 |
Also, "this can be abused" is not an argument here IMO. Yes, the modders can check for models being turned off and make the game unplayable because of that. BUT. We already have ZScript, which is way more dangerous as to what modders can do with it. I don't think "protecting players from modders" works anymore. As for forward/backward compatibility, the function could default to returning true if feature id is not known, thus causing the same mod behavior as if it was unchecked, instead of breaking completely. Ports like Zandronum that lag behind could implement an "always return true" version too, until they get it right. |
 |
As-is - no, I will not support this feature because the playsim should behave exactly the same whether you have an 8-bit palette software renderer that supports absolute diddily, or if you're running with state of the art Vulkan with full shader support and all the fun effects (multisampling, SSAO, etc). Multiplayer and demos would break otherwise. What I *will* support is a simple "render-if" - where *all* code is executed - no matter what - but you only see the effects of an actor that's designated to show in the 8-bit renderer, or the true-color renderer, or the OpenGL one. |
|
|
>I will not support this feature because the playsim should behave exactly the same We are going low level with ZScript, and we are already expecting the modder to know what they are doing, so it should be modder's duty to put +NOINTERACTION in such cases. As for the demo support if you are worried about that, the feature set that was used _during recording_ could be stored in the demo for 100% reconstruction, as well as global override during networked games (although do note that networked games are ALREADY broken). If things will break for the players as the result of feature set not matching their actual one — well that's their problem already. The demo/networking should warn that it may not look as expected. "Renderer-if" sounds like another gross hack construct in the language that serves no other purpose other than limit modder's abilities to perform modding, in the end frustrating both the modder and the developer that has to support all that stuff later. Besides, it may not be related only to rendering. Think mods that support both GZDoom and Zandronum. For example, they would be able to check for something like FT_ACS_281 (ZDoom 2.8.1 acs feature level), and if this is not available, use their own (often slower or hacky) ways to do stuff. |
|
|
I don't understand how can we at the same time implement the all-powerful (by definition) scripting language and still limit modders' capabilities by developer's view on how it should be done. Remember: the developer won't always be there to deal with all the edge cases. If this is done like you suggest, people can and will continue to write terrible, unobvious, deprecated and backwards incompatible code and essentially the engine will have to support these hacks forever, as removing them would mean that "mod X is no more supported". As for the "playsim should never change": we already allow changing the playsim based on arbitrary uncontrolled values out of the space by allowing user CVars, and by allowing to query NON-USER CVars which are not always stored in the demo. |
|
|
Just because GetCVAR was badly implemented does not justify breaking a broken situation further. GetCVAR should be fixed and it is one of the things I had been planning on doing. |
 |
You cannot fix that part. GetCVar is obsolete anyway beyond user variables and there's more than enough options to query stuff that's not synchronized. I cannot restrict CVar access because other parts of the engine, like the statusbar or menu need access there, and it's impossible to tell if code is demo-sync-critical or not at compile time. |
|
|
Please don't ignore the rest of my post: what's wrong about force-synchronizing feature sets over demos and networking? And what will we do about it later? The more code is zscriptified, the higher probability of demos breaking there is. This is because ZDoom has broken demo mechanism by design; for proper demo mechanism, see Zandronum which essentially dumps the server packets to the disk, and as such it always reproduces things exactly the way they were first behaving, without any ways to desync. The procedural demo playback is very good, but — for small and simple engines like PrBoom, not as feature-rich as GZDoom. |
|
|
In the long term we can probably look at something like this, if the network code ever matures past its current state. For right now, though, the deterministic model is all we have, and it should be followed as much as possible, even if it's not 100% up to par right now. I am going to go ahead and close this issue because it is not worth an argument that will ultimately devolve and upset everyone involved. I am sorry, but that's not what the tracker is for. If you want to debate this, please bring it to the forum, instead. |
- Anonymous
