Lobo
Doomer
Posts: 594 
|
Post by Lobo on Oct 4, 2020 2:49:09 GMT -5
We would like to replace all normal doors in a map with a two-sided linedef that has a special Action/Type.
We need a LUA script that:
1. Merge 2 lindefs (anything with "Action 1:dr door open wait close" which are in close proximity i.e 8 units between them), thus deleting the sector.
2. Move the merged single linedef 4 units to center it.
3. Change the linedef action to 546 (or another type).
4. Make the front and back sector index of the linedef match the current sector where the linedef is.
5. Apply texture "NZUD12" to both sides as a middle texture.
OR alternatively
1. Deletes a door sector(anything tagged "Action 1:dr door open wait close")
2. Move and merge the 2 orphan linedefs that are left. Preferably to a center point between both.
3. Change the linedef action to 546 (or another type).
4. Make the linedef 2-sided.
5. Make the front and back sector index of the linedef match the current sector where the linedef is.
6. Apply texture "NZUD12" to both sides as a middle texture.
Can it be done with LUA scripting in DB.X?
We're talking about 111 maps and a shitload of doors in each map. Not feasible to do it manually.
|
|
40oz
diRTbAg
Posts: 6,107
|
Post by 40oz on Oct 5, 2020 14:31:58 GMT -5
Sorry, wish I could help you with that. My area of expertise lies more in sectors/linedefs and mapping principles than in the programming languages developed by source port creators. Based on the list of commands you've described, it sounds like it is functionally possible but I wouldn't be able to tell you how to do it or even where to start.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 6, 2020 5:44:33 GMT -5
See attachement:
DoomBuilderX version: 2019.1 , the released one
I have not figured how to delete a sector or merge linedefs in Lua API for DoomBuilderX, it seems these features might not be avaiable (the latter seems to be defined in source code, but is not accessible despite that, and I never found the definition for the former). So I had to do it differently, the algo is: 1. Identify all "door" sectors on the map. A sector is said to be a "door" sector if it has a tag, and has exactly two linedefs bordering it that both have the same tag and their action is set to "1". (See as_door(...) function)
2. For each identified door, merge its sector into adjacent sectors (this action removes both linedefs), that is, adjacent via linedefs with that door action.
3. After that, one pair of vertices (from one linedef we just removed) is deleted, while the other pair of vertices is moved to new coordinates (so that they are placed alfway through between the two linedefs, even if they were not actually parallel and regardless of whether they are orthogonal to grid or not). 4. A new linedef is drawn through the remaining two vertices which were moved. This action automatically splits the sector into two and so makes it double-sided, the script joins them back together so that the sector on both sides is the same (did I understand you correctly?). 5. This new linedef is then set action = 546 and both its sidedefs have their middle texture set to "NZUD12"
I noticed a thread on doomworld exists, is it also you or another guy? His task is a little bit different and requires a bit more coding on top of what I had already done (to set each sidedef to different textures, and have that texture determined from original ones on each door side). It is also possible to do this, but you did not request it, and I had rough enough time with both Lua and the absence of any documentation on DoomBuilderX (also, anotak seems to have left Doom behind?!). I've downloaded source code for DoomBuilderX from github's repository and used it to find what the hell is actually possible to do, and quite honestly, the API is really infuriating.
Backup all maps you are going to use this on, as it's quite possible there are some oversights (doors that shouldn't be converted errounesly covered by the current logic) or fuckups. The script also aborts with error if some unexpected things happen, if that happens, I might not be able to find a workaround without seeing a map. Also, I didn't actually test in on an EDGE map. Aso, if the format is actually UDMF, it is quite possible there is more stuff to keep in mind (never used UDMF).
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 6, 2020 5:59:41 GMT -5
Turns out there is a wiki on github, which may or may not be up to date on Lua API. But too late for that, I wrote that shit anyway. As for the source on anotak withdrawing from Doom, see github.com/anotak/doombuilderx/issues/21 |
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 6, 2020 9:08:37 GMT -5
holy shit @vigilantdoomer
Thank you so much! Can't wait to try this later!
I was messing with this last night and came up against the same issues you had.
The thread on the other forums is from the guy who actually needs this: I'm just helping out by cross-posting on other sites (like this one) and I originally defined the problem (he"s not a native english speaker and doesn't map too much).
As for the other texture stuff, I can probably figure that out from your script: the major issue is what you have solved(deleting sector and adding the new linedef).
Thanks again! I'll let you know how it goes.
|
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 6, 2020 9:23:48 GMT -5
The map format is just normal doom format. With my own experiments, I had gotten as far as changing the textures and the action type, and tonight I was going to try sector merging as a solution: like you said, there is no way to delete sectors any other way. What I couldn't find was a way to redefine the lines front and back sector, which was what I needed for how I was trying to do it last night. Anyway, dying to try this out later. CeeJay(the other guy) will be really happy. It's for his wolfenstein mod: basically wans to replace all the vertical doom doors with horizontal slider doors. If you're interested, this will be the test case basically: www.moddb.com/mods/wolfenstein-3dge |
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 6, 2020 12:20:43 GMT -5
It's not working. I've been trying to tweak it to see what's wrong but can't find where it's failing.
One thing I have changed is that you seem to assume that the doors will be tagged sectors, but the map I have here, none of the door sectors are tagged. I edited that part out and then the script ran a bit more but still does nothing.
I'm testing it against map E1F1 from the moddb link above.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 6, 2020 21:08:09 GMT -5
Lobo, I only now figured how to get the mod, because the original link you posted points to an article section, it has a lot of mods announced, while the file link is easy to confuse with entire moddb downloads section, which is what I have clicked until now (so I was very confused about how to get the file). Also, I have experience with mapping only for vanilla/limit-removing, doubtless there are other incorrect assumptions in my code, I will have to dig mod myself to understand how to get working code against it. Will post once I look inside, hopefully soon.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 6, 2020 21:18:34 GMT -5
Yeah, script seemingly hangs up (never finishes executing, and interrupting it of course cancels any action it might have done). That is, after assumption about tag is removed. This is really surprising, I expected bugs, but it is simply infinite cycle which is also not detected with check I left in there.
Now that I've got map at least (although not yet configured edge), maybe I could try fix script against it.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 6, 2020 21:31:18 GMT -5
The culprit for hangs, like expected, is vertex_pair_in_order, and this function already drove me nuts when I was writing it. Its idea is actually identifying which order of vertexes on one linedef matches the one chosen for the other, so that I am actually calculating middle line between the two later, and not some crossover with vertices opposite each other. Looks like I never got it right, it had problems before but I fixed it for my tests, and still it is not working here.
Also, it was written with mind that door linedefs are not necessarily orthogonal to the grid; some other approach (may be simpler, or just different) is possible.
!!! WAIT !!! Since you allow non-tagged sectors, it interprets that sector around a door as a door itself - it ends up having two linedefs with action 1, just like door, except this sector is discontinous and has more then two non-action linedefs. So you can't just remove tag from that function, you have to implement some other check to distinguish doors from neighbouring sector to which those linedefs also belong, but don't act upon it. I guess the check should be which direction the door is facing relative to the sector.
Thus that function hangs because it never was supposed on something not a door, and a lot of non-doors get picked like doors and the logic explodes.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 6, 2020 21:39:13 GMT -5
Here is a working script for ya. I didn't test it in Edge after it run (no did my Doom Builder X even get the resource right), but this one certainly does something on E1F1. I removed the tag = 0 check, and added check that linedef has "door" sector as a back sector for it to count as a door.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 7, 2020 3:10:42 GMT -5
Here is the final (for now) version of the script:
Which is based on bugfixed version (accept zero tagged doors but don't confuse a neighbouring sector for the door itself) above in my previous post, and also puts middle textures based on what the upper textures on original doors were. The direction is expected to match, although hard to test for me, because the editor does not load any textures from your mod. They do work in game though, I have completed the first level with sliding doors. It seemed familiar... (haha, never palyed the original wolfenstein, but I figure know that map31 from doom 2 is apparently the very fist map in wolfenstein).
However, I should warn that if any doors with action type 1 are occasionally used for walls (not sandwitched like proper doors would be), they may be accidently converted. I see that you have some openable walls but those fortunately used a different action type... so, basically, if you ever used action type 1 on something unusual, the script might need to be adjusted even more.
P.S. I changed script architecture a bit, now action and texture assignment is done inside squish method, not outside of it. I thought, I might have to figure linedef orientation on a case by case basis, but it looks like it was unneeded, as the formula is really the same in every case, for the new linedef is drawn in the direction that matches direction of the "first" encountered acion linedef for this door. (I get confused every time about directions since I've chosen to remove vertices from the first original linedef and instead move vertices from the second original one, which has an opposite direction... basically, I should have written the code more clear, but at the time of writing I was really going nuts with all the obstacles the Lua and limited Doombuilder X API threw at me, so I was just happy that it worked at all)
|
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 7, 2020 7:19:57 GMT -5
You are a GOD amongst men!
I'll give it a try tonight and let you know how it goes. I saw you'd even discovered hidden methods not on the wiki!
Again, thank you so much for this.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 7, 2020 8:03:43 GMT -5
Lobo, I was happy to help since I am much better at programming than mapping. I only wish you tried stuff out before you give compliments, cause it feels really awkward (although not together unexpected) when things actually break after you seemingly told everything is great. I only run one map after conversion (wanted to try out those sliding doors), the other I kinda looked at in editor before and after... this Edge port looks surely interesting, I gotta say. I hope this time it will be good though. I didn't expect your doors are going to be orthogonal (rather than potentially angled like Doom engine allows) when I first wrote it, so some of the code (talking about vertex_pair_in_order) is unnecessary complex for the task. You can see that by the time I got to create a new linedef I got pretty agitated, so one of the function was called draw_fucking_linedef, because I really happened upon much shit before that point already. With orthogonal doors it would also be much easier to check for distance between door linedefs - which I never did by the way - although it is possible to write this code for general case as well. As for the 'hidden methods', I cloned git repository of entire doom builder x source code, and looked at it directly. The code responsible for Lua plugin can be seen at this link online otherwise: github.com/anotak/doombuilderx/tree/master/Source/Plugins/WadScriptyeah, the plugin's development name is "WadScript". And there you see files like "LuaSidedef.cs", "LuaLinedef.cs", etc. - so you can see all methods and properties that are defined, as well as the implementation of these. What's interesting there could have been a method for joining two linedefs, but it is commented out. The plugin's source code was found by me by just searching the dbx's source code for lua stuff, since error messages tell some info about how classes are called, etc. I decided to look at the source since I couldn't find documentation at the time, and one can only get so far with the examples found in dbx release folder.
|
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 7, 2020 16:12:17 GMT -5
@vigilantdoomer So this time I waited to give it a good testing and also the other guy who is actually gonna be using it more than me. Working great! I edited and added some stuff specifically for what we want to do, since we also had to take into account sliding doors that need keys (fortunately only blue and yellow) and thus had to create some custom line types since stock Edge didn't have that. Also, things got a bit simpler since Edge is so smart it automatically mirrors the texture on the other side of the slider, so I made it that front and back use the same texture. An oddity I found was that sometimes the new slider line is facing left and other times right(or up down), even consecutive runs on the same map! Kind of random, not sure why it happens: maybe it depends where you right click to activate the lua script? This means that sometimes the textures are wrong, so I added some code to make sure that the slide direction is always correct changing it depending on the texture (we don't care which way front is, just that the texture for left sliding corresponds with left sliding and so on). Let's see what else: just that I edited your door class to also *remember* the original linedef.action, so that later I could detect the yellow and blue key doors. Finally draw_fucking_line() is an epic name for a function  Again, thank you so much for this, from me and from CeeJay. I am trying to add my edited version as an attachment but keep getting and error... Attachment Deleted |
|
|
|
Post by ceejay on Oct 8, 2020 2:58:15 GMT -5
Thank you so much for your help, vigilantdoomer and you too Lobo.The finished script worked without a hitch, plowed through 60 levels last night and playtested about 40 of them. Certainly not a big deal or anything (hell, it took me awhile before I even noticed it) but I did spot this oddity  Not sure what is going on there, it happens at every converted sector. I can not see anything on the map editor. The other side facing it looks normal. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 8, 2020 8:02:52 GMT -5
One of the linedefs is always X texture offset = -28, the other = 0. Before the conversion, linedefs were length = 28, now they are length = 32, but the offsets remained unchanged, since the script never touched them (no code was written to address this, it just didn't occur to me this is needed). Perhaps the problem is solveable by adjusting offset, I suspect it should be -32 now. This likely can be done in automated fashion (via another script), too, and doesn't require you to start over, just search for that specific offset, maybe verify the sector hosting this linedef has this new kind of door (if run against the maps that were already subject to conversion).
P.S. X texture offset can be changed via accessing "offsetx" integer property of LuaSidedef object. There is already code in the previous scripts that shows how to get sidedef (front or back) of a linedef.
|
|
|
|
Post by ceejay on Oct 8, 2020 8:58:07 GMT -5
I was looking at that earlier and wondering if that had something to do with it. It is now confirmed, texture offset -28 should be -32. Which makes sense when you think about, since the texture is 64x64 and split up in two parts.
Is it possible to add this to the existing script ?
|
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 8, 2020 11:46:18 GMT -5
I'll take a look. Not saying when though 😉
But hold off for now doing more maps till I update the current script.
|
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 8, 2020 17:02:11 GMT -5
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 8, 2020 20:54:21 GMT -5
Just for posterity, here is the new script which also changes the offsets: View AttachmentAnd it changes every offset X = -28 it finds on the map, wherever it finds it, I see. Well, it might just work with your maps indeed. As for random direction of new linedefs, that's because there is no attempt to determine which of the two original door linedefs should be the first or the second, the direction of a new one depends on the direction the "first" encountered one (when enumerating all linedefs of a sector) was facing, since that's non-deterministic, the results are too. Undoing and thus recreating old linedefs may not necessarily restore the original state in all details as well, it might actually internally store sector's linedefs in a different order, or maybe simply enumerating sector's linedefs is not deterministic anyway. It is possible to make a deterministic choice, if some rule is devised, such as "new linedef should be facing south/west" (or north/east). |
|
Lobo
Doomer
Posts: 594
|
Post by Lobo on Oct 9, 2020 0:21:27 GMT -5
I know it could have been done more elegantly, making sure it's connected to a slider. But it was late and I was tired (been running on 4-5 hours sleep all week) and from what I see, for this particular mapset it works.
Again, big Thank you for all the work you put into this!
|
|
