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:

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:

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:

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:

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.

$lave wrote: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.

Last edited by Wrkncacnter on Dec 27th '18, 21:12, edited 1 time in total.

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.

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.

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.

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.

“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

Wrkncacnter wrote: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.

Wrkncacnter wrote: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.

The Man wrote: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.

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.

“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

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.

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.

“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

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

“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

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.

The Man wrote: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.