ZDoom

You know - with the transition in ZDoom development, that's actually not a bad idea. GZDoom could rename it to something else, and QZDoom could repurpose the variable entirely to contain all the various renderers into one accessible variable which can then be put on the menu appropriately. Then vid_renderer can be simply used to fool those old mods into running properly, regardless of the renderer setting being used.

[quote="Eruanna"]Exactly. It's like - why even bother letting the mod check for the renderer? It's pointless. And plus, people STILL like to do silly ugh-worthy death scripts like GF2 did. (No offense, Cutman)[/quote]
I did that on my "mod", the mod used alot of dynamic lights to make the map more "spooky", and since it was useless to software users, i just made the áreas near those static dynamic lights just more brighter...
But on the future since both renders (on zandronum) will have dynamic lights, I think the best thing to do is just to check if the user has dynamic lights on or off instead of the render.

edit:
what about about changing the software value to a new value? since it has so many stuff that will make the old render a 1994 toy (or just set it to 1)

We're not the ones pulling them straight out of Youtube and Twitch. :)

It's always nice to have some good additions to our community, but by the time they get here they usually know a thing or two about it. Even if they don't, they're smart enough to figure out how to ask for help.

I agree, and haven't done anything that extreme since, but I think you overestimate the common PC user. Many of them barely know how to extract a zip file (especially in this "touch" generation of hardware), let alone bother reading a README text file. There's a reason I had to make a simple launcher for my mod that creates a default ini file for you with recommended settings.

[quote="Cutmanmike"]I want to believe that. You don't know how many frustrated conversations come out of our dev chat about how we shouldn't add xyz because it doesn't work properly in software mode. :P[/quote]

No matter what, the engine requirements belong in a text file, not in an ACS script, and certainly not in one that nukes the game! It's bad that such things even need to be told!

[quote="Nash"]QZDoom's true colour software mode is making all this moot as time goes by, to be honest... dynamic lights already work in the TCR... all that's left is skyboxes and models (of which the drawer already exists and works), get Zandronum to adopt the TCR, and everyone will be happy. :D

Of course all this won't "just" be easy and fast but it all seems do-able already and modders don't need to come up with shithacks anymore in future...[/quote]

Don't forget the triangle drawer and/or flat/roll sprite implementations, if that can happen.

@Cutman: Worry not, I wasn't targeting you specifically, just what was done as an example. (At this point I can just make the player absolutely immune to instant death scripts at the drop of a hat. I can even make him impervious to ACS health-setting of 0.)

I want to believe that. You don't know how many frustrated conversations come out of our dev chat about how we shouldn't add xyz because it doesn't work properly in software mode. :P

Exactly. It's like - why even bother letting the mod check for the renderer? It's pointless. And plus, people STILL like to do silly ugh-worthy death scripts like GF2 did. (No offense, Cutman)

QZDoom's true colour software mode is making all this moot as time goes by, to be honest... dynamic lights already work in the TCR... all that's left is skyboxes and models (of which the drawer already exists and works), get Zandronum to adopt the TCR, and everyone will be happy. :D

Of course all this won't "just" be easy and fast but it all seems do-able already and modders don't need to come up with shithacks anymore in future...

This feature was rejected due to the inherent problems. Sorry for the bad tag, it should have been "No".

Sorry to bump this but I need clarification: Would this feature be enabled by default? Yes, people can abuse GetCVAR to do some dumb things to the player but I don't think it's worth playing around those stupid WADs. I've used GetCVAR recently to detect which renderer is being used to get around software visual bugs (y'know, bugs that no one wants to fix because the software renderer is bad) and A LOT of people who play my mod can't run openGL mode, probably more than you expect. I made [url=https://youtu.be/AwYAhisslq8?t=510]a boss fight that uses a ton of sloped 3d floors[/url], and after finding out they don't work in software mode I actually went and [url=https://youtu.be/DMXnwUZJDGw?t=116]programmed a second boss fight[/url] simply because there was no way they were getting fixed in software and I didn't want to abandon what I already created. If this gets implemented and is set to true by default, a lot of people are going to see a [url=http://imgur.com/a/nhsBU]buggy mess[/url] due to GetCVAR vid_renderer returning true in software mode.

Other than my own work I've heard of maps using GetCVAR with the renderer (and other settings) to do things such as changing skyboxes that don't appear correctly in software mode. I think having this enabled by default is a mistake, and for what, one really old bad WAD file that could easily be fixed with a patch wad or update/revamp? It just seems stupid for me to have to tell (or force?) players to disable this flag by default for all the current WADs that use GetCVAR in a positive way rather than the other way around if they want to play [i]specifically [/i]Ghoul's Forest 2 in software mode.

(The fact I'm the one who made GF2 and that dumb script feels like a cruel joke :ugeek: )

@NeuralStunner: Exactly.

It seems reasonable to do both: A user-level setting block [i]and[/i] an override file for old, non-updated mods known to be abusive. The former provides more proactive defense against new hacks*, while the latter avoids everyone having to reinvent the wheel, so to speak.


[size=85]* Provided the hack is innocuous enough: If a current in-dev mod is being actively abusive, shame on them.[/size]

[quote="Ed the Bat"]If it should still happen to be of any interest, I've made a revision for Ghoul's Forest 2 with the kill scripts removed, as per Eruanna's request.

If everyone decides that this all can/should be dealt with engine side, I'll scrap it.[/quote]
I think it should be kept, as the official ZDoom versions still will not have any changes engine-side to counter it. No sense in wasting time/effort if it's already done.

[quote="Major Cooke"]Engine side/user configurable please.[/quote]
Of course.

Engine side/user configurable please.