The COMPLVL Lump

[Arsinikk]

16 minutes ago, Xaser said:

No, what you're doing here is spreading misinformation (intentionally or not), then trying to grammar-lawyer your way out of the conversation when it gets pointed out.

What are you talking about? I'm saying this is how OPTIONS work because this is what I've been told by Shepardus and from my own experience while trying to make my WADs compatible with multiple source ports for years now.

 

It maybe is possible that it's slightly different now, but you haven't really given proof that say what I'm saying is false. I have no problem admitting I'm wrong if I am shown proof, but I'm not trying to ease my way out of a conversation. At least I'm not trying to spread misinformation. That would be a cowards way out, and I'd like to think I still have integrity.

 

16 minutes ago, Xaser said:

BTW, a comp_ option doesn't have to be disabled in vanilla -- it could easily be whitelisted into lower complevels if that's where it's meant to be used, and comp_soul fits the bill.

I guess... although I'm not really happy about utilising a lump where most of it gets disabled. Seems counter intuitive to me.

 

16 minutes ago, Xaser said:

To be clear, I suggested the option because the proposal in the OP has already been shot down by all relevant port devs and I thought this approach would have a better chance of getting traction while still fixing the problem at hand

To be fair, yes the COMPLVL proposal has been shut down. But last I heard, GAMEVER still has some kind of a chance.

 

16 minutes ago, Xaser said:

If you're going to react by shutting it down immediately and trying to rules-lawyer your way through any further discussion, then I doubt anyone else is going to bother assisting you any further

Look, I'm not trying to get out of a conversation. But I'm not gonna back out if someone's going to call me out on misinformation, when I know how things work. I've been implementing support for all my WADs for all ZDoom ports, Eternity, DSDA Doom, Woof, even special support for Doom Retro. It's not like I literally know nothing about these things.

 

If you really wanna show me that I'm wrong about the OPTIONS lump and DSDA Doom, then send me the actual code from Github. Then I have no problem conceding that I was wrong. But just saying that I'm wrong without receipts and then saying I'm lawyering my way out is just disingenuous.

 

I'm not trying to make enemies here. But I will stand up when challenged.

Edited April 27 by Arsinikk

[Redneckerz]

On 4/25/2024 at 6:55 AM, Arsinikk said:

ZDoom ports I often use ACS to fix things because some really old ZDoom ports don't support ZMAPINFO, or even DECORATE for that matter (ZDaemon).

ZDaemon in particular has a lot more idiosyncrazies to work around stuff that other ports do through standardized or widespread means, such as DEHSUPP, EXTRADEH and PATCHINFO. The latter i think you could misuse to implement something similar to your GAMEVER, but as a patch at loadtime.

 

Unrelated but i am impressed you and Worst have made an ACS script that can guess which complevel needs to be used. Is this done in Hexen ACS or extended ACS?

 

In either case, that script might be more useful for general use for other mappers to automatically set complevel correctly for the end user. Could you perhaps distribute this script and its source?

6 hours ago, Xaser said:

To be clear, I suggested the option because the proposal in the OP has already been shot down by all relevant port devs and I thought this approach would have a better chance of getting traction while still fixing the problem at hand. If you're going to react by shutting it down immediately and trying to rules-lawyer your way through any further discussion, then I doubt anyone else is going to bother assisting you any further. You're doing something extremely niche here, and there's very little incentive to address this case if it benefits precisely one person and that fellow is being difficult.

 

Port compatibility is hard. It's even harder if you decide not to work with the folks who develop the ports.

I agree with you here that Arsinikk is trying to uncover new grounds here by pushing for something the majority of mappers generally don't think about, simply because most are okay with the options as they are. That doesn't mean it can't hold improvement, yes and i don't think this should be ruled out instantly (by Arsinikk)

 

However i disagree with the latter part, because Arsinikk goes beyond what is expected of a map release by getting it to work in practically every port (and Vanilla) out there, even down to ZDaemon. I say that's commendable and far removed from not to work with the folks who develop the ports, on the contrary. Arsin's maps get better compatibility with ports than most..

 

This is merely a difference of view and not so much an attack on anyone, if you were to ask me.

 

6 hours ago, Arsinikk said:

What are you talking about?

You said: Unfortunately OPTIONS is a legacy lump used by Eternity that sometimes requires certain tweaks to get it fully compatible with the port.

 

Xaser said: OPTIONS is a feature from MBF, which was preserved in Eternity, removed in Prboom-Plus, and restored for dsda-doom. The lump itself in dsda's case is just an interface for a series of comp_ flags, and the actual comp flag implementations were not removed from the codebase in Prboom-Plus -- i.e. the code that actually implements these options hails back from Eternity and DSDA's shared ancestor (MBF). It's the same feature.

 

Then you said: Which while I didn't say in the post, is in fact an MBF feature like you said. MBF came out in 1998, so OPTIONS is in fact a legacy lump. I also never said it was ONLY an Eternity lump. I just said it was the main lump you would use for Eternity to set compatibility settings. So at this point, OPTIONS is essentially the ZMAPINFO defaultmap, or COMPLVL of the Eternity Engine. Due to the Eternity Engine being the port that's slowest in development, OPTIONS is essentially the only current way to force settings.

 

I think the essential is in the bolded. It is the same feature. It is a legacy lump, yes, but it isn't from Eternity, but from MBF. Its just that Eternity carried this over.

 

FWIW i don't think this is intentionally spreading misinformation but rather explaining the same thing slightly differently which is what causes the argument to happen.