Just showing off GG capabilities regarding Lua so excuse the rubbish lighting, uninspiring entities and bland map and concentrate on what can be achieved with two Lua scripts (one attached to the lift platforms and the other attached to the walls, roof and doors for each lift).

Now I just need to figure out how to use this in a game.

Video upload didn't work, uploading it to photobucket ....

While I'm waiting for photobucket to "process the video", whatever that means, here are two screen shots to wet your appetite

Gave up with photo bucket, hope this works instead:

https://vimeo.com/175132661

Those animations are buttery smooth! nice job!

They aren't strictly speaking animations, all the entities are just simple, normally static, solid objects that are being moved around in games space in real time.

The trick to getting it smooth is:

1) Set the entities physics weight to 0.
2) Store the entities for each lift in an array then move the lift platform first followed by all its entities in the same frame.
3) Turn collisions off before moving the lift and on again afterwards.
3) Set vsync to 1 in the init file and only move things by a tiny bit each frame, for example the doors are moved by 0.25 each frame.
4) Have a machine fast enough to always give 60 FPS.

Not only does this only use two scripts but it does not rely on any timers and only uses 3 global variables! (two of which are 'lists' )

In third person I think it suffers from the Lua before Physics bug* (which Lee is fixing for the next release) so isn't as smooth plus the camera movement as the lifts go up or down is a bit erratic (a common 3rd person problem in enclosed spaces).
(*correction, it happens even when the lifts are stationary so it is some weird camera problem)

The only limitations on the lifts with the current scripts are; 1) that they can only be oriented 0, 90, 180 or 270 degrees, the math required to allow any angle would be possible but not worth it really. 2) they can only currently be 'up' or 'down' .

You can have as many lifts as you want (not sure if there is any limit to how many 'active' entities GG will cope with but the demo here has 15 lifts).

Incidentally does anybody have any lift sounds?

Here are the scripts.

Smaller one is attached to all the lift 'components', big one is attached to the lift bases.

In properties:
The 'name' of the base must be the same as the 'name' of all its entities (e.g. 'Lift1')
For the base the 'strength' specifies the stopping height so for example if the base is placed at a height of 600 (default of the flat map) and the strength is set to 700 the lift will start of 'down' and when entered will go up one floor (800 would be two floors etc). If the lift base starts at say 800 and strength is set to 700 then the lift starts in the 'up' position and will travel down when entered.
For the lift 'components' the 'strength' specifies what they are, 1 - left hand wall, 2 - back wall, 3 - right hand wall, 4 - roof, 5-6 stationary door parts, 7-8 moving door parts.

A lift must have all 8 components to work.

Make all entities static - no, always active, 0 weight

edited to add - the lift base should be placed where you want the lift to be and rotated appropriately to either 0, 90, 180 or 270 but the 'component parts can be placed anywhere as the script will locate them at runtime. The offsets are hard coded to be appropriate to the entities I have used which are all 100x100 in size, if you find this look really weird it is probably because the entities you are using are either not 100x100 (with the origin in the centre) or they are rotated differently.

Thas realy cool,thank you .

Dave

That's great, thank you! I have thought of remaking the old 2d game "Elevator Action" in a 3d environment. Was never sure if it would be as fun, though. This would make it pretty easy to try, at least.





Is there another direction for lifts that I'm not aware of?

thank you.

pretty awesome work mate, nice one.

just to clarify, all the walls of the lifts need to be 100 high correct? if yes then is there a way to change that in the script? as the standard gg room height is 125 to 135 to avoid clipping.

If you use different sized entities you'll just have to fiddle with the offsets, I will probably fiddle with that myself at some point, maybe have a static array as a global specifying the dimensions and have the script pick the right values.

Height of the walls should be easy enough as you just need to change the entity '4' y offset in the script to lift the roof up.

A bigger change would be to use 200x200 base for the floor for example, then the x and z offsets would need to be changed (and different sized doors used etc.

Can't of the life of me find any free sound samples, might have to go out and record them myself!

https://www.google.es/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=lift%20sounds%20free

Do not try scripts yet, but it sound interisting after look the video.

3com

What I meant by only 'up' and 'down' is that currently the lifts aren't able to service multiple floors, to do that would require some more scripts attached to lift operating buttons or similar, easy enough to do but I was going for a minimalist approach as an example of what scripting is capable of rather than a fully fleshed out game solution.

What would make things a lot easier when doing this sort of thing is being able to access other entity parameters from within scripts, for example the size of it or the speed setting. (hint: vote for the option!)

Any 3d artists out there like to create some lift (elevator) components to make this more realistic, some nice metallic doors for example?

Hmmm, I appear to have been extremely lucky in picking entities that fit quite nicely together!

Just tried to put together a big lift 200x200 with various components from different packs and failed miserably. Some entities I couldn't even make 'active' from the properties so had to edit the .fpe files.

In the scripts the init script sets the height of the roof (YO=nn)

The function calc_positions sets the X and Z offsets and rotations depending on the rotation value of the base.

Those are the two main places where values will need to be edited if you use different sized entities (or ones with different default rotation values).

The fiddliest bit is the doors, in the script 'sd' stands for stationary door and 'md' for moving door.

Figured out what the problem was, I designed the script with entities that have the origin in the centre, i.e. when you rotate then in the editor they spin around on the spot.

Standard wall segments rotate around a 'centre' off to one side so that in grid mode they line up with floor and roof segments. To use these in a lift will require amending the scripts so you can specify either centre rotating pieces or offset rotating pieces (or you can edit the offsets by trial and error to find the best fit).

OR edit the fpe files to specify offsets to make the entity rotate around its centre, OR re-import the entity you wish to use and specify the 'centre' option in the importer (although I haven't tried this to see if it works as I expect it to).

How about instead of three wall section in separate models, have them as a single object with the origin as a median point in the centre, hopefully fixes the issue, cuts down on the number of scripts running, and reduces the poly count a tiny bit?

Are you volunteering to make it?

I realised I was being a bit daft, I'm going to knock up some scripts which will give the values needed in the scipts, i.e. put the lift parts together in the editor where you want them to be, run it and each entity will report it's offsets from the base, simply transfer those values to the bas script and job done.

The scripts running part is not really an issue if all they are doing is returning to the engine, it's only when they are doing some heavy lifting that they impinge on the performance (with 15 lifts the AI slider barely registers!).

If anyone wants to knock some simple lift parts in different varieties, i.e. a wooden lift, modern steel lift etc, that would be super smashing great.

LOL, I see, thanks again!

Perhaps I don't get the point right, if so excuse me.
But, why does not simply use let's say some decals as start/end point.
In another words, a decal in the start point (usually firts floor), and a decal in each floor you want the lift stop, smallg should have something done about this.

3com

How is that simpler? That would require another script on the decals plus how does the player indicate which floor to stop at?

I suppose one way of doing it would be to have an 'up' decal on one side of the door and a 'down' on the other side, if the player steps in front of the decal it sets the direction for the lift, if the lift is not on the same level as the player it moves to that level. Player steps in lift and it goes up or down as appropriate and then stops momentarily at each floor, if the player stays in the lift the door closes and you carry on up or down. (obviously top floor and bottom floor only require one decal)

Still reckon some buttons in the lift would be cooler with a call button on the wall near the lift, would be more realistic.