ROP 2015: Finished!

scifista42 said:

tecnical stuff

I found out that there is a sort of dehacked for heretic called HHE, IF we want to choose the H+ path i think this might help.

REFERENCES:

-HHE 1.1 download: http://www.doomworld.com/idgames/?file=utils/exe_edit/hhe11.zip

-chocolate heretic support .HHE patches: http://www.doomworld.com/vb/source-ports/50676-chocolate-heretic-hhe-support/

-Hex11 noted this in the Blasphemer thread, may or may not work, i still have to test it:

hex11 said:

Here's one patch for Chocolate Heretic that uses same limits as Heretic+
http://pastebin.com/NgFuhJ22

You can ignore the g_game.c stuff though... I was just unhappy the game has hardcoded binding on Backspace key (my ergo keyboard has odd layout...)

Btw this patch is several years old. I haven't tried to apply it recently, but that code probably hasn't changed.

Additional stuff that may or may not be interesting:

-Dehacked homepage (scroll to the bottom for HHE): http://www.yossman.net/~tree/_doom.html

-One random heretic wad that use HHE (still have to play it): http://www.doomworld.com/idgames/?file=levels/heretic/g-i/ichor.zip

That is what i found out for now, might search some more later.

HHE patches are not supported by any other ports than Heretic+, Choco and vanilla Heretic. As Gez explained to me, each port that runs Heretic would need its own treatment.

I'm for going the Heretic+ way, but preferably also with the custom sprites according to Egregor's model A.

I've got an idea which might and might not work: Let's make a HHE patch that will change sprite names of small pillar and stalagmites, for example to HTR1, HTR2, HTR3. Rename the tree sprites to HTR1A0, HTR2A0, HTR3A0, put them in the wad and place a S_END marker behind them. Behind this marker, let's put SS_START and SS_END markers, and place the tree sprites between them again, this time named as the original sprites: STGSA0, STGLA0, SMPLA0. They will be ignored by vanilla, Choco and Heretic+ (because of the S_END marker before them), but advanced ports should catch them.

This could work, i'm not really into dehacked so i need some time to learn it properly, even for something that easy.

HHE patches are going to be problematique in Heretic+ anyway, because Heretic+ supports neither embedded HHEs, nor any command like -deh in Chocolate Doom. It would be needed to patch a Heretic+ executable using HHE.EXE. I personally think that merging sprites using DEUSF (or even manually in SLADE3) is EASIER to do than using HHE.EXE - on the other hand, someone would just make an edited Heretic+ executable and distribute it with the wad, which should work and the end user would be free of any work. Chocolate Heretic (and anything higher) hopefully supports -merge command natively, so that DEUSF wouldn't be needed.


In other news, I suggest this temporary solution as seen on this screenshot from SLADE3. I've changed the Hexen tree's sprite name to SMPLA0, placed all custom sprites between SS_START and SS_END markers, and put S_END at the very start. This way, the wad should be possible to launch in EVERY port - in Heretic+ and Choco, the new sprites simply won't display, but at least they won't crash the game. In any advanced ports, the tree sprites should display properly.

I've tested GRB's map in Heretic+ with this altered ROPTEX, and it worked.

Egregor said:

I. Go Heretic+ compatible, map for vanilla with an extended limit, remove the custom tree sprites, leaving only custom textures/flats and be on our merry way.

Actually the tree sprites are fine to use in this case. It's just that when using Heretic+ in DOS, you have to first merge the sprites into your IWAD with deusf.exe (just like they did in the old 90's Doom TCs).

If playing with limit-raised Chocolate Heretic, you don't even have to do that extra IWAD merge step with deusf, just the runtime -merge parameter is enough (chocolate-heretic -merge the.wad instead of chocolate-heretic -file the.wad).

Of course you can't just add new sprites, the trees would have to replace other obstacle sprites like pillars or whatever.

Jeez, I had NO IDEA that 3 little tree sprites would become the technical crux of the Doom engine in 2015! Alright, first, thank you to scifista42, Cacowad, hex11, and Gez for doing the research on this shit.

Okay, so now when I get a chance, I will update the texture pack via scifista42's Slade edit suggestion and we can all be confident that the project will be compatible for both Heretic+ and Chocolate Heretic, as well as advanced ZDoom ports.

Egregor said:

Jeez, I had NO IDEA that 3 little tree sprites would become the technical crux of the Doom engine in 2015!

Heh. It shows that nobody ever cared about Heretic (and its cross-compatibility) nearly as much as about Doom, including engine programmers (which is understandable due to the overall lack of interest and the fact that Doom was a priority).

scifista42 said:

Heh. It shows that nobody ever cared about Heretic (and its cross-compatibility) nearly as much as about Doom, including engine programmers (which is understandable due to the overall lack of interest and the fact that Doom was a priority).

I don't see how Heretic's cross-port compatibility is any different to Doom's beyond all Doom ports generally supporting Dehacked versus no notable support for Heretic's HeHacked?

The issue with the tree's would be the same if yourselves were making a Doom project.

You want to add them as all new mobjs, you are limited to ports that both support Heretic and ports that support adding new mobjs (i.e Doomsday, ZDoom etc).

You want to add them as replacements, you can use any Heretic supporting port (though Vanilla Heretic itself would require the sprites to be merged, which is the same as Vanilla Doom).

It may also be worth noting that Vanilla Heretic (again like Vanilla Doom) will crash if it encounters an unknown mobj type; port's like Doomsday and ZDoom can run maps with unknown mobj types (i.e Doomsday removes them and ZDoom displays an exclamation graphic in their place).

Vermil said:

I don't see how Heretic's cross-port compatibility is any different to Doom's

You've answered yourself:

"Doom ports generally support Dehacked and no Heretic port supports HeHacked." - so that there's no cross-compatible way to change behaviour of game objects.

If "you want to add new mobjs, you are limited to Heretic ports that support adding new mobjs (i.e Doomsday, ZDoom etc)" - each of them has it's own scripting language, there's no cross-compatible one like Doom's DEHACKED is.

Scripting has nothing to do with adding new mobjs.

ZDoom's Decorate and Doomsday's DED can co-exist without issue for instance. Each simply ignores the other ports lump.

Vermil said:

Scripting has nothing to do with adding new mobjs.

ZDoom's Decorate and Doomsday's DED can co-exist without issue (each port simply ignores the other ports lump).

I don't deny either. My point still stands. DEHACKED is an easy cross-compatible "language". If you want it in Heretic, you need to know multiple "languages".

There's one improvement to Scifista's edit that can make it work in H+ without deusf merging: if you put the sprites between SS_START and S_END (not SS_END) lumps and rename them, the new sprites will load without error*. From here, you can use DEH (or HHE in this case) to change the sprite names to work. STRAIN was one of the earliest uses of this trick, and I used it in D2TWID, as a more modern example.

[*One caveat: you can't have any lumps that share the first 4 characters of its name with a sprite name (e.g. PLAYPAL) anywhere before SS_START, else it'll crash (due to sprite loader weirdness). Also technically SS_START isn't required, but organization is great. :P]

The fact that we need a patch though is technically a bit more problematic since HHE has less support, but it'd be a simple matter to add DECORATE/DEDs for the trees that do the same thing, enabling it to work in ZDoom/Doomsday. I've never used HHE, though, so I must ask: can you rename sprites via Text like you can in DEH? It's essential for the trick to work.

Whew, long walls-of-text. Point is we can most likely make this work in H+ just fine. It may be worth distributing the project with a pre-patched H+ EXE with the wad for convenience (along with the external .hhe of course) so folks won't have to go out of their way to download+run the tool. Does entryway allow such a distribution, though? I can't find the license info on sourceforge since I'm probably a dunce.

Xaser said:

There's one improvement to Scifista's edit that can make it work in H+ without deusf merging: if you put the sprites between SS_START and S_END (not SS_END) lumps, the new sprites will load without error*. From here, you can use DEH (or HHE in this case) to change the sprite names to work.

It WILL NOT work without the HHE patch, though - and the patch will ONLY work in Heretic+ and Chocolate Heretic. The way you describe it, it may sound that simply putting standard sprites between SS_START and S_END markers would prevent Heretic+ from crashing - but NO, I just did it and it obviously crashed the game. The HHE patch is completely necessary, otherwise my SLADE3 edit appears as the best solution.

I think that I've already suggested the optimum here, a few posts above:

Let's make a HHE patch that will change sprite names of small pillar and stalagmites, for example to HTR1, HTR2, HTR3. Rename the tree sprites to HTR1A0, HTR2A0, HTR3A0, put them in the wad and place a S_END marker behind them. Behind this marker, let's put SS_START and SS_END markers, and place the tree sprites between them again, this time named as the original sprites: STGSA0, STGLA0, SMPLA0. They will be ignored by vanilla, Choco and Heretic+ (because of the S_END marker before them), but advanced ports should catch them.

If someone can make the patch, I'd appreciate it, because I've already tried myself, but HHE.EXE shows corrupted texts to me.

Either you're doing something wrong, or there's a difference in Heretic that makes it not work the same. If set up properly in Doom, failure to load the patch will only result in the original actors being shown; no crash (again, see D2TWID).

The SS_START/SS_END trick is a neat addition though, since yeah, that'd get ports to load it without any actor mods necessary.

You're right, but I was talking about the sprites named SMPLA0, STGSA0, STGLA0. You said what to do and briefly added "From here, you can use HHE...", you didn't emphasize enough that it's absolutely necessary to actually RENAME the sprites + have the HHE. It's clear to me that it works that way, but it might not be clear enough to Egregor, so that I wanted to emphasize that simply altering my SLADE3 screenshot according to your SS_START + S_END advice won't work that easily, in fact not at all.

Ah, okay -- my post had an error in it. When writing it, I had a dangling sentence fragment which I deleted 'cause I forgot what I was trying to say. "Rename" was the operative word I was missing -- derple.

[EDIT] If it's clear the issue was "hey you forgot to say to rename the sprites" though, point that out instead so the post is corrected without any back-and-forth. Had I been absent, the lack of conclusion to the conversation would've been extra confusing to Egregor and others. :(

Xaser said:

Does entryway allow such a distribution, though? I can't find the license info on sourceforge since I'm probably a dunce.

He can't really claim any copyright on the modified heretic.exe (it's still id software's program).
Just the patching tool he wrote is his.

Xaser said:

[EDIT] If it's clear the issue was "hey you forgot to say to rename the sprites"

Sorry, my bad. I didn't realize that this was the critical statement that was missing, and that simply stating it could have been enough. I've seen your post as basically correct, just confusingly complex. I've improvised an answer, even more confusing one, as it seems. Again, sorry for being like that.

Here's that update to The Reservoir with the difficulty settings implemented. Let me know if anything needs fixing.

Tormentor667 said:

Why not finishing one community project before starting another similar one?

I was thinking that we need to get more people involved with making Heretic maps. It doesn’t matter if they are vanilla of zdoom. We just need more good Heretic maps.

I was also thinking that if someone makes a vanilla style community project all maps should be allowed to be used for other projects. If the maps work for Blasphemer then Blasphemer can use them. If they work for Hpack then they can be used in Hpack.

If they are tiny or small I would like to use them for one of my projects. For example in the 3 episode version of Heretic: Treasure Chest “Hell’s Maw” and “Earthquake” would work for my project while others could be used to help balance others.

Maps from Egregor’s other CP HYMN were donated to Blasphemer. This makes it have some more good maps to work with.

I was also thinking that if one starts a CP they should not limit the mappers to deadlines, That way mappers have time and elbow room to pull off some impressive maps and ideas.

Egregor said:

If you want my opinion on HPack release it in 9 level episodes. This could be done once each year, give or take. Each release could also include balance/bug fixes from the previous years episode. Doing this would create short term release goals, as well as get folks playing the maps, thus generating interest in contributing to more maps down the road.

Egregor brings up a good point here. If it is a very large project, why not release them in smaller chunks so others can provide feedback. This will in turn make the maps better by my opinion.

Egregor said:

At this point; no. With 500 textures to choose from there should be enough textures to make most any idea work. Hopefully this isn't a deal breaker for you. Make sure you have version 3 of the texture pack as about 100 textures/flats were added to it.

500 textures and flats is not a large number. Hexen has about 600, Bakers Legacy has 1701 textures and my ultimate work in progress texture pack aimed specifically for Heretic will have around 3K total textures.

Most of these textures were spliced from various community resources, from realm667, Hexen and scaled down versions of Egyptsoc from Q3 and some sky boxes from Cube 2 and Red Eclipse.

3k textures?!, Can't wait. We need more Heretic textures. Awesome.

Halfblind said:

I was also thinking that if someone makes a vanilla style community project all maps should be allowed to be used for other projects. If the maps work for Blasphemer then Blasphemer can use them. If they work for Hpack then they can be used in Hpack.

I don't get it, why should we reuse maps that were already released? this would lead to a mess of shovelware that are basically the same mapset with or without some maps in. This does not make any sense.

Maps from Egregor’s other CP HYMN were donated to Blasphemer. This makes it have some more good maps to work with.

At last was decided to not use them for the reasoning above, if those maps were to be rereleased as blasphemere maps, why bother releasing them as heretic's one (or vice-versa)?

I was also thinking that if one starts a CP they should not limit the mappers to deadlines, That way mappers have time and elbow room to pull off some impressive maps and ideas.

No good if you ask me, having no deadlines only means that the project will be eventually forgotten by everyone, simply becouse "there's time".

Anyway, good to see there are already some contributors! i did not had any time lately to play anything, but i'll try to give some feedbacks soon!

Cacowad said:

I don't get it, why should we reuse maps that were already released? this would lead to a mess of shovelware that are basically the same mapset with or without some maps in. This does not make any sense.



At last was decided to not use them for the reasoning above, if those maps were to be rereleased as blasphemere maps, why bother releasing them as heretic's one (or vice-versa)?



No good if you ask me, having no deadlines only means that the project will be eventually forgotten by everyone, simply becouse "there's time".

Anyway, good to see there are already some contributors! i did not had any time lately to play anything, but i'll try to give some feedbacks soon!

I agree with all of these points. Your point about deadlines, however, is not true in all cases.

Cacowad said:

I don't get it, why should we reuse maps that were already released? this would lead to a mess of shovelware that are basically the same mapset with or without some maps in. This does not make any sense

Not accepting donated maps for Blasphemer is a terrible policy. Even FreeDoom, which benefits from Doom's much larger modding community, uses already-released donations (like the entire episode Double Impact) to avoid having missing maps. Heretic has a very small modding scene and a project like Blasphemer will never be finished if you reject contributions that have been previously released. You will never get enough exclusive contributions.

I feel that Blasphemer is a special case, similar to Freedoom, so reuse/donations are totally fine there. It's the earlier comment in regards to "every Heretic project should share maps" that doesn't make any sense to me. :x

Obsidian said:

Here's that update to The Reservoir with the difficulty settings implemented. Let me know if anything needs fixing.

Whether anything needs fixing might depend on the port used. It plays fine in ZDoom with ROPTEX4.wad. But.

I opened it in an editor to look at a scrolling floor issue I noticed. In the Lich room, the four sets of "moving water steps" carried me along - they were scrolling. But only on the southern steps, sectors 289 & 290 were the actual flats scrolling (east). On all the other steps, I was moving, but the floor flat wasn't. The same is true in the secret area above the waterfall; some are, some aren't. But all the water under the outdoor bridge is. And I don't think any of the floor flats in the coffin area above the Lich room are moving. All the water flats are animating correctly, so that isn't it. Is this just some sort of ZDoom issue?

Also, when I opened the map, I saw what appeared to be missing textures in the editor. It looks like you added the PATCH name to the linedef, for example W_132, when the actual TEXTURE2 name is MONK16. Also W_075, W_136 and Z40. But they showed up in the game fine. Is this another ZDoom only issue? No idea how other ports would handle this.

I agree with Xaser about Heretic projects sharing maps. Just make some maps for it if you want more maps. Don't be lazy. End of disucussion.

Oh my gee, yesYesYEs, I am so in.

EffinghamHuffnagel said:

Whether anything needs fixing might depend on the port used. It plays fine in ZDoom with ROPTEX4.wad. But.
steps, sectors 289 & 290 were the actual flats scrolling (east). On all the other steps, I was moving, but the floor flat wasn't. The same is true in the secret area above the waterfall; some are, some aren't. But all the water under the outdoor bridge is. And I don't think any of the floor flats in the coffin area above the Lich room are moving. All the water flats are animating correctly, so that isn't it. Is this just some sort of ZDoom issue?

Also, when I opened the map, I saw what appeared to be missing textures in the editor. It looks like you added the PATCH name to the linedef, for example W_132, when the actual TEXTURE2 name is MONK16. Also W_075, W_136 and Z40. But they showed up in the game fine. Is this another ZDoom only issue? No idea how other ports would handle this.

In Vanilla Heretic, the scrolling flat/conveyer sector specials are bugged so that only the east ones scroll the flat. Doomsday fixes this. ZDoom doesn't.

Unlike Vanilla Heretic, if ZDoom doesn't find a texture with X name, it looks for a lump with that name and uses that instead.

Vermil said:

In Vanilla Heretic, the scrolling flat/conveyer sector specials are bugged so that only the east ones scroll the flat. Doomsday fixes this. ZDoom doesn't.

Unlike Vanilla Heretic, if ZDoom doesn't find a texture with X name, it looks for a lump with that name and uses that instead.

Huh! Twenty years I've been playing Heretic and I never noticed that before.

And you'd think ZDoom would have fixed things over the years that were obviously broken from the start. It's not like they'd be putting the arms back on the Venus de Milo. I guess if they never fixed the powered-up Phoenix Rod bug, why should they bother with scrolling floors.

Thanks for the info. The things you learn!