Sehacked codepointers

What exactly is keeping Sehacked from having access to the codepointer redirect table (or what it is) the same way Dehacked can? Is it not discovered yet? Or does Strife use a different action function structure? Because currently you cannot change codepointers with Sehacked. If there's found a way to change codepointers, vanilla Strife modding will get revolutionized.

printz said:

vanilla Strife modding will get revolutionized.

Uh... Even with the non-vanilla Strife-supporting engines out there, Strife is pretty much the game with the least modding activity out there, behind even Chex Quest. So, it doesn't seem to me that it really needs some revolutionizing.

Furthermore, what good would a "vanilla Strife mod" be if it only works with the vanilla executable plus sehacked? Dehacked patches are supported by practically all Doom ports. Sehacked patches... aren't. There's SvStrife, but it's a discontinued port, replaced by ChocoStrife.

Speaking of discontinued, who would work on this new version of sehacked? Would it have a chance of becoming an actual standard, supported by all actively-developed Strife-supporting ports?

Frankly, the last thing we need is more blehackeds out there. There are better ways to add or modify content now.

Gez said:

Furthermore, what good would a "vanilla Strife mod" be if it only works with the vanilla executable plus sehacked? Dehacked patches are supported by practically all Doom ports. Sehacked patches... aren't. There's SvStrife, but it's a discontinued port, replaced by ChocoStrife.

If I'm not wrong, Chocolate Strife will support SEH files, and if we're lucky, Eternity will as well.

Speaking of discontinued, who would work on this new version of sehacked?

Either we're lucky and Gokuma returns and is willing to work on it, or someone else gets permission from him to evolve the code.

Would it have a chance of becoming an actual standard, supported by all actively-developed Strife-supporting ports?

What standard complication are you talking about? All that is needed from this topic is to find (if existing) a way to edit codepointers like in Dehacked. If it doesn't exist, then it won't be feasible. The way it's implemented in DEH files is like this:

Pointer n (Frame f1)
Codep Frame = f2

If it's a port, just read frame f1 and map its action to that of f2.

Frankly, the last thing we need is more blehackeds out there. There are better ways to add or modify content now.

Yeah, but they all currently require ports that can only approximate how Strife truly works, and give gratuitous power to the modder. I'd rather have mere mapping with Dialogue Scripting and basic ability to change the things/frames/sounds/some actions. Not more.

I'm pretty sure most people playing Strife now use ZDoom, GZDoom, Skulltag or Vavoom to do so; rather than the original or the still-experimental ChocoStrife. Things like bug fixes, unlimited saves, higher resolution and access to a console are powerful motivators for non-purists.

Guess what isn't supported by these ports?

Now you may think that a clean and clear content definition language is "gratuitous power for the modder", but it's a lot safer from a code perspective than the monkeying around that a exe hacking utility provides. Especially given how frail some of the Strife codepointers are to begin with. You can crash the game if you muck up the firehand states, for example.

Gez said:

I'm pretty sure most people playing Strife now use ZDoom, GZDoom, Skulltag or Vavoom to do so; rather than the original or the still-experimental ChocoStrife. Things like bug fixes, unlimited saves, higher resolution and access to a console are powerful motivators for non-purists.

Guess what isn't supported by these ports?

That argument doesn't work. Those ports are used because they're the only available ones. Chocolate-Strife isn't used because AFAIK it's not done yet. And vanilla Strife is used as often as vanilla Doom(+), Heretic(+) or Hexen(+). If someone likes to run those files as vanilla, they'll also like to run Strife as vanilla. DOSBox exists and is pretty portable. Likewise, if someone likes running Chocolate-Doom, so will they like using Chocolate-Strife, once it's completed.

If a mod isn't used because it contains vanilla-only features, too bad. People interested enough, or who don't worry about using something else, will eventually download DOSBox and use Strife1.exe or Sehacked and Strife1H.exe. Those who refuse to use something else than port X, it's their own loss. If it's their OS which disallows it, too bad as well. But DOSBox's download page shows lots of OS choices. I hope the lacking ones can be worked around...

Now you may think that a clean and clear content definition language is "gratuitous power for the modder", but it's a lot safer from a code perspective than the monkeying around that a exe hacking utility provides. Especially given how frail some of the Strife codepointers are to begin with. You can crash the game if you muck up the firehand states, for example.

I'm not just talking about DECORATE, I'm more worried about the power of ACS scripting, which belongs to Hexen, not Strife, and could be useful to bypass lots of tricks that would be done solely by Strife activator build-ups.

Why are you so hellbent against this anyway? The port you're contributing to doesn't support SEH files in the first place. It wouldn't gain anything if a WAD already using SEH files uses an extra feature (if possible). And if I still want ZDoom support, I will include ZDoom-compatible features in it (DECORATE, MAPINFO). It's likely Kaiser, Gokuma and Quasar who would rather have a say on this.

Chocolate Strife is way way outside of an "experimental" phase. It is, for all intents and purposes, finished.

I would guess that be able to make a comment like that, you have not actually tried using it yet.

I'm just going by the fact it's in the v2 branch rather than the trunk. I always consider branches to be experimental.

Sehacked doesn't support code pointers? I'm kind of surprised by that. Are you sure?

If you really care about it, the source code is on the website :-)

I would assume it doesn't support it simply because Gokuma wasn't able to figure out the way in which DeHackEd has to handle them and re-adapt it to the Strife EXE.

When you modify codepointers in DOOM, you're not actually changing the value of state_t::action in the states[] table, like you would expect. You can modify those values in the executable all day until you're blue in the face and it will never have an effect on the game.

At first this is going to seem really bizarre to you. How can you modify a binary value in an EXE and it not affect the program? It does load into memory from the file, after all.

So you come to the conclusion that the values must be getting modified during load somehow, and reverted to their original values. AHA! If you come to this conclusion, you are 100% correct.

The reason is that DOS programs are compiled into what is known as relocatable code, meaning that their base address is not fixed, unlike Win32 programs.

In the header of the linear executable is a region known as the relocation table. It is a segmented list of every pointer value in the program's code and the relative address that pointer should start out with if the program loads at its preferred load address. When the program does NOT load at its preferred load address, the operating system's executable loader is required to iterate over the relocation table and add in the difference between the preferred load address and the actual load address to these offsets.

So for example if the preferred load address for DOOM is 0x10000 (and it IS, as all Watcom extended mode programs want to load there), and a code pointer function is at nominal offset 0x40000, but the program actually loads at 0x20000, then the value of that codepointer needs to be changed to 0x50000 so that it still points to the same function which has moved in memory from where it wanted to be.

Unfortunately the format of the relocation table is extremely complicated. There are multiple types of relocation table entries, for 8, 16, and 32-bit values, and the table is divided up into segments - one table for each segment of the file.

xttl was able to figure out the Watcom relocation table format starting nearly from scratch and knows how to modify it freely, even adding or taking away entries. I myself do not know enough about it though.

Okay, I think there is a 1:1 correspondence between the codepointers in the relocation table and the codepointers in the states table. The thing left to do is finding out which frame number goes to which relocation table entry, with as little trial and error as possible.

Judging from Dehacked's example, the order of pointers in the relocation table looks totally arbitrary. What is the order they're written in the EXE, does it depend on the order the functions were compiled?

Does Chocolate-Strife read "Pointer x (frame y)" "Codep frame = z" SEH entries just in case?

Trying and erring (which I fear I'll have to) the RPG-like Strife codepointers will be a lot harder than in simpler Doom.

The worst part is that I don't have all Strife versions to verify, but chances are high that people will be using any of them -_-

Where can I find the various Strife version executables? Do they all work with the same STRIFE1.WAD and VOICES.WAD?

printz said:

If a mod isn't used because it contains vanilla-only features, too bad. People interested enough, or who don't worry about using something else, will eventually download DOSBox and use Strife1.exe or Sehacked and Strife1H.exe. Those who refuse to use something else than port X, it's their own loss. If it's their OS which disallows it, too bad as well. But DOSBox's download page shows lots of OS choices. I hope the lacking ones can be worked around...

... if you want to lose your audience, be my guest. Expecting anyone to play in eye-cancerous 320x200 these days is something I'd consider very bad style.

Yeah, sure, make such a mod but I doubt you get many cheers for that outside Doomworld which is probably home to 90% of vanilla/choco fans in the world.

printz said:

Why are you so hellbent against this anyway? The port you're contributing to doesn't support SEH files in the first place. It wouldn't gain anything if a WAD already using SEH files uses an extra feature (if possible). And if I still want ZDoom support, I will include ZDoom-compatible features in it (DECORATE, MAPINFO). It's likely Kaiser, Gokuma and Quasar who would rather have a say on this.

Let's just phrase it like this:

From today's perspective even Dehacked is a maintenance nightmare. It effectively prevents any cleanup of the game's actor definitions because you can't just do it the 'right' way with monsters being a separate class from decorations or pickup items. The hacks ZDoom has to go through to force this insanity into its class hierarchy are almost ludicrous.
And the other ...hackeds are much, much more troublesome because the games are so much more complex - that's why ZDoom does not support them.

Fortunately, until now, not a single serious mod for Heretic and Hexen has surfaced making life easier for everyone involved.

Now start using Sehacked as an editing tool and all the nightmares will resurface in a form twice as bad. If Quasar wants to subject himself to that, fine, but I'd honstly still prefer if Sehacked was left in the trash where it belongs (and where Dehacked would also belong in a better world.)

Don't sweat, if popular ports don't support hacks, I'll provide equivalent native definition lumps (eg DECORATE) in the wads for them, while allowing people who do want 320x200 and DOSBox to use hacked vanilla executables.

EDIT: and I disagree with your intention to separate monsters from items and decorations. I see them as too similar to be separated, especially monsters and decorations, who might be modded to be far more dynamic and less black and white (decorations that turn into monsters).

printz said:

EDIT: and I disagree with your intention to separate monsters from items and decorations. I see them as too similar to be separated, especially monsters and decorations, who might be modded to be far more dynamic and less black and white (decorations that turn into monsters).

There are a lot of ways to do that with a good content definition language without forcing everything to be the same class.

It'd also allow to improve performances since some of the CPU-intensive AI logic could be entirely avoided for pickup items and simple decorations, instead of having to be processed on the off chance it's really a monster...