Reshuffling thing numbers?

Just need to say I luv DB. It is the editor with everything one could possibly want.

I have a feature suggestion though.

I make some maps for Zdaemon predominately. They're attempts at making maps for DM, Coop, SP all at once.

One of the problems with making for Zdaemon is sometimes when working with a big map with lots of decorations and stuff is the server doesn't display things that are higher on the thing number list.

EX: You're running in a net game and you bump into a torch that you didn't see was there because its thing number was all the way up to the 300 range - so Zdaemon didn't display it.

What I want in Doom Builder is the ability to reshuffle thing numbers automatically to where some things are numbered first and others are numbered later.

Keys being the first thing numbered, then items should be next, then decorations, then monsters - The reason why monsters should be last on the list is 'cause once monsters start moving they're updated on the server and become visible. Then after all the visible things become numbered the invisible things come last - Such as player starting points, map spots, bridges, environment sounds and such.

I do this myself for problems my maps have when they don't display things properly. For instance I take a Player 1 starting point and turn it into a key and then turn the key into a player one starting point. However I would much rather the editor do it for me.

I know this is really a Zdaemon issue and I'm going to mention it on there, but I figured I should first suggest for the author of my favorite map editor*kiss up*to add some simple reshuffling code to his editor then suggesting an improvement to complicated net code.

Also I would like for the editor to have a 'next unused' key for linedef identifications. Like it does for sectors and things.

Well the *kiss up* was nice, but I'm afraid I'll have to answer your question with the answer you actually have already given yourself:

It's a ZDaemon problem. The index of the things may not matter in Doom. It never has. And since I'm very cautious with adding new stuff to Doom Builder (because I don't want to clutter it any more with 'useless' features) I'm not going to add such a feature in there.

Your second question is somewhat odd. Linedefs don't have tags like things and sectors do. What should the 'next unused' button do there?!

"because I don't want to clutter it any more with 'useless' features"

I wouldn't suggest it if I thought it wasn't gonna be used.

"Linedefs don't have tags like things and sectors do."

Linedef action number 121. Called 'H linedef identification'

It has a thingy called 'line id' beside it. You can use scripts to referance those numbers.

they're hard to keep track of if you have a lot of them.

CodeImp said:

Your second question is somewhat odd. Linedefs don't have tags like things and sectors do. What should the 'next unused' button do there?!

Scan all linedefs for types that reference a line ID and find the first number that hasn't been used. Of course this requires that all special arguments have a proper type.

Doorhenge said:

I wouldn't suggest it if I thought it wasn't gonna be used.

I suggest to bug the ZDaemon team to fix their piece of crap. Having problems like this is really pathetic.

Adding workarounds for such a thing to an editor would mean to do special work for one very specific problem in one particular source port. I'm sorry to say but you won't have much success with such requests anywhere because all people would say is to get the problem itself fixed.

Doorhenge said:

Linedef action number 121. Called 'H linedef identification'

And I have had just about enough of these hardcoded exceptions upon variable settings. Linedef action 121 is not the same thing for every sourceport and even if it was, there is a reason why it and its properties are variable.

So use the information from the config file to determine the kind of argument. If clearly marked you can find any sector tag and line or thing id just by looking through the arguments of the respective type and then set the first one that isn't used. I once have written a tool that lists all tags and id's that are being used in a map and at no point I had to hard code any specific knowledge about certain line special types. All I needed was a list of specials with the types of each argument, i.e. the engine configuration you already have.