[Fixed] Problems with Darkest Hour

[randomlag]

That's like saying you made a mistake and now you are saddled with this mistake. That should not be done unless you want to open up the whole coding scene to "mistakes of the past". The PWAD cleary has a mistake and should be fixed.

However, if anything "new" should be done, allow replacement graphics without ANY control stuff. Easy to do, very flexible and friendly to newbies (since it's duck simple to explain) and actually more consistent with other "rules" of PWADs. That's probably how that worked in the first place and you accidently disabled it via the new TX stuff which required stricter checking.

And that "fixes" DARKHOUR 2. So you get a fix and something - 2 for the price of 1

[Graf Zahl]

Yes, and it will break any WAD that accidentally creates a duplicate of an existing lump in another namespace. Since Boom allowed this there are most certainly some WADs out there which have it. THe 'bug' in darkhour.wad was that it had both FF_END and F_END. The problem came from the fact that ZDoom simply chose the first of those markers, not the last. It should always be the last lump, however, that is the real terminator because that's the way it had always been with Doom. Changing the entire WAD loading behavior just to adjust it to your ideology is a massive change and, believe me, it WILL create more problems than it solves, especially if you try to use a combination of WADs that has overlapping name stuff which can easily happen if resource WADs from different sources are mixed. After all, that was the main reason the strict namespace separation was invented in the first place.

I'd say keep it generally as it is but make sure that all lumps before the last F_END/FF_END marker in a WAD which qualify as flats can be used as such. That is the only stable solution that doesn't break anything (and I hope that is what Randy has done.)

[Cyb]

in my unfinished lump util (which I may never finish) when first determining if something is a flat it checks between the first F*_ marker and the last F*_ marker since I found a couple wads that had conventions similar to Darkest Hour and it wasn't identifying a couple flats because of that... so yeah I agree with what Graf says : P

[randomlag]

Yes, and it will break any WAD that accidentally creates a duplicate of an existing lump in another namespace. Since Boom allowed .... stuff ..

That's about as "theoretical" as it gets and merely reflects your "idealogy" without supporting evidence. IOW there is no proof. FYI, my arguments are always from the practical user pov, contrary to what you always state - it's the only way to approach this. And I think I know how I think Obviously it had both FF_END and F_END Lots of PWADs do, even if they don't need both.

As I've said before: There is NO PWAD with deliberately inserted duplicate lumps in the SAME PWAD. You confused this term before. A duplicate means in the SAME pwad. This a replacement, not a duplicate.

Stated before, but never ever came up with an actual example to support your argument. Same goes for the multiple resource argument, all theoretical. PWADs are not additive anyway for namespaces/TEXTUREx (if more than 1 PWAD has same). Similarly the whole duplicate lump in the same PWAD is theoretical and asks for problems. That's why I said it should not be allowed for the TX stuff - that too was a theoretical argument lacking practical perusing of the implications for the user. Just because you can code it, doesn't mean it's a good thing to do.

However, there are many PWADs with accidental duplicate lumps (meaning in the same PWAD). As I've said before, if there is a PWAD with deliberate duplicate lumps that have "meaning" (in the same PWAD) just show me. I can show you lots of accidents - including DOOM, DOOM2.WAD, HERETIC and STRIFE IWADs. The reason I'm pretty confident that such an animal does not exist is that DeePsea tells me automatically when a PWAD is loaded.

Contemplate these tidbits:

1. It makes SPRITE and FLAT replacements much simpler if all they do is replace existing lumps. The namespace stuff is usually for new, but this won't change anything for that. All the change does is make life EASY for replacing EXISTING names. The original spec was merely because id had no need for this feature. This is similar to why adding FF/SS stuff was added, to expand the possibilities for editing.

2. It makes for a precise vs a sloppy spec, although allowing for the F_END as shown is not that big a deal to me either way - just would have been cleaner.

3. Change fixes all PWADs that did this if they had Lumps replacing existing resources (again that's not the same as "duplicate"). Plus if you put out a console message for real duplicates, the user now knows that there are duplicates - obviously the designer had no idea duplicates existed.

4. Designing for theoretical OLD PWADs for which no example can be shown, is not exactly cogent. Even then, if it never should have worked, then all we are talking about is a coding mistake, not that it should be done that way.

5. Changing this is NOT a massive change. In fact, it's already done for patches IOW, it's consistency again and would make explaining stuff much simpler for all newbies. If you do not consider new blood, then DOOM/ZDOOM is terminal since that's the only thing that keeps this going - new people getting interested.

6. Now what about S_END? Sure that never worked for DOOM, since the F_END thing was a QUIRK (not a spec) in the DOOM engine and was actually never meant to work. IOW, an accident again. This came up as a problem several times already for ZDOOM since the F_END was supposed to exist all by itself with any kind of crap in front of it - and this caused mucho probs. Since we are now moving forwards, it's best to tighten down the hatches and not expand on the confusion here.

So you see there are many other STABLE solutions that give a lot more bang for the buck, are much simpler to understand and don't break anything. For that matter for the extremely rare hypothetical case, not a big deal to fix the offender. Just like ZDOOM, LEGACY, JDOOM, etc are not compatible and therefore some stuff is just not supported, same thing here.

What I'm suggesting is much more generalized solution. Believe me, it WILL solve more problems than it creates I hope Randy improves the handling of replacement lumps to make editing easier.

[that's a joke, since it's a silly way to argue - IOW why should anyone believe your or me just because we say so ]

[Graf Zahl]

Well, all it will probably make easier is your DeepSea coding and I doubt that is worth the effort...


And no, I don't think the specs you are proposing are easier to understand. All it will create is even messier WADs than the ones we have now and I don't think that's such a good idea. THe WAD file is totally unstructured unfortunately and enforcing some minimum structural coherence is absolutely necessary. With your 'solution' it would suddenly be possible to randomly mix flats, sprites patches and everything else in the WAD making it utterly impossible to edit the file without the IWAD (or any PWAD) it depends. (And experience tells me that sloppy mappers will most certainly abuse it.) Even accidentally loading such a PWAD into an editor with the wrong IWAD will create a total mess. And you are calling that a 'proper' solution?

Thank you but: 'No Thank You'!

IMHO the best solution is to enforce the current marker scheme as strictly as possible, just allowing the cases of improperly placed F_ENDs in a sensible manner. That really can't be that hard considering that any 'legal' flat in Doom is exactly 4096 bytes and thus easily identified. There aren't really much of them:
FF_START and F_END - no problem
F_START and FF_END - no problem
F_START, FF_END and F_END - use the last end marker
F_START, FF_START, F_END - ignore all but the first start markers
F_START only - ignore flats completely
F_END only - handle all lumps which are exactly 4096 bytes long - best create a duplicate WAD entry for it in the flats section just in case it isn't really a flat.

And this will handle ALL possible cases without any need to completely alter the WAD handling as you propose.

[randi]

I'm sorry, RandomLag, but that is perhaps the worst idea I've seen you make. Doing what you suggest would needlessly create inter-wad dependancies and make the wad loading code considerably more complex. Graf Zahl is being much more sensible than you. The markers are there for a reason.

[Virgil]

You could just delete FF_END...

[randomlag]

I'm sorry, RandomLag, but that is perhaps the worst idea I've seen you make. Doing what you suggest would needlessly create inter-wad dependancies and make the wad loading code considerably more complex. Graf Zahl is being much more sensible than you. The markers are there for a reason.

That is not true Randy. Give EXAMPLES guys. Having freedom to just replace resources without all the marker BS makes it much easier for users period.

I never said to get rid of the markers at all - read carefully and do not use preconceived ideas of what I'm saying. What I said was that replacements really don't require markers. Hell, I "could" push this even further and argue that you do not require markers (which is not what I said) - use level usage context and lump format, but that would make for more work on your part - but that is easy to do too as far as a solution for a technical problem to resolve lump types

(edit: I don't think you guys understand what a replacement means in my context: It means the lump name already exists in the IWAD and the user is giving you a replacement for the lump)

It does NOT create inter-wad dependancies any more than you have now. It does NOT make wad loading more complex - look carefully and you will find that the whole thing simplifies, but you should get rid of that duplicate in same PWAD thingy - not a good idea.

In fact, if you follow the rules CONSISTENTLY, it makes it much simpler. What you do is is just replace all the resources that duplicate those in the IWAD at load time.

For an editor it presents no problem either. All that has to be done is exactly what I proposed. Clean, simple and consistent with SOUNDS, MUSIC and PATCHES. IOW, it's just like all those are done which for some strange reason hasn't confused anyone yet. In fact, the #1 question for replacement FLATS and SPRITES has to do with exactly this problem. I'd say that's defacto proof that the system is not friendly to beginners.

The current system clearly has inconsistent rules and awkward for beginners - something easily forgotten in all the "namespace" arguments. You also need to add better checking for texture formats in any event in case you are concerned about replacing the wrong thing - something that can already happen anyway.

Btw Graf, legal flats are NOT 4096 at all - look at some of the IWADs very carefully. And it has nothing to do with DeePsea - again a silly comment to make. I can make it follow crazy rules

[Graf Zahl]

If even Randy disagrees so strongly with you it should be obvious that your idea is not good. Clearly you haven't got the faintest clue what you are suggesting. Your scheme would make everything but editing for beginners make a total mess but you are not able to see it. Yes, the WAD system is in dire need of improvement but there is no need to make it an incomprehensible mess which is what will happen if you create dependencies like these (because suddenly some resources may end up in a different namespace and the user has no clue why if you alter the order of WADs. Of course you could remove the namespaces but I don't want to deal with *that* mess it will create.) I think everybody agrees that the WAD structure is far too limited but removing it completely (because that's essentially what you are proposing) is most certainly the worst of all bad ideas you ever had.

[randomlag]

LOL - come'on Graf, let's keep it civil. How about you haven't got the faintest clue what I'm suggesting eh? Whether Randy agrees or not is a strange way to argue. Means absolutely nothing Graf. Somehow I'm comfortable arguing with either one of you on this topic -).

First off, it's NOT an incomprehensible mess. In fact, I'd say that what exists is a mess. Just follow the yellow brick road which I've repeated over and over. Current rules are COMPLETETY contradictory to other rules.

Just because you can't figure how to code this doesn't mean it can't be done - namespace be damned. I know how to code this - fairly simple really And if Randy got rid of the bias he'd see that it could be done. As I pointed out in the initial "tall textures" which also were supposed to be impossible (according to Randy when I did them at 512 high - leading to the current support of really tall), this too can be done.

Although I never said this in the context of "duplicates", removing the namespaces actually does NOT make a mess - god. I wish you would quit concluding things just because it's not clear to YOU how to do this. For the sake of argument only, as I said, it's easy to not require namespaces at all and figure out what is what in the context of the level. The only "namespace" might be TX, but not even that if the duplicate name in a PWAD is dumped. Duplicate ability here is absolutely not required - iow it doesn't solve any problem per se. Remember, there are NO deliberate duplicate lumps in any PWAD that exists that would be affected. If you think there is give an example of the pwad.

If you can't see the problem here, don't argue with me. Try actually coding the whole thing to see how this works.

Amazingly removing the namespace stuff is the exact answer to the specious argument that the "user has no clue", because in fact he has no clue now of all these strange rules (not that I said to do this, just an academic argument).

(All that is just for the sake of argument since it is a bit more than what I intended - so dont' carry on and on about that as you've now done 2X).

Nor did I say the WAD structure is too limited (in fact it's pretty extensible - think outside the box), I'm only saying it can be much simpler to understand for beginners to allow replacement of duplicate IWAD lumps just like many other lumps can be. And it does NOT break anything that already exists (why? if you disagree give a example of a real live level that would break). Sure it takes a bit of code, but much more useful than alternate graphic formats for fonts

Btw, when you argue, it's customary to counter the points brought up by the other party, not carry on as if the points were never made. Giving examples would be a spiffy way to counter my points.

And I'm busy doing the ingame 3D texture editing with RISEN3D, so I'm not going to keep repeating the same stuff over and over. Just keep an open mind.

[HotWax]

God dammit, go back to wherever you've been since Xmas. Things around here were starting to look up.

[Graf Zahl]

LOL - come'on Graf, let's keep it civil. How about you haven't got the faintest clue what I'm suggesting eh? Whether Randy agrees or not is a strange way to argue. Means absolutely nothing Graf. Somehow I'm comfortable arguing with either one of you on this topic -).

It just means that you are wrong. Period. I'm still waiting for the first time you admit that maybe your idea may not be that good after all. Instead you react like a politician defending your ridiculous ideas ad infinitum unless nobody is interested in reading your pointless ramblings anymore.

You have certainly reached that point with me (and HotWax of course, too!)

[randomlag]

GOD what a PIA. Funny thing is YOU say tbings that reflect the way YOU post things. Seems that is what you resort to every single time when you can't actually come up with a valid argument (it's not something to be proud of). In fact, it's you doing the "politician" bit, because you haven't given anything resembling objective reasoning. Here's the problem with the way you reply:

First off all, you can't seem to do this objectively, but instead refuse to give examples of how doing this would screw things up. That's how it's done Graf, not just because YOU say so. Btw, there aren't any example, hence you are stuck.

Secondly, Randy is hardly the final answer. He's been incorrect several times on technical issue. No biggie, just that it's ridiculous to use this in your argument. Remember this is merely an idea, doesn't have to be done, but don't tell me it can't be done. It can. Existing "rules" are confusing period. Tell me exactly how it makes sense that a patch can be replaced (for the same name in the IWAD), yet you can't do this with a FLAT. Ditto for music, sound and many other lumps. It's an oversight and it does not make sense in the context of the other "rules" nothing else.

Third, you have said numerous times that you can't accurately detect if something is a DOOM format graphic. I've corrected you when I saw same. Did YOU ever admit that it can be done? No. Q.E.D.

I starting to think you have no idea what I was talking about or maybe you finally did and since you objected you now can't pass that point and realize what I was actually saying. This has nothing to do with namespace stuff. God, it's so frikken simple I'm laughing at all this fuss.

Btw, glad to see you comparing yourself to Hottie (I agree you tend to act very much like him when pressed for facts) -tis not something to be proud of

[HotWax]

I don't think you grasp the concept that we don't really care when you talk anymore.

[Graf Zahl]

I don't think you grasp the concept that we don't really care when you talk anymore.

No, he doesn't. What's worse:

§1 RandomLag always got to have the last word.
§2 RandomLag is always right
§3 When in doubt, see §2

(Yes, I know I posted this before but it obviously still applies)

And I don't read his worthless blabbering either anymore.
And he would definitely make a good politician. He's got all the necessary attitides.

It's definitely no fun arguing with someone like him but, honestly, sometimes I can't let the nonsense he talks stand unchallenged.