Warning in software mode

[esselfortium]

I'm surprised no one (explicitly) gave the real answer to the question: "Don't do it."

The capabilities of the software renderer can, and have, expand in the future. Giving an obstructive warning now may not make sense in the future (no matter how unlikely it would be). Case in point being 3D floors. Just put a note in the txt file, if people don't read it, that's their problem.

This is why we don't have an official way to check renderer, port, or port version. It's too easy to make false assumptions. (Also, software users don't care about high resolution textures being down sampled to the Doom palette.)

I cannot stress enough how important this is. It is fully intentional that GZDoom does not have a definitive renderer check because all it would do is cause problems (both ways actually; some people mistakenly thinking that their mod won't work with GL and others assuming that software will never provide the feature set they need.)

At some point it just has to be RTFM and if some idiots stubbornly ignore that I don't see why I should make it easier for them.

Okay but what if someone's mod literally doesn't work in GL and they're not an idiot

SpaceDM9, last I checked, performs wholly inadequately in GL (at the least, it does so in Skulltag, which is the required, intended port), and yet no matter how many times I mentioned in the release thread and textfile that it needs to be run in software, a whole lot of people missed the memo and played in GL anyway, getting a rather broken and unintended experience without even realizing it

edit: Comparison shots. In GL it looks like somebody turned off the power grid. (And more importantly, in GL it runs at about 5 frames per second.)

[Enjay]

I guess it depends how much you want to wipe people's backsides for them.

[Graf Zahl]

Okay but what if someone's mod literally doesn't work in GL and they're not an idiot

SpaceDM9, last I checked, performs wholly inadequately in GL (at the least, it does so in Skulltag, which is the required, intended port), and yet no matter how many times I mentioned in the release thread and textfile that it needs to be run in software, a whole lot of people missed the memo and played in GL anyway, getting a rather broken and unintended experience without even realizing it

edit: Comparison shots. In GL it looks like somebody turned off the power grid. (And more importantly, in GL it runs at about 5 frames per second.)

Even though some mod may currently not work in GL it doesn't mean it will never work in GL. Maybe someone finds a solution for the specific problems that cause glitches at the time of release later. Maybe it's just a bug that can get fixed or whatever. So if you stick your stupid warning into your mod you are about to screw it up for all time.

BTW, your SpaceDM9 looks fine for me in GZDoom (at least I haven't seen any glitches that render it useless) so there's a good chance that at some point in the future it will work in Skulltag with hardware rendering.

I guess it depends how much you want to wipe people's backsides for them.

Indeed. Why be so anal about shoving this info down your users' throats. If people persistently refuse to read manuals there's really no point in making more intelligent people's life miserable just to make the idiots happy.

[esselfortium]

Okay but what if someone's mod literally doesn't work in GL and they're not an idiot

SpaceDM9, last I checked, performs wholly inadequately in GL (at the least, it does so in Skulltag, which is the required, intended port), and yet no matter how many times I mentioned in the release thread and textfile that it needs to be run in software, a whole lot of people missed the memo and played in GL anyway, getting a rather broken and unintended experience without even realizing it

edit: Comparison shots. In GL it looks like somebody turned off the power grid. (And more importantly, in GL it runs at about 5 frames per second.)

Even though some mod may currently not work in GL it doesn't mean it will never work in GL. Maybe someone finds a solution for the specific problems that cause glitches at the time of release later. Maybe it's just a bug that can get fixed or whatever. So if you stick your stupid warning into your mod you are about to screw it up for all time.

BTW, your SpaceDM9 looks fine for me in GZDoom (at least I haven't seen any glitches that render it useless) so there's a good chance that at some point in the future it will work in Skulltag with hardware rendering.

I guess it depends how much you want to wipe people's backsides for them.

Indeed. Why be so anal about shoving this info down your users' throats. If people persistently refuse to read manuals there's really no point in making more intelligent people's life miserable just to make the idiots happy.

I'm sure all the people who worked on CChest3 had this same attitude a few years ago when a bunch of Skulltag users voted their work 0 stars on /idgames because the "scripts don't work".

Nearly a year after SpaceDM9 was released for Skulltag, it still doesn't work correctly in GL in the latest official Skulltag version. This gets blamed on me, not on the renderer.

[zap610]

Why be so anal about shoving this info down your users' throats. If people persistently refuse to read manuals there's really no point in making more intelligent people's life miserable just to make the idiots happy.

It's okay to force users to play your port in a specific way but not okay to do the same for projects?

[ALMN]

Nearly a year after SpaceDM9 was released for Skulltag, it still doesn't work correctly in GL in the latest official Skulltag version. This gets blamed on me, not on the renderer.

You provided the product, the renderer renders your product bad, it's your product acting bad, it's your fault!

Why be so anal about shoving this info down your users' throats. If people persistently refuse to read manuals there's really no point in making more intelligent people's life miserable just to make the idiots happy.

It's okay to force users to play your port in a specific way but not okay to do the same for projects?

:almn:

[entryway]

Even though some mod may currently not work in GL it doesn't mean it will never work in GL.

But you are not working on GL renderer any more. So probably it will never "work" forever

So if you stick your stupid warning into your mod you are about to screw it up for all time.

That's because I want to check vid_displaybits for 8bit. WAD is not intended to be played in 8bit and even God is not able to change it. Never!

Also it is not intended to be played in ZDoom 2.5.0 or earlier. It just does not work as intended there and even God is not able to change it (but zdoom authors still are able to break it in future future versions :trf:) So checking for min. version is also makes sense. At least for ports with scripting abilities and stormy development.

Personally for me, I agree with you (I think mentioning in txt is enough). But mods authors are more painful about their projects often. They even hate "change gamma" ability heh. You are not able to understand and accept it, because you are technician

[Graf Zahl]

I'm sure all the people who worked on CChest3 had this same attitude a few years ago when a bunch of Skulltag users voted their work 0 stars on /idgames because the "scripts don't work".

Nearly a year after SpaceDM9 was released for Skulltag, it still doesn't work correctly in GL in the latest official Skulltag version. This gets blamed on me, not on the renderer.

The sad thing is that idiots being idiots (and Skulltag seems to be full of them as your examples show) you can try what you want - they still are stupid and do stupid things. So if you take one potential issue out of the equation they just jump onto the next one (which in this case would most likely go along 'Oh geez, this esselfortium is sooooo stupid and makes a map that can't be played with real grafix!!!')

In my opinion the only thing to do with this braindead types is to ignore them.

Even though some mod may currently not work in GL it doesn't mean it will never work in GL.

But you are not working on GL renderer any more. So probably it will never "work" forever

Things can change. I may get motivated again or someone else may come along. The main reason I don't work on it anymore is that my job doesn't give me enough free time to work on other projects and I really don't need to spend my weekends programming, too.

That's because I want to check vid_displaybits for 8bit. WAD is not intended to be played in 8bit and even God is not able to change it. Never!

That may be but since you can't check the actual graphics mode with it it won't help you. Even in ZDoom it does *NOT* do what you seem to think it does (in fact when using the D3D video mode it's also completely ignored and when using DDraw it only specifies the mode the hardware is set to. So in other words: This CVAR doesn't tell you anything whatsoever. If it's 32 it can still be a software renderer

Also it is not intended to be played in ZDoom 2.5.0 or earlier. It just does not work as intended there and even God is not able to change it. Never! So checking for min. version is also makes sense. At least for ports with scripting ability and stormy development.

Personally for me, I agree with you (I think mentioning in txt is enough). But mods authors are more painful about their projects often. They even hate "change gamma" ability heh. You are not able to understand and accept it, because you are technician

That's a valid concern, of course.

[XutaWoo]

Also it is not intended to be played in ZDoom 2.5.0 or earlier. It just does not work as intended there and even God is not able to change it (but zdoom authors still are able to break it in future future versions :trf:) So checking for min. version is also makes sense. At least for ports with scripting abilities and stormy development.

Add a DECORATE function that was added after 2.5.0. Bam, it can no longer be played in 2.5.0 or earlier.

[Kinsie]

Is there still some sort of 3D floor type that doesn't function in ZDoom? Just have the player start on one of those sitting over a fatal drop or a trigger to a non-existent map.

Nearly a year after SpaceDM9 was released for Skulltag, it still doesn't work correctly in GL in the latest official Skulltag version. This gets blamed on me, not on the renderer.

Graf pulled some license changery that effectively means that Skulltag can never upgrade to the latest GZDoom renderer as long as it stays closed source, so technically you're fucked as long as that little lover's tiff is going on (spoilers: it will never end)

[Gez]

I'm sure all the people who worked on CChest3 had this same attitude a few years ago when a bunch of Skulltag users voted their work 0 stars on /idgames because the "scripts don't work".

I'm reminded of that citation from Courteline: "To be deemed an idiot by an imbecile is a true gourmet's delight."

[Graf Zahl]

Is there still some sort of 3D floor type that doesn't function in ZDoom? Just have the player start on one of those sitting over a fatal drop or a trigger to a non-existent map.

Nearly a year after SpaceDM9 was released for Skulltag, it still doesn't work correctly in GL in the latest official Skulltag version. This gets blamed on me, not on the renderer.

Graf pulled some license changery that effectively means that Skulltag can never upgrade to the latest GZDoom renderer as long as it stays closed source, so technically you're flanged as long as that little lover's tiff is going on (spoilers: it will never end)

The Skulltag devs haven't even asked since that happened.

[Gez]

It's not like your log message made it sound like you'd be willing to reconsider if they asked politely:

- Added the following clause to all GL renderer related files (Skulltag devlopers, beware!):
Full disclosure of the entire project's source code, except for third party libraries is mandartory.
(NOTE: This clause is non-negotiable!)

[NeuralStunner]

I'm sure all the people who worked on CChest3 had this same attitude a few years ago when a bunch of Skulltag users voted their work 0 stars on /idgames because the "scripts don't work".

Considering how perfectly normal mods will be down-voted because the author is disliked for one reason or another, personally I make a habit of ignoring /idgames ratings.

Unfortunately, you can't bugfix stupidity...

---

For cases requiring such extreme measures, I've been drafting up the FULA*:

By use of this game modification, users have read and understood the instructions in this file, and agree to accept full responsibility from any problems that arise from failure to follow those instructions. All feedback will be reviewed on the basis of this agreement. Failure to read it will be treated as willful disregard of terms, and will be closed and ignored. You have been warned.

This game modification's authors are not liable for any damage, physical, mental or electronic, resulting from use of the software. Play at your own risk.

Suggestions/recommendations for this "license agreement" are welcome.


* File of Uninformed Loser Avoidance