Ledges and Movers

[heliomass]

Hi All,

I've been working on a library of two Lua classes which will allow solid ledges and fully 3D moving platforms.

The first is called Ledges, which can either be decorative (basically the same as placing a 3D model in a map), or solid (meaning you can walk on it as if it were a solid polygon).

The second is called Movers, and is basically a Ledge that can move along a path. It can be activated by a switch, or it can be initially active. Like a Ledges object, it can be either decorative or allow the player to walk on it.

Although I'm developing this for my own scenario, I'm making sure that the library is easy for others to implement. It's used something like this:

Code: Select all

function Triggers.init(restoring_game)

        -- Create Ledges and Movers objects here
        demo_mover = Movers.new(constructor_arguments_go_here)

end

function Triggers.idle()

        -- The below is pretty standard, just cut & paste into your own script
        for player in Players() do
                for ledge in GetLedges() do
                        ledge.perform(player)
                end
                for mover in GetMovers() do
                        mover.perform(player)
                end
        end

Anyway, without further ado, a video to show it in action:

https://www.dropbox.com/s/ssynz04orasen ... _mover.mp4

So, as you can see from the video, there are a few questions I'm trying to resolve:

a) It seems the centre of the 3D model has to be in front of the player for it to render. If I'm on top of a moving platform (as in the video) and turn around, the platform vanishes from underneath me. Any workaround for this? (one idea I'm considering is having the platform composed of several separate models fitted together like a jigsaw)

b) How do I cancel the player's forward momentum? Once standing on the platform, my script is moving the player's location to match the platform, but this isn't ideal (there's no way to step off!). It seems that unless the player is standing directly on a polygon, the engine considers them to be falling, and so they have this frictionless forward momentum.

c) When replacing scenery with 3D objects, you lose the original scenery object you're replacing. Any way to have the 3D objects in addition to all the scenery, otherwise levels with lots of models will look sparse.

d) Any tutorials on making exported Blender obj files work with Aleph One? Every attempt I've made to use an exported 3D object of my own crashes Aleph One, so I have to assume I'm doing something wrong in Blender before exporting.

Thanks!

[irons]

I can only answer question (b). You can't cancel it based on player input. Once a player is in midair, that player's "internal velocity" can't be changed by his actions. This is the whole reason why such scripts never took off.

[heliomass]

But it seems the internal velocity also can't be modified by Lua either. Is there a reason for this I wonder? If there was a way of having Lua modify the internal velocity... or could the internal velocity be offset by an inverse external velocity (which Lua can modify)?

[Zott]

As far as c): I don't know of a way to both keep the scenery and the 3D model. My advice would be to replace scenery that is normally static with your 3D model. Then, take the sprites for the scenery you have replaced, and add them to another scenery object that is marked one view random frame. You lose some control, but the sprites can still show up. I would suggest consolidating some of the many 'bone' scenery between the collections.

I don't know if this would work, but you might be able to hide 3D models in the 'destroyed' state of scenery using mml. Then, make the scenery objects have almost no collision detection so the normal 2D scenery can't be destroyed by the player. You can then destroy that scenery with lua to reveal the 3D model as applicable.

[Crater Creator]

This is neat to see; best of luck with your experiments.

a) It seems the centre of the 3D model has to be in front of the player for it to render. If I'm on top of a moving platform (as in the video) and turn around, the platform vanishes from underneath me. Any workaround for this? (one idea I'm considering is having the platform composed of several separate models fitted together like a jigsaw)

Your jigsaw solution might work as well as anything, but it seems like a lot of extra work. The alternative would be to tightly control the angles from which the player can see the 3D model.

Aleph One uses the lines between polygons as portals to figure out what it may need to draw. Anything on the same polygon as the camera should pass that check as being potentially drawable. So assuming the 3D model and the player are on the same polygon, there's probably another check that's finding that the point where the scenery object is placed isn't in view, so it therefore doesn't draw any of the 3D model.

b) How do I cancel the player's forward momentum? Once standing on the platform, my script is moving the player's location to match the platform, but this isn't ideal (there's no way to step off!). It seems that unless the player is standing directly on a polygon, the engine considers them to be falling, and so they have this frictionless forward momentum.

Years ago I also tried floating polygons with lua. They turned out differently than yours, but I do remember I wasn't able to fix this problem to satisfaction. Adding external velocity can counteract, but not cancel out internal velocity. The player's going to keep that speed, even if you counteract it every frame, until he touches the ground.

...Which brings to mind a wacky idea. We've got triggers for idle() and postidle(). I have no idea if this would actually work, but... what if you move the player to the ground in idle(), so he can encounter friction and accelerate/decelerate as expected, and then move him back onto your platform in postidle(), so when the game renders he looks like he never left? I'll be the first to point out this could cause weird interactions with other players, monsters, or items.

c) When replacing scenery with 3D objects, you lose the original scenery object you're replacing. Any way to have the 3D objects in addition to all the scenery, otherwise levels with lots of models will look sparse.

Wait, so the tools don't provide a way to add slots for new scenery items? If that's the case I don't have an answer, but I'm surprised.

d) Any tutorials on making exported Blender obj files work with Aleph One? Every attempt I've made to use an exported 3D object of my own crashes Aleph One, so I have to assume I'm doing something wrong in Blender before exporting.

Documentation is regrettably sparse. This link is very old and doesn't mention Blender, but it's all I can offer.

[heliomass]

Thanks for the replies everyone!

...Which brings to mind a wacky idea. We've got triggers for idle() and postidle(). I have no idea if this would actually work, but... what if you move the player to the ground in idle(), so he can encounter friction and accelerate/decelerate as expected, and then move him back onto your platform in postidle(), so when the game renders he looks like he never left? I'll be the first to point out this could cause weird interactions with other players, monsters, or items.

That's definitely thinking outside of the box! I shall give it a try, and report back what happens.

Failing that, I was thinking that a behaviour for Movers could be that the mover "grabs" the player when they step into its boundaries, as seen in the video.

The player will then travel along with the mover until they hit a key (perhaps action?), at which point they will hop forward, either to safety or into the abyss. It's not perfect, but it would suit my own needs. An optional argument to the class constructor would allow for an on-screen message to explain to the player how to hop off, perhaps for the first platform the player encounters in the scenario.

[heliomass]

That's definitely thinking outside of the box! I shall give it a try, and report back what happens.

So, that was a fantastic idea Crater Creator, it works! I can now walk around Ledges, and by making the Movers inch the player forward by the same amount as the movement, I can freely walk around a moving platform too.

There are a few issues, but I think none of them are insurmountable:

• The biggie is that once you drop off the edge of the Ledge, you're immediately on the polygon underneath without a fall, but I reckon this can be worked around.

• As you mentioned, there can't be any monsters or other obstructions underneath the platform, but again that's easy to work around too.

• You can't step from the platform back onto the raised polygon if the polygon, I guess because the engine thinks the player is on the ground, or perhaps the moving platform isn't quite high enough. Not sure how to work around this one.

I'm going to experiment to work around these problems, and I'll put up another video soon.

Thanks again everyone!

[treellama]

Maybe you play Marathon differently than I do, but I would consider the inability to fire or be hit by a projectile to be an issue!

[treellama]

But it seems the internal velocity also can't be modified by Lua either. Is there a reason for this I wonder?

There isn't a straightforward way to let Lua scripts control this and still interact well with the game's (primitive) latency hiding. I didn't want to implement a non straightforward way because I don't trust Lua scripters to do it right. This thread only reinforces that belief

[heliomass]

Maybe you play Marathon differently than I do, but I would consider the inability to fire or be hit by a projectile to be an issue!

Fair point, I hadn't even tested that! I suppose there might be a way to have the projectile fire at the hight of the moving platform, rather than on the floor where it's actually firing?

There isn't a straightforward way to let Lua scripts control this and still interact well with the game's (primitive) latency hiding. I didn't want to implement a non straightforward way because I don't trust Lua scripters to do it right. This thread only reinforces that belief

Harsh, but fair For my purposes, this is good enough. It will work for instances where there's no monster interaction, which is what I need.

• The biggie is that once you drop off the edge of the Ledge, you're immediately on the polygon underneath without a fall, but I reckon this can be worked around.

• As you mentioned, there can't be any monsters or other obstructions underneath the platform, but again that's easy to work around too.

• You can't step from the platform back onto the raised polygon if the polygon, I guess because the engine thinks the player is on the ground, or perhaps the moving platform isn't quite high enough. Not sure how to work around this one.

I've solved issues 1 & 3 by detecting when the player moves out of the Ledges object's bounds, and putting the player back at the correct height post-idle. The gotcha is that there needs to be a slight gap between the Ledges object and the raised polygon, so the player can momentarily fall off at the correct height.

Anyway, a video will probably demonstrate better than I can explain it:

https://www.dropbox.com/s/bb0v7idnm28ex ... over_2.mp4

I'll definitely share this library with the community once I think it's usable, even if it does abuse the Aleph One engine

[Crater Creator]

That works impressively well in your last video. Nice work!

[treellama]

For my purposes, this is good enough. It will work for instances where there's no monster interaction, which is what I need.

even if it does abuse the Aleph One engine

You don't need Lua control over internal velocity to accomplish this one, though. A simple "player.allow_velocity_control_in_flight" (if such a thing existed) would work here right?

[Wrkncacnter]

He hasn't even gotten around to adding monster_minor_tick_is_dying_hard yet, so don't hold your breath.

[heliomass]

You don't need Lua control over internal velocity to accomplish this one, though. A simple "player.allow_velocity_control_in_flight" (if such a thing existed) would work here right?

Sounds like that would address all those issues. The flag could be switched on whilst the player is on the platform, and would negate the need to "fake" the player being on the ground. But, wouldn't this contradict what was said earlier? Specifically:

There isn't a straightforward way to let Lua scripts control [internal velocity] and still interact well with the game's (primitive) latency hiding. I didn't want to implement a non straightforward way because I don't trust Lua scripters to do it right. This thread only reinforces that belief

[treellama]

But, wouldn't this contradict what was said earlier?

Hmm, the game would be responding to entirely player input in that case (just more of it than usual in the air), so it doesn't contradict with the first sentence, at least.

[heliomass]

In which case, is there a process to submit this as a feature request? I can see that bugs are reported at http://sourceforge.net/p/marathon/bugs/, but this isn't really a bug.

EDIT: OK, found it http://sourceforge.net/p/marathon/feature-requests/

[Crater Creator]

*BUMP*

Although I'm developing this for my own scenario, I'm making sure that the library is easy for others to implement.

Did you ever reach a point where you can share your lua code for others to explore and use?

[Hopper]

The bump reminded me that I swiped the idle/postidle player repositioning idea for Vasara. Since the editor doesn't need to worry about projectiles or aliens, the visual trick works pretty well to read player movement in the air, or prevent movement while on the ground. So thanks for the idea, CC, and thanks to heliomass for starting the line of thought.

[heliomass]

Hi All,

Unfortunately, I've not had time to return to working on this lately. Apologies for those who've been curious.

My aim is to get the Lua code I've written to be well documented and API-like, so it's really easy for a non-coder to just plug in the module and have things just work.

I also wanted to produce a demo level or two to show off what's possible. Since the Canadian Winter is approaching, they'll be less sun to tempt me away from my hobbies