lilith.pk3 - release candidate 1

Please do not mimic the behavior of the posts shown here.

Moderator: GZDoom Developers

Re: lilith.pk3 - release candidate 1

Postby Xaser » Sun Jul 23, 2017 11:55 pm

Real question for ZZYZX and Rachael: Is there a snowball's chance of GZDoom/QZDoom actually introducing compatibility hacks to make this mod work in future versions? If not, it is impossible for there to be any benefit to removing the check, and the requests instead become "please make it easier for me to not be able to finish your wad."

I really don't know how "this mod is a weird edge case that defies conventional wisdom" isn't 110% evident based on the screenshots. :/
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: lilith.pk3 - release candidate 1

Postby Rachael » Mon Jul 24, 2017 12:05 am

The main issue is: Once one person does it, then two more get the idea to do it, then a dozen more think it's really cool, and all of a sudden we have a bunch of mods that block access based on arbitrary rules, like what port you are using. It's already an issue with mods like GF3 that actually kill you if it detects vid_renderer is 1, and the past has proven that if one person has abused it a bunch more will, too.

Basically it's more of a philosophical request than a technical one, and to condone it even once is a can of worms on my end, that a number of other people will have a bunch of use cases to justify their using it as well. I know people will ignore the warnings "HEY THIS DOES NOT WORK IN GZDOOM" but if I had to choose, I'd rather the bogus bug reports on this mod than people thinking that this kind of practice is okay. Even worse than that, those people probably won't offer the same courtesy that Anotak did by including the ACS source, requiring an actual decompile and an engine-side hack. This is wholly the very definition of "slippery slope."

Inevitably it will end with myself or Graf adding hacks directly into the engine to bypass these checks, and nobody wants that.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: lilith.pk3 - release candidate 1

Postby Xaser » Mon Jul 24, 2017 12:50 am

The situation's already self-policing. If another mod tries this, they'll be met with a "Don't do that!" (a la this discussion) and likely won't have some sort of valid reasoning for what they're doing. Beyond that, the risk is super-low that this mod in particular becomes some sort of brushfire catalyst that causes everyone to try and build janky port checks into their wads all of a sudden. Let the exception be an exception, and fight this battle if it happens for real.
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: lilith.pk3 - release candidate 1

Postby Chris » Mon Jul 24, 2017 1:54 am

Xaser wrote:The situation's already self-policing. If another mod tries this, they'll be met with a "Don't do that!" (a la this discussion) and likely won't have some sort of valid reasoning for what they're doing.

Being told "don't do that" and actually not doing it are two different things, as we see here. A person that explicitly prevents their mod from working with a particular engine is obviously not going to care when that engine's developers or users ask them to stop, because that engine is not part of their target audience. If they cared, they wouldn't have done it in the first place. In fact, doing it actually shows they care enough to block it (it takes extra effort to explicitly block a particular engine) despite doing nothing to improve the experience for users on the ""correct"" engine. It's essentially a form of DRM, preventing the content from working on "unapproved" engines for no benefit on the "approved" engine (which means it could potentially be illegal to modify the content to bypass the check and make it work on other engines, if you're not given explicit permission).
User avatar
Chris
 
Joined: 17 Jul 2003

Re: lilith.pk3 - release candidate 1

Postby anotak » Mon Jul 24, 2017 2:38 am

i would like to point out that the only reason this was brought up was because zzyzx tried to run it in a port that the instructions in the txt file explicitly said not to run it in. which is concrete evidence for the whole reason i did this, as opposed to hypotheticals about "what if everyone did it".

Chris wrote:explicitly prevents their mod from working with a particular engine

it already does not work though, i just provided a helpful error instead of people being confused.
to be sure, i just re-examined it in qzdoom and gzdoom with the check disabled, and yes, many things are broken. plenty of which are broken in non-obvious ways.

edit: i would like to also point out that what i chose to do is, well, commonly considered a best practice in designing software. graceful exit as opposed to letting people's continue in a broken state.
anotak
 
Joined: 06 Dec 2016

Re: lilith.pk3 - release candidate 1

Postby Chris » Mon Jul 24, 2017 3:41 am

anotak wrote:it already does not work though, i just provided a helpful error instead of people being confused.

It doesn't currently work as you want. Doesn't mean an interested person won't want to check it out anyway knowing it won't be as you envisioned, and it doesn't mean those other ports won't work "correctly" with it in the future. It also doesn't mean that (had it not stopped development) a future version of ZDoom couldn't break it, so users would not get a "helpful" error when it doesn't work even when using the "correct" engine.

edit: i would like to also point out that what i chose to do is, well, commonly considered a best practice in designing software. graceful exit as opposed to letting people's continue in a broken state.

In software development, it's good to check for the actual feature or issue in question, not what has a feature or issue. If MSVC has an issue with my code, for example, I don't check for MSVC and blacklist it*. Same as if there's a useful feature that Clang has, I don't only use it if I detect Clang*. I check if the compiler the user is using has an issue with the code in question, or has the feature I desire. So if MSVC gets fixed, or some other compiler I don't know about has the same issue MSVC has and has the same feature as Clang, it all works appropriately. This also avoids issues with spoofing or masquerading, where a compiler purports to be a bugged MSVC version but in fact does not have the problem my code triggers, for example.

* Generally speaking. Sometimes I'm lazy, but that's because I want to do less work, not give myself more work than necessary.

Also, "error early" is good practice in programs, not content. If your content does something bad, it should be GZDoom/QZDoom/whatever's job to detect something bad going on and stop it if it's a problem. If the engine doesn't deem it to be a problem worth exiting over, let the user decide if they want to play it despite not being as you intended. Content should just be, the engine decides if it's capable to run, and the user decides if they want it to run.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: lilith.pk3 - release candidate 1

Postby anotak » Mon Jul 24, 2017 4:53 am

Chris wrote:It doesn't currently work as you want.

of course????? i wanted to make these levels!! i wanted to make them a certain way! if how i wanted them to be does not matter, then why am i here? in fact, why make anything ever?
if my desires don't matter, then why would anyone play my wad? why even have doom wads, or any form of creation, period? why should i wake up in the morning?
do you make arguments like this if someone makes a wad for eternity-engine?

doom wads are expressions of things people want to make. they are sets of restrictions on players, walls, doors requiring given keys, so on, so forth. one of the restrictions involved is how you can see (or can't see) certain things. if the player can see through walls, or if certain visuals don't show up, in certain cases this can be as egregious as not having walls or not having a level in the first place.

- the central ideas behind several areas and levels in this wad do not function in the newer renderers. notably mirrors, portals, homs, and 3d floors are often handled very differently. this affects ALL the maps. map03 is basically completely broken on new sw/hw renderers.
the largest specific issues are:
- map03 literally crashes the gz hardware renderer
- qz's software renderer does not render some Things on map05 making one room in particular appear to be an empty black void
- monster behavior on map06 is different on gz/qz for unclear reasons. several monsters can see you while facing away from you. couldn't figure out the cause of this. this is a heavily damaging issue because of the modified monsters in the area.
- map02 literally cannot be completed on zandronum because of differences in how 3d floors are handled.

you should actually play the wad some before jumping to conclusions.

if someone that badly wants to play them differently, they can just disable the script and load them in something. have fun. i am a-okay with that! it's not even hard. i wanted to prevent accidentally playing it on the wrong port. which, as evidenced by earlier in this very thread, is a real concern. on the other hand, if you intend to do something weird and broken, that's fine with me.

Chris wrote:In software development, it's good to check for the actual feature or issue in question, not what has a feature or issue.

great. point me to where this ability exists in ACS.
because i actually looked and asked around before i resorted to this. i obviously didn't find anything.

Chris wrote:Also, "error early" is good practice in programs, not content. If your content does something bad, it should be GZDoom/QZDoom/whatever's job to detect something bad going on and stop it if it's a problem. If the engine doesn't deem it to be a problem worth exiting over, let the user decide if they want to play it despite not being as you intended. Content should just be, the engine decides if it's capable to run, and the user decides if they want it to run.

considering that games (and by extension the content for games) are systems, principles for designing systems still apply.

Chris wrote:If MSVC has an issue with my code, for example, I don't check for MSVC and blacklist it

let's suppose MSVC had an issue where your code still compiles, does not cause any error messages, but produces wrong results, that are clearly wrong given knowledge of the intricacies of the system, but to an enduser might not be clear. suppose that MSVC does not provide a way to detect this specific problem other than detecting MSVC. suppose that fixing this would require a large rewrite of MSVC and maintenance on it to support your one single solo project. what would you do in this case?

and as far as you saying that it doesn't apply to content, this is your personal philosophy that i do not agree with. you don't give any reasons for any of this, you just say it's true, as if everyone accepts it.
anotak
 
Joined: 06 Dec 2016

Re: lilith.pk3 - release candidate 1

Postby Rachael » Mon Jul 24, 2017 6:03 am

Xaser wrote:The situation's already self-policing. If another mod tries this, they'll be met with a "Don't do that!" (a la this discussion) and likely won't have some sort of valid reasoning for what they're doing. Beyond that, the risk is super-low that this mod in particular becomes some sort of brushfire catalyst that causes everyone to try and build janky port checks into their wads all of a sudden. Let the exception be an exception, and fight this battle if it happens for real.


I am sorry, I don't normally disagree with you Xaser, but that is a horrible policy. By the time it gets to that point it is usually already too late.

My request still stands.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: lilith.pk3 - release candidate 1

Postby Rachael » Mon Jul 24, 2017 6:29 am

anotak wrote:- map03 literally crashes the gz hardware renderer

All the more reason to leave this unblocked! The crash needs to be reported, even in situations where the renderer is not intended to be run with that map!
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: lilith.pk3 - release candidate 1

Postby Graf Zahl » Mon Jul 24, 2017 6:33 am

Rachael wrote:My request still stands.



How about installing a policy for the projects forum that prohibits such idiotic antics and if not obeyed dump the respective project thread into the garbage bin?

I think the best way to deal with obnoxious modders is to stigmatize them as losers. Sorry, but stuff like this is just retarded. (Of course this 'mod' is retarded anyway so no big loss.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: lilith.pk3 - release candidate 1

Postby Rachael » Mon Jul 24, 2017 6:35 am

A few points with that:

A) Such a policy should be discussed among the moderator team, in my opinion. I'll try bringing it up with them in Discord.
B) Is it really too much to ask for you not to resort to insults, even in cases like this? :|
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: lilith.pk3 - release candidate 1

Postby ZZYZX » Mon Jul 24, 2017 6:37 am

Rachael wrote:Inevitably it will end with myself or Graf adding hacks directly into the engine to bypass these checks, and nobody wants that.

this. People blocking things based on the port results in not introducing actually useful features for modders because "it'll be abused, see that example".

Chris wrote:In software development, it's good to check for the actual feature or issue in question, not what has a feature or issue.

I brought this up several times. It never got implemented.
Example 1 viewtopic.php?p=977743#p977743
Example 2 https://mantis.zdoom.org/view.php?id=85

So newer engines get altered behavior in many ways, and still have no way to check and maintain compatibility on the mod side. That's another problem IMO.
Last edited by ZZYZX on Mon Jul 24, 2017 6:58 am, edited 4 times in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: lilith.pk3 - release candidate 1

Postby Chris » Mon Jul 24, 2017 6:46 am

anotak wrote:of course????? i wanted to make these levels!! i wanted to make them a certain way!

And you do. But that has nothing to do with GZDoom/QZDoom/whatever. You made it for ZDoom, ZDoom can run it as intended, and that's about as far as you need to care about that. You preventing other engines from even trying to run it does nothing for your vision of what ZDoom does with it. All it does it cause a headache for people who want to try it in those other engines regardless. Think of it this way. If someone ran your mod with ZDoom and had another mod that interfered with yours, but the user was still satisfied or otherwise understood that if they wanted to see your mod as intended the other mod would need to go, or wanted to see if they could fix that other mod to work better with your mod, isn't it their choice to do that? That's the point of mods, and even alternative engines to an extent, to change the intent of the original to better fit what the user wants (or needs). Adding extra measures to prevent it from working, beyond the actual manifested problems, just comes across as spite. It's saying even if it could work and provide a decent enough experience for some user, you won't allow it.

doom wads are expressions of things people want to make.

And people play doom wads to experience what they want. The whole point of using mods is for the player to personalize their experience, to make it different from what the original creators intended. That goes for mods as well as the base game. Sadly, I know a number of modders would actually prevent users from using other mods with their mods if they could.

- the central ideas behind several areas and levels in this wad do not function in the newer renderers. notably mirrors, portals, homs, and 3d floors are often handled very differently. this affects ALL the maps. map03 is basically completely broken on new sw/hw renderers.

In the original versions of most (if not all) GL-accelerated ports, many rendering tricks that were widely known did not work. Self-referencing sectors for shallow water and invisible walkways, omitting upper and lower textures to cause flat bleeding for fake floors and ceilings, and other such tricks would fail in a number of various ways. Imagine if mods could detect an accelerated renderer back then and stop it from working... such mods would still not work today even though those effects work now (at least in GZDoom), while at the same time potentially fail with a non-accelerated polygonal renderer but the mods not caring because it's not accelerated.

the largest specific issues are:
- map03 literally crashes the gz hardware renderer

Clearly a bug in the engine, as mods shouldn't be able to crash the engine. Other people being able to run the mod in GZDoom's hardware renderer would be beneficial to finding and fixing the crash, if not make the intended effects work.

- qz's software renderer does not render some Things on map05 making one room in particular appear to be an empty black void

It not rendering in QZDoom's software renderer could be indicative of a bug that was introduced. Being able to run the mod with it would allow others to determine if it could be made to work again. And if not, it's only one room out of several maps.

- monster behavior on map06 is different on gz/qz for unclear reasons. several monsters can see you while facing away from you. couldn't figure out the cause of this. this is a heavily damaging issue because of the modified monsters in the area.

Same as above, this could be indicative of a bug. It could also be caused by a fixable issue in the mod, where you can get intended behavior on newer engines by making some changes. But we wouldn't be able to know if we can't easily run and test it.

- map02 literally cannot be completed on zandronum because of differences in how 3d floors are handled.

Again, could be indicative of a fixable bug in the engine or mod. But we can't easily run and test it.

you should actually play the wad some before jumping to conclusions.

I wouldn't mind playing it. But for some reason, the author prevents it from even trying to work on the engine I use. :?

great. point me to where this ability exists in ACS.

It likely doesn't. So the question is then, is it your responsibility to care as long as the user knows? Does taking the extra effort to make an inexact blacklist, for something users may not care about on an actively developed engine that could fix the most severe problems, do anything positive for the experience?

considering that games (and by extension the content for games) are systems, principles for designing systems still apply.

There's also things to consider like a system's reach. Different systems worry about different things, e.g. AI scripts don't worry about networking bugs. If something can't reliably detect what should be checked, that indicates system overreach; that system is caring about something it shouldn't care about.

let's suppose MSVC had an issue where your code still compiles, does not cause any error messages, but produces wrong results, that are clearly wrong given knowledge of the intricacies of the system, but to an enduser might not be clear. suppose that MSVC does not provide a way to detect this specific problem other than detecting MSVC.

Such a supposition is impossible. If the results are wrong, I can check the results for being wrong. If the only detectable difference is the compiler, then what is actually different that's causing a problem?
User avatar
Chris
 
Joined: 17 Jul 2003

Re: lilith.pk3 - release candidate 1

Postby ZZYZX » Mon Jul 24, 2017 6:57 am

Chris wrote:
- map02 literally cannot be completed on zandronum because of differences in how 3d floors are handled.

Again, could be indicative of a fixable bug in the engine or mod. But we can't easily run and test it.

This part is even funnier: Zandronum will get updated to the next ZDoom base and BAM fixed.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: lilith.pk3 - release candidate 1

Postby Xaser » Mon Jul 24, 2017 9:02 am

Rachael wrote:I am sorry, I don't normally disagree with you Xaser, but that is a horrible policy. By the time it gets to that point it is usually already too late.

If you have any evidence/reasoning on why it's "horrible policy" aside from what's been said, please share it. We're probably at the "agree to disagree" point by now, but I feel as if I'm missing some piece of the picture because the situation still seems pretty clear-cut to me (i.e. "this mod is a special exception" for all the reasons I've stated previously).

I'm obviously concerned about (read: oppose) the idea of introducing some sort of forum policy in response to this, but more alarming is the notion of "stigmatize [modders] as losers" as a serious suggestion. I don't think it's in anyone's best interests to foster a toxic community as a means for policing mods. It's not surprising hearing that coming from the poster in question, mind you; I just hope nobody else is taking that particular suggestion seriously.


@Chris: The key thing to understand is that running this mod in G/QZdoom doesn't just result in the mod not working as intended; it results in it not working at all, in very non-obvious ways. Aside from the crashes, perhaps, the issues in question aren't going to be fixed engine-side. I'd agree with most of your points if it wasn't for these couple of facts turning the entire situation on its head.

Some post-thoughts: it's really unfortunate that folks are coming down so hard on a legit issue by fighting against the one mod that really ought to get a pass on it. It's already turning folks against the very concept, which isn't helping anyone. :?
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

PreviousNext

Return to Hall of Unpleasantness

Who is online

Users browsing this forum: No registered users and 0 guests