can tiles be elevated / lowered?

[Diarmuid]

unfortunately, the technique required to do this is really pushing the engine to its limits. I even had to cheat a bit to get that video running, in that I stored directlyentities in tables instead of string ids and findEntity calls. Else I was getting 7-8 fps at times! But you could not run it beyond the editor at a decent speed. But if the player was enclosed in the elevator or with an otherwise blurred vision it could work.

[Dr.Disaster]

Ain't pushing the engine how new things are made possible?
(what's the cpu/gpu you run on anyway?)

Beside that you need to consider these elevators run constantly. That's not needed when the party is not around and most would even want to activate them on need only by switch or pressure plate if they don't intend to build some mad climb-to-the-top puzzle. Aaand there is always the option of further optimisation

[Diarmuid]

Oh I have a 4th gen i7 with a GTM750 Nvidia, problem isn't there.

Actually we don't have control over the party position, but we have control over the environment. So I took the problem backwards: if I cannot move the party, I'll move the environment. So that's what's happening here. When the party steps on an elevator to go up, the entire level slides down, the party never actually moves off the "real" floor plane.

So how is that "moving" done? The only thing in LoG that allows us any control over the Z position is the shootProjectile function which allows to shoot a projectile at a specific height. So the entire level in my video is made out of projectiles, but unfortunately, once shot, I cannot alter their height anymore. So I need to destroy and respawn the whole lot every frame (when the party "moves" only, of course), which is super inneficient, relies on a ton of findEntities and entitiesAt calls, and obviously bogs the thing down no matter the system.

What I meant by pushing the engine, is that it's a very convoluted way of doing things exploiting some niche details, while a simple :translate(x, y, z) function added to all objects would have made everyone's life so much easier in the past year.

As long as there were only certain elements moving however, like only the elevators, it was running super fine, though. That's a reason why the "stomper" is actually super easy to export and reuse. The experiment at least got us a usable trap...

[Leki]

Well... I have some experience with this so I can share it I guess...
It can be done by simple trick/animation (level part is on one - for example door - node) - play anim, spawn / destroy animated object if you need. No performance issues... In other word you can control env as a door (another object operated in Z axe, right ...

I already tested it +1/2 year ago and I can move whole level...
You can do it by yourself in very simpe way:
import obj as walls and floor and ceiling model is into blender,
create level pard using these components
add some objects as statue or torch holder is...
colapse and name node as "door" - you can rename it in GMT as well
write custom door object definition...

So you created level part as "door" (walls and floor etc are "door") - for simple 0 to +/-3 level (depends on state of door and pivot, then do the same level as -3 pivot and you can respawn the new one... place into scene, controll by evenet close/open. For more levels, use more doos, with pivots in +/- 3, but There is bug with hardcoded door movement if I remember it correctly, so better choice is to do it as an trap door and animation is open/close event... But for +/- 3 m level its ok.

There can be a small problem with lights, so you have to remove normal torch holders etc, and torch holder must be a part of model and fire particle must be linked to that node - it means one torch per model - but still you have to spawn and destroy light - easy job - first spawn then destroy first to prevent blinking - timed on animation by timer.

It's still 1000x simplier than your full scripted/projectile method you described... And animation allows you to control object in all directions... But I dont liked it because of droped items, so i got an idea: Read cells for items droped by party, destroy items and spawn projectiles, destroy and spawn when movement ends... it works, but you need all items in +3, 0, -3 pivot position sets. So I gave up to do it...

[Isaac]

But I dont liked it because of droped items, so i got an idea: Read cells for items droped by party, destroy items and spawn projectiles, destroy and spawn when movement ends... it works, but you need all items in +3, 0, -3 pivot position sets. So I gave up to do it...[/color]

I did it differently. In my rooms that use the effect, you can drop anything you like, and I did not alter any of the models; the effect (as I was using it) was limited to a few small areas, and it sufficed to place alcoves that corrected for the elevation change.

But of course for an entire level that used the door trick, it would be worth it to use Diarmuid's stair-spawn script to spawn the alcoves dynamically; and conditionally activate/deactivate the effect.

[Diarmuid]

Obviously baking models together would fix the issue, but once we have only 1 big model, controlling it with projectile respawning would maybe still give more dynamic control over placement/speed depending on what is going on vs a door and less speed problems. But anyway as you said, many issues to fix with items and such...