by Tesseract » Sun Sep 08, 2013 5:20 pm
Okay, so it seems that our final question is, WFDS or implement this as a flag?
DoomScript is, indeed, ultimate answer to all world's problems and most likely would allow to handle these options. As a coder I understand that needless addition of another feature is inefficient and makes maintainance difficult. Despite that, here are few points favouring flags:
- I don't know DS specifications, not even sure anyone besides Randy do - so if you know more, please correct me on this one. I think that DS will be primarily C-like thing that substitutes/extends/unites Decorate and ACS. Full addition into special lumps wouldn't have much use, would be SBARINFO exception? It was designed to be simple, lightweight scripting lump that can't affect game state in any way, ensured by finite amount of own functions and lack of variables. These properties allows for example easy hud switching when loading games, and such advantages can't be seen in potential full, non SBARINFO based DoomScript huds, which are just evolution of ACS huds. So it's possible that it won't be changed much for sake of simplicity.
Even if SBARINFO would get DS additions that only offer passive information retrieval, question is how difficult would be to replicate these flags there. Code would be certainly longer and with multiple conditionals. That's not a problem if such flags would be used in one or two huds, but if they would be in like 75% of them, flags are more optimal.
Lastly, WFDS over the years started to look like "When it's done" from 3d Realms, leaving similiar aftertaste. As common Zdoom player, I see it as distant as it was decade ago. To say it pragmatically, I'd like to get my hud working in official releases before 2025. Indeed, it won't be added for one modder, so I think real question is how many hud creators would use these flags.
Therefore, my final opinion on this matter is this:
It was already demonstrated that features offered by these flags can be useful. If sufficient amount of modders would like to use them, to the point that their usage would be common practice or almost standard in some kinds of huds, it's better to make them flags, available right now and easy to type. On the contrary, if they'd be obscure choice used in bare minimum of cases, DoomScript is much better option.
Blzut, if you came to the same conclusion, I'll leave it to modders' consensus, maybe even start a poll or something. We can discuss how many hud creators would be sufficient to justify this addition. I'm just concerned if enough hud creators would actually read this thread.
Also, would your answer be enough or should I wait for Graf's opinion about this voting too?
In case this will be approved, I think I'm going to code it after all, shouldn't be too hard.
Spoiler: Slightly offtopic babble
Blzut3 wrote: I'm still not entirely sold on the idea of the flags since ZDoom lacks a whole lot of "cross modding" features. I'm sure with little effort you could come up with a dozen examples of little paper cuts that prevent mods from working seamlessly with others (not limited to status bars).
It's true that ZDoom lacks a lot of cross-mod features compared to say Unreal Engine, but on a same time it's not bad enough. I'm still suprised I've got Brutal Doom working with KDIZD with no major issues, and got very enjoyable afternoon with it. Sure, little "paper cuts" may appear, but if mods are well written and if no serious actor name or script number collision occurs, many mods are perfectly playable together. And HUDs, due to their passive nature and being part of interface, are especially susceptible for (mis)use in another mod.
Blzut3 wrote: Actually it wouldn't be entirely unprecedented. DrawSelectedInventory has flag to execute a sub block if nothing is drawn. If you choose to implement something like this be careful though, drawswitchableimage hangs off of the drawimage code.
Thanks! I must have read about this one, but I completely forgot about it. Very useful indeed!
Okay, so it seems that our final question is, WFDS or implement this as a flag?
DoomScript is, indeed, ultimate answer to all world's problems and most likely would allow to handle these options. As a coder I understand that needless addition of another feature is inefficient and makes maintainance difficult. Despite that, here are few points favouring flags:
[list]
I don't know DS specifications, not even sure anyone besides Randy do - so if you know more, please correct me on this one. I think that DS will be primarily C-like thing that substitutes/extends/unites Decorate and ACS. Full addition into special lumps wouldn't have much use, would be SBARINFO exception? It was designed to be simple, lightweight scripting lump that can't affect game state in any way, ensured by finite amount of own functions and lack of variables. These properties allows for example easy hud switching when loading games, and such advantages can't be seen in potential full, non SBARINFO based DoomScript huds, which are just evolution of ACS huds. So it's possible that it won't be changed much for sake of simplicity.
Even if SBARINFO would get DS additions that only offer passive information retrieval, question is how difficult would be to replicate these flags there. Code would be certainly longer and with multiple conditionals. That's not a problem if such flags would be used in one or two huds, but if they would be in like 75% of them, flags are more optimal.
Lastly, WFDS over the years started to look like "When it's done" from 3d Realms, leaving similiar aftertaste. As common Zdoom player, I see it as distant as it was decade ago. To say it pragmatically, I'd like to get my hud working in official releases before 2025. Indeed, it won't be added for one modder, so I think real question is how many hud creators would use these flags.[/list]
Therefore, my final opinion on this matter is this:
It was already demonstrated that features offered by these flags can be useful. If sufficient amount of modders would like to use them, to the point that their usage would be common practice or almost standard in some kinds of huds, it's better to make them flags, available right now and easy to type. On the contrary, if they'd be obscure choice used in bare minimum of cases, DoomScript is much better option.
Blzut, if you came to the same conclusion, I'll leave it to modders' consensus, maybe even start a poll or something. We can discuss how many hud creators would be sufficient to justify this addition. I'm just concerned if enough hud creators would actually read this thread.
Also, would your answer be enough or should I wait for Graf's opinion about this voting too?
In case this will be approved, I think I'm going to code it after all, shouldn't be too hard.
[spoiler=Slightly offtopic babble][quote="Blzut3"] I'm still not entirely sold on the idea of the flags since ZDoom lacks a whole lot of "cross modding" features. I'm sure with little effort you could come up with a dozen examples of little paper cuts that prevent mods from working seamlessly with others (not limited to status bars).[/quote]
It's true that ZDoom lacks a lot of cross-mod features compared to say Unreal Engine, but on a same time it's not bad enough. I'm still suprised I've got Brutal Doom working with KDIZD with no major issues, and got very enjoyable afternoon with it. Sure, little "paper cuts" may appear, but if mods are well written and if no serious actor name or script number collision occurs, many mods are perfectly playable together. And HUDs, due to their passive nature and being part of interface, are especially susceptible for (mis)use in another mod.
[quote="Blzut3"] Actually it wouldn't be entirely unprecedented. DrawSelectedInventory has flag to execute a sub block if nothing is drawn. If you choose to implement something like this be careful though, drawswitchableimage hangs off of the drawimage code.[/quote]
Thanks! I must have read about this one, but I completely forgot about it. Very useful indeed![/spoiler]