Grimrock

Pompidom wrote: ↑Wed Mar 06, 2019 2:54 pm

minmay wrote: ↑Wed Mar 06, 2019 10:44 am Repositioning pushable blocks with setPosition() is not a good idea, because their DynamicObstacleComponent will continue blocking the square they were previously on. You should destroy the block and spawn a new one instead.

In this case, it can actually be beneficial. An invisible obstacle left by the original location of the block will prevent the player from getting weird ideas like for example trying to walk upon the block that has dropped down. which won't work since he will then fall through the block.
Let's say the block is used to drop down from elevation 1 to elevation 0. He will have enough trouble as it is with people solving the puzzle alternatively by either jumping on the boss or glitching through blocks.
Block falls down, obstacle will prevent the player from walking/glitching through the fallen block. Block moves back up again, everything is fine since the block is back to the original position.

The script I provided works fine for what he wants to use it. Just adjust the speed and he's done.

https://youtu.be/8sLtNd--jsY

Except the design of my dungeon will require that the player both walk under the block and use the block as a bridge to access other area's later on. If the players path is blocked by an 'invisible wall' or they're falling through it, that simply won't work for what I want to use it for. I will use other methods to prevent the players from circumventing the boss. Like an 'on monster death' script that triggers when the boss is killed.

Everything you just said is super easy to implement with my basic simple script. The block starts at elevation 1, so you will always be able to walk under it.
As soon the boss is dead, you simple call block.destroy() and spawn block at elevation 0. Since the block is already there, there will be no visual issues as well.

Also spawn or enable an invisible platform on top of the block or spawn or enable a magic bridge on it like so many other mods already have done. There, problem solved. I played at least 3 mods that had a puzzle similar to the puzzle/boss fight you're trying to achieve here. you can walk over the block to the next area.

You can give the block a platform component as well.

I have no idea what you're fuzzing about. I started making this type of puzzle months ago just the same way like you want it to happen in less than an hour.
You know what I did? I deleted it. All of it. It was hands down the most fucking BORING puzzle i had ever created. And it was already done in other mods. Dropping a block on a monster boss is "mehh"
And all it took was my simple script and some delayed call scripts with some .enable() .disable() .destroy() and spawn trickery.

You're better of creating a small arena (9x9) for example on 0 elevation where you are being chased relentlessly by an immortal boss (for example an ogre boss charging at you all the time) So you actually have a more thrilling boss fight instead of waiting for the damn thing to walk under your block which is basically the equivalent of watching paint dry.
Where you have to activate 4 blocks manually and then move them around until you can trap the ogre on a furnace or a pitfall with lava or something like that. And then later move the blocks around to activate/create a bridge.

Now this is just my personal opinion. Up to you what you want to achieve in the end.

Thank you Pompidom, yes you have a very simple solution; and I appreciate the work you've done to help with my question.

The reason this doesn't work, is because of the DynamicObstacle component. Say I was to use this script, which does work in dropping the block which was the initial problem. (Adding a gravity component does the same thing.) The problem with this is since the DynamicObstacle remains in the initial position. Even if you add an invisible platform, or add a platform component to the block, the DynamicObstacle is still at height 1, and blocks passage. Meanwhile you can walk through the actual block model at height 0 as it now has no collision.

So yes, your script visually does the job. It mechanically fails at every point for what I need it to do. As no matter how you destroy, disable, enable, create and recreate; the instant you move the block via this script you're going to run into this problem. While yes, I could add in invisible walls at the 4 sides of the model when it's at height 0 via more scripting, and destroy/create blocks at whim to keep the components in the same 'real space' as the model, or disable the Dynamic Obstacle completely. That's not solving the actual problem that's working around it with admittedly clever solutions. It can also lead into other problems like if a player finds a creative solution that you didn't think about.

Edit

I've been doing some thinking and research on this and came up with a solution of sorts, just have a few questions on how to implement it. In the Pushable Block object script it has the clickable class and uses party facing to move the block in the cardinal directions. If I can add two more directions, on the Z axis using the mechanic it should be a matter of calling that with a button or timer, whatever to move it in those directions. The problem of course that the party can't 'face' up or down. While we can move the camera to view up or down, that's completely different than what the game understands. So I took a look at the code:
This is what I am understanding this to do. When you click on the block, it looks at all 4 'clickables' and runs the function(self) on each. Which takes the facing of the party and see's if it's equal to it's facing, +1, +2, or +3 to get the four directions. Then for the one it finds true it moves the block by the offset vector value. So what I can in theory set a vector for the +- Y vector in two more to have it move up and down via the :push command. The only question is how do I script it not using a party.facing. I've been looking through the script reference but not seeing something to satisfy this. While I know I could just tell the script on click to go up or down the Y axis. Since the clicking mechanic doesn't account for the face that it's clicked on, that would ring true for every way clicked making it either crash or simply not do anything as both up and down would be always true every click. A lever activate/deactivate could solve this, if I hard code a rise fall lever and include it in the dungeon; would there be a better solution though?

Killcannon wrote: ↑Thu Mar 07, 2019 6:04 am
So yes, your script visually does the job. It mechanically fails at every point for what I need it to do.

Ok, 5 minutes work with just 2 simple blocks showing you the objective situation. And how all your concerns are invalid. And how my simple solution does work 100% mechanically and it is simply a matter of you not understanding how it works.
In this video I will show you how I walk or bump into blocks and spaces where blocks used to be without any of the issues you mentioned. Without using anything.

If you give the blocks a gravity component and a platform component it will be even more easy. And you can make the entire thing without any scripts.

https://youtu.be/RgkhUkRVgKg

The only script I had to use was this:
My movement script is simply used to simulate your gravity component. And in case you want to use it as well moving the blocks back up again like you asked.

All I had to do was disable dynamicobstacle on both blocks.

So again, I have no idea what you're fuzzing about.

The block crushes the monster.
Even after movement of the blocks,
Every tile where there is no block is perfectly accessible by the party.
Every tile that contains a block is blocked.
And you can now use the block as a bridge.

Every single issue you seem to run into simply doesn't exist or can be overcome by using common sense.
I already told you that I made a similar puzzle you're trying to achieve in less then an hour a couple of months ago. It worked flawless. It was also boring.

So just get building, and if you run into specific issues, let me know, I will have the solution for it.

If I wanted to modify the heightmap of a tile in a function, how would I go about doing that..?

I'm trying to remove a mound that is in front of a tombstone when the player digs a floor trigger.

Heightmap mesh cannot be changed once the dungeon has been loaded.

Shadowlet wrote: ↑Fri Mar 08, 2019 1:33 am If I wanted to modify the heightmap of a tile in a function, how would I go about doing that..?

I'm trying to remove a mound that is in front of a tombstone when the player digs a floor trigger.

You do have a couple rockpiles, sandpiles, and stone_pile objects in the game. You can instead place one of those in front of the Tombstone and then use a Destroy object or object health component to destroy it when the players dig.

Pompidom wrote: ↑Fri Mar 08, 2019 1:55 am Heightmap mesh cannot be changed once the dungeon has been loaded.

That is not ~technically~ true. The heightmap component has a model, and it can be both moved and deformed via scripting. But this does not affect the way the engine raises an lowers the various placed objects and animated monsters. Changing the model will cause objects to appear to sink into or float above the ground plane.

We were talking about the layer. Not the object.

technically it can be changed, but that involves saving/loading before the effect can be seen.

The technique like Killcannon mentioned is a nice alternative. A beach sandpile object on beach ground for example works fine.

Pompidom wrote: ↑Fri Mar 08, 2019 3:39 am We were talking about the layer. Not the object.

technically it can be changed, but that involves saving/loading before the effect can be seen.

No, that is not what I am describing.