[Fixed] Problems with Darkest Hour

cccp_leha · Post by **cccp_leha** » Fri Dec 12, 2003 6:39 pm

I noticed that some of the flats in "The Darkest Hour" (you know, that awesome Star Wars PC

), especially on sloped surfaces show up as DEM1_*. See here and here . I am using 2.0.60.

LilWhiteMouse · Post by **LilWhiteMouse** » Fri Dec 12, 2003 10:50 pm

I think it's a problem with the way the wad is setup, that older versions of ZDoom (pre flat/texture interchangeability feature?) tolerated. If you look you've got:

Code: Select all

FF_START
flats
FF_END
flats
F_END

Moving all the flats between the FF markers fixes it.

cccp_leha · Post by **cccp_leha** » Sat Dec 13, 2003 12:59 am

So does this end up being a specific WAD problem or a ZDoom problem?

randomlag · Post by **randomlag** » Sat Dec 13, 2003 11:26 am

Level contains:

Code: Select all

FF_START
flats
FF_END
F_END (not really required)
..more flats that replace existing FLATS

Maybe what happened is the result of Randy compensating for other mistakes people make when adding flats using those markers or the TX stuff?

I'm surprised it worked in the first place

Although technically the FLATS in error just replace existing FLATS, so perhaps it should work? Anyway that's how I approached this - if a PWAD has LUMPS that replace existing lumps they override (as for patches), except for the TX_START stuff.

Yes moving the FF_END and F_END after the extra flats fixes the problem.

Post by **Graf Zahl** » Sat Dec 13, 2003 2:55 pm

randomlag wrote:Level contains:
Code: Select all
FF_START
flats
FF_END
F_END (not really required)
..more flats that replace existing FLATS

No, it contains flats between FF_END and F_END.

Fortunately the solution for this problem is simple: Always look for the last marker to end the flat section, not the first.

randomlag · Post by **randomlag** » Sat Dec 13, 2003 3:29 pm

Mine does not. Geez Graf, you think I can't read my own program Lol. Maybe he changed it some more, but 100% for sure my version is as I described.

Dated 9/23/2001 2:17PM

Post by **Graf Zahl** » Sat Dec 13, 2003 3:43 pm

Mine is 8/6/2001 (zip contents) so there seem to be different versions. I can't imagine the one you have to run at all with the flat management scheme in ZDoom.

randomlag · Post by **randomlag** » Sat Dec 13, 2003 4:21 pm

It's not a problem because the FLATS in question are replacements in both cases.

Don't know where I got that file, since the one from Rex's place is like the one described and has a date of 8/6/01. Maybe I used it for testing various progs and it accidently got modified, although I have one called DarkHourmod.wad with the 8/6/01 date?

In any event, both are incorrect with regard to FLAT locations. Prefer that people follow the rules vs rules that get ever more confusing. IOW, this should be fixed in the PWAD.

Post by **randi** » Sat Dec 13, 2003 6:36 pm

Added a check to make this wad work. Normally, I would say the wad should be fixed, but since it worked with earlier versions of ZDoom (which is somewhat surprising), I feel inclined to make it work with the current version unmodified.

randomlag · Post by **randomlag** » Sun Dec 14, 2003 11:48 am

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

Post by **Graf Zahl** » Sun Dec 14, 2003 3:31 pm

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 · Post by **Cyb** » Sun Dec 14, 2003 3:54 pm

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 · Post by **randomlag** » Tue Dec 16, 2003 12:26 pm

Graf Zahl wrote: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

]

Post by **Graf Zahl** » Tue Dec 16, 2003 12:47 pm

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.

Post by **randi** » Tue Dec 16, 2003 2:42 pm

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.