Speaking of which, how long more do we have to wait for Doomscript?Gez wrote:Then WFDS I guess

Moderator: GZDoom Developers
Speaking of which, how long more do we have to wait for Doomscript?Gez wrote:Then WFDS I guess
I guess, another 8 years, but I really want it!ArcheKruz wrote:Speaking of which, how long more do we have to wait for Doomscript?Gez wrote:Then WFDS I guess
Because using tags to do that is better of course..Gez wrote:The idea of having gameplay mods that mess around with lines and sectors in maps which weren't specifically designed for them sounds like a recipe for undefined behaviors and game-breaking bugs.
I think that's just your opinion.Graf Zahl wrote:Without detailed knowledge of the map such access is utterly useless.
I don't think I would call that "cleaner".GooberMan wrote:You know what would be cleaner here? A script that activates once for each sector. Like a new SECTORINIT script type. And then you could get the sector's tag, and if it's zero then you can set it to any unused tag. Say, for example, starting at the minimum value (0x80000000 for 32 bit - chop off the 4 extra zeros if it has to be 16 bit) and checking if that tag is taken and then assigning if it is not.
You should get out more.Korshun wrote:I haven't seen a single mod that uses negative tags.
You don't. And that's not a bad thing.Korshun wrote:Without it, how do I make a day/night/weather system that correctly restores sector properties back to original without manually setting tags for hundreds of sectors and inevitably making mistakes?
Rubbish. A tag provides a (non-)unique identifier for a sector/line/actor. The only thing providing additional information about the sector is the scripts you write/line actions you set to support it.Korshun wrote:And that's no different from individual access, just worse, because the "tag" field could have been used to provide additional information about the sector.
Welcome to several posts ago.Korshun wrote:Any sector can have any vars set
Then you're also not thinking it through. A script function that lets you analyze a sector on initialisation and decide what you want to do with it? Cleaner, more flexible, and less error-prone than giving direct access to sectors through a half-assed ill-informed modification to the tag system.Leonard2 wrote:I don't think I would call that "cleaner".
GooberMan wrote:You should get out more.
How did you implement support for changing light level, color and fog on about 1000 sectors and then restoring their original values? Like, I have a sector gradient light on a street, and it needs to get brighter as the sun rises, and then get darker, but not less than its original value. To implement this in the original system, I need to manually tag every such sector with a different tag for every light level, and what if I have some areas that sometimes get foggy? Now I need to double the amount of tags. Considering that there would be about 200 such sectors, and a lot of tags, it's easy to mix them and end up in bugs. Individual access to sectors fixes all the problems here. Just mark all street light sectors with one tag and make a script that changes and restores all needed properties.GooberMan wrote:Both myself and Nash have separate day/night/weather systems. What's the problem? You're clearly not thinking it through. You have no problem setting a sector's properties to give it nukage damage, but a tag for a lighting effect is a bad thing?
Sector/line/actor numbers need to be NUMBERS only because everything is a number in ACS. If that was DoomScript, they would be object references. Also, what was the last time a sector or line number changed during the game?GooberMan wrote:It also hides the fact that a sector/line/thing number can change underneath the system.