Lua tables

[ravenshining]

Forgive my lack of basic knowledge here, but I get the impression that whatever I'm doing wrong is so basic that everything I'm reading up on to try and solve this assumes I know the relevant syntax already.

I know I can assign values to things in a... table, I take it? for example:

Code: Select all

Polygons[58].visible_on_automap = false

will remove polygon 58 from my automap if I type it in manually to the console. But in a script, I would need to specify a polygon I don't know ahead of time, not just #58. So I write a function to store the polygon I'm standing in to a variable:

Code: Select all

function standing()
  stand = Players[0].monster.polygon
end

And I can use that variable in a function, say, to teleport there later:

Code: Select all

Players[0]:teleport(stand)

But If I try to use that variable to assign a value in the table above, it doesn't work. If I put this line in a script:

Code: Select all

Polygons[stand].visible_on_automap = false

It doesn't work, I get a cryptic error:

Code: Select all

attempt to index field '?' (a nil value)

From what I've been able to read and somewhat understand, I think the problem there is that I'm telling the script to look for a polygon called stand, not the polygon index corresponding to the variable stand. On about the 30th webpage I attempted to reference (I counted!) I got a hint that putting quotes inside brackets might be a way to do this:

Code: Select all

Polygons["stand"].visible_on_automap = false

but that doesn't work either. Now it's 3 am and I'm running out of search ideas.

[$lave]

You can actually just use stand directly. I made a small script which hopefully will help a little bit; it just sets the player's polygon to one texture and every other poly to a different floor texture:

Code: Select all

stand = nil

Triggers = {}

function Triggers.init()
	stand = Players[0].polygon
end

function Triggers.idle()
	stand = Players[0].polygon

	for p in Polygons() do
		p.floor.texture_index = 10
	end
	
	stand.floor.texture_index = 11
end

A couple things: make sure "stand" is in scope. I'm assume scope in lua works like most other languages, and if "stand" is only used inside of one function, then it won't "exist" or be visible to other functions and you'll probably get nil. Also make sure you initialize it to some non nil value before it is ever used.

[Wrkncacnter]

I'm assume scope in lua works like most other languages, and if "stand" is only used inside of one function, then it won't "exist" or be visible to other functions and you'll probably get nil.

You have to use the "local" keyword if you want your variable to be local to the function, in this case the function would assign a global variable.

[treellama]

To answer the specific question, you can't use a polygon to index the Polygons table! You have to use a number to index it. So, Polygons[stand.index].visible_on_automap

But like Steve said that's pointless when you can just use stand.visible_on_automap instead.

[ravenshining]

Awesome, thank you guys so much for bearing with me there!

Now I have a script that lets me edit floor and ceiling heights sort of like Forge used to do ;-) Don't worry, I won't distribute it if y'all think that would be a bad thing to do, especially since I haven't gotten the math right and stole a lot of code from several other scripts, but it'll be useful for editing natural areas or if I do a pass with Weland to smooth things out afterward.

[Wrkncacnter]

Does collision with raised walls work when you do that? If so, what are you doing to make that work?

[ravenshining]

Collision only works if the sides are already textured. I suppose I'd need to combine it with a texturing script for that to work with newly-exposed sides - which would be really convenient - but juggling the limited set of modifier keys is tricky.

At the moment, I have it set up like:

microphone button: jump/fly
primary trigger: teleport to target polygon (only works if it has a side)
action trigger: remember the polygon you're standing on
cycle weapons backward: raise floor height of remembered polygon 0.1 WU
cycle weapons foreward: lower floor height of remembered polygon 0.1 WU
secondary trigger + cycle weapons backward: raise ceiling height of remembered polygon 0.1 WU
secondary trigger + cycle weapons foreward: lower ceiling height of remembered polygon 0.1 WU

[Wrkncacnter]

Assigning a texture isn't sufficient to fix collision. There's no way to make collision work, as far as I know. However, after you .save level and re-load the map, collision is fixed at that point, so maybe not a huge deal in this case.

I'd also imagine most people would only be interested in this if it were integrated into VML/Vasara, otherwise you'd have to keep switching scripts to fix the untextured mess you just created, then fix the heights again when you can see what you have, and keep going back and forth.

[The Man]

This would be worth building a fork of either VML or Vasara to integrate, IMO. Having to save and reload to get collision detection to work properly is a small price to pay for not having to switch applications nearly as often. If needed, I suspect it should be relatively easy to integrate a feature to require elevations to be constrained to certain limits as well (my vote goes for 0.05 WU) so that it isn’t stupidly imprecise like Forge’s implementation was.

Of course, my #1 and #2 feature requests for VML/Vasara are fixing the tag switch/platform texturing issues and implementing a way to keep existing alignment when you retexture a given wall. Vasara also needs support for maps with more than 56 lights, and probably some other bug fixes as well. I might look into writing some/all of these when I can focus more on things besides Eternal.

Regardless, it would be nice to be able to have a way to redo polygon heights in a texture editor, since I often used to find it helpful to change them temporarily and then change them back (particularly for polygon boundaries that were close to a particular wall), so I’m in support of this addition.

[ravenshining]

Assigning a texture isn't sufficient to fix collision. There's no way to make collision work, as far as I know. However, after you .save level and re-load the map, collision is fixed at that point, so maybe not a huge deal in this case.

I see you're right. I just tested raising a floor from the console in Vasara, texturing it, and walking into it, and it warped me to the top.

I'd also imagine most people would only be interested in this if it were integrated into VML/Vasara, otherwise you'd have to keep switching scripts to fix the untextured mess you just created, then fix the heights again when you can see what you have, and keep going back and forth.

It is a third layer to the already complicated process, but editing heights in Weland creates the same problem of un- or wrong- textured sides, you can't see what you're doing, and you have to switch applications entirely, which is extra problematic if like me you're on a platform where Aleph One refuses to be alt-tabbed into or out of unless it's running in windowed mode.

With this script, I can edit heights without having to leave Aleph One, and I can see what I'm doing.

If needed, I suspect it should be relatively easy to integrate a feature to require elevations to be constrained to certain limits as well (my vote goes for 0.05 WU) so that it isn’t stupidly imprecise like Forge’s implementation was.

0.05 WU would be convenient, but tedious, and like 0.1 doesn't go into eighths very well, you'd need 0.025 for the GCF of 1/8 and 1/10. I could add a function to specify how much the increment should be, although getting the math right might be complicated. At the moment, for example, if I raise a polygon 0.5 WU with the script, Weland shows it having been raised 0.498 WU.

[The Man]

I think dividing a given variable into 51.2 (i.e., 1,024/20, or .05 WU) and then, if needed, adding whatever the base value of 0 WU is internally (probably 32,768) might be the best solution. I can’t remember if Lua automatically converts to integers when needed; if not, I presume there’s a function for that somewhere. If needed, it might also be helpful to add .5 to the quotient so it rounds up in edge cases.

I’m also going to add +1 to needing to deal with windowed mode less often. A1 is very, very unstable in windowed mode on macOS at the best of times. I often can’t command-option-new game properly, and the game frequently crashes when I switch into or out of windowed mode.

[ravenshining]

It doesn't seem to be a mere issue of unit conversion, rather, the math doesn't evaluate as cleanly as I would expect. For example, if I raise a floor 0.1 WU, and then lower it back down 0.1 WU, it winds up a sliver higher than where it started - just like Forge! Continuous floors are impossible atm, which isn't so bad for the map I wrote this for, but for most maps that'd be annoying, and would lead to exactly the sort of terrible maps Wrkncacnter would expect were I to release it publicly.

I tried simply making the height increment a variable called hinc, set to 0.1 in Triggers.init(). Now if I just type hinc = whatever into the console, I can change it on the fly.

[The Man]

Well, right. The problem is that you have 51.2 of the game’s internal measurements equal to 0.05 WU, which isn’t an integer value, and since the game expects an integer value, you end up getting 51, which doesn’t go cleanly back into 1024. 51 * 20 is 1020, so every .25 WU, you lose roughly 0.001 WU (more accurately, 1/1024 WU, which isn’t actually 0.001 WU, and that’s actually a way to restate our main problem). An increment of 1/8 WU is fine; even 1/16 WU or 1/32 should be fine. But a lot of people make maps based on .2 or .1 increment steps, which is where the issue comes up.

So that’s why I suggested calculating the height value based on a formula rather than by adding or subtracting 51 to the height each time (except that I said division, and now I’m not sure why; I think it’s actually a multiplication formula). The problem is that one out of every five 0.05 WU steps, you’re not going to want to increment 51; you’re going to want to increment 52. However, calculating that with a counter brings with it its own problems (to do it properly, I suspect you’d have to have a separate counter for each polygon floor and each polygon ceiling, and that’s just not worth it).

Hence why I suspect simply recalculating the height based on an unchanging formula is the best option. For instance, if counter is your variable, you could use ((counter * 51.2) + 32768.5), where counter can be shifted up or down by changing weapons. I chose 32768 since that’s (probably) the value of 0.0 WU, and .5 so that it rounds up when needed. 32,768 might not even be needed depending upon implementation; the .5 is probably ideal, though.

It should be possible to use another formula to ascertain what the counter variable should be based on the height or floor of a given polygon, but I’m too tired to figure that out right now. Might work it out tomorrow.

Apologies if any/all of this is obvious. I’m partially thinking out loud (well, OK, on the page – well, OK, the computer screen) too.

[ravenshining]

o.o Right, well, if you'd like to take a shot at refining the math, I'll PM you the script. Neither math nor programming is a strong suit of mine :-)

[The Man]

Thanks; I’ll take a look at it this weekend and see what I can come up with.

[treellama]

Setting floor/ceiling heights in visual mode is easily Forge's stupidest feature, which is why I didn't add it to Visual Mode.lua. Having a separate script makes more sense, that keeps all the geometry editing out of Visual Mode.lua.

[treellama]

Of course, my #1 and #2 feature requests for VML/Vasara are fixing the tag switch/platform texturing issues and implementing a way to keep existing alignment when you retexture a given wall.

VML lets you apply textures unaligned. It's in the control panel somewhere.