Scripting walls possible in LoG2 modding?

[MrChoke]

I read somewhere (don't remember where) that one enhancement to LoG2 modding capability is how walls can be dynamically created and I assume destroyed via Lua scripts. Am I high or did I read this correctly. Does anybody know?

Thanks

[Chimera005ao]

I recall similar.
I'm assuming they use wall objects, not tiles.
Which would mean you might (randomly?) determine which spaces should be a wall, then place an invisible blocker there, then surround that square with wall objects and pillars. Which shouldn't really be that hard, but preventing it from spawning the wall objects that would not be seen (as in the spaces connecting two walls) might take a bit more work.

This is probably just one possibility.

[MrChoke]

So I found where I read this stuff on scripting walls. An article from Feb 2013:

http://www.grimrock.net/2013/02/01/ever ... criptable/

I hope this is still true.

[Lark]

I sometimes get a little carried away, so this example isn't as simple as it started out to be, but... Place this script anywhere and trigger its one function from a pressure plate in the middle of at least a 3 x 3 dungeon room. When the party steps on the plate, the script will erect a wall and blockers around the party so they cannot escape. Obviously you don't want to use it as is, but it shows the concept.

Code: Select all

function makeWalls(c)
  xs = {-1, 0, 1, 0}
  ys = {0, -1, 0, 1}
  for i = 1, 4 do
    ox = c.go.x + xs[i]
    oy = c.go.y + ys[i]
    spawn("invisible_wall", c.go.level, ox, oy, 0, 0, c.go.id .. "_iw_" .. i)
    spawn("dungeon_wall_01", c.go.level, ox, oy, i % 4, 0, c.go.id .. "_dwo_" .. i)  --outside
    spawn("dungeon_wall_01", c.go.level, c.go.x, c.go.y, (i + 2) % 4, 0, c.go.id .. "_dwi_" .. i)
    spawn("dungeon_pillar", c.go.level, c.go.x, c.go.y, 0, i % 4, c.go.id .. "_dp_" .. i)
    end
end

A few points to note: This creates inside and outside walls because the inside walls do not block the light. Since walls can be walked through, a invisible wall has to be created too. If you use something like this, be sure to auto or otherwise disable the rerunning of the script as duplicate ids will be created and it will crash. Leave the id (last) argument off to have the system generate the field ids if you don't need to reference them later. I hope this helps - let me know if you need more of an explanation of the script.

[MrChoke]

Thanks! I will try it out. I have a few questions though. What is "c" that is passed in? Also what is the "go" reference in "c"? "go" is that short for GameObject maybe?

[Lark]

Thanks! I will try it out. I have a few questions though. What is "c" that is passed in? Also what is the "go" reference in "c"? "go" is that short for GameObject maybe?

The "c" is a reference to the calling object. Note that it was used in the parenthesis of the model "function" statement. It's just the variable that is sort of a pointer to the calling object. I would have called it "calling", but I didn't want to type that much. So, if you link to the script using a pressure plate, for example, "c" (or "calling") will be the pressure plate object. Therefore, you can reference the pressure plate's coordinates by c.go.x, et cetera. Yes, you are correct in that the "go" stands for "Game Object" and it's required to reference the object's coordinates. -Lark