Convert Doom levels to Strife

I added a modified default.rsp for Dm2conv to the strife editing package on my site.

Grab dm2conv from DW's editing util section, replace its default.rsp with the modified one, and convert away. I'd already tested normal Ultimate Doom and Doom 2's levels with good results.

Usuage:
dm2conv whatever.wad convertd.wad @:DS

I suppose it would be unnecessary to post a link since there's already the homepage link at the bottom of my post.

Hey, I don't suppose you could do a reverse of that which can convert Strife levels (their line and sector types, at least) to Doom, could you? That would be like, another 1/4 of my work on the ZStrife project. All I would have to do then would be to emulate the enemy behavior in DeHacked and the script behavior in ACS. If you EVER wanna play Strife in ZDoom, I suggest we team up. :D

That would be almost like completely redoing what I just did except...

ZDoom can already load Strife1.wad like a pwad, so with just some thing conversion you'd be well on your way, except for those additional linedef types, which I haven't messed around with too many of and in many cases you could only substitute for with a script so it would be pointless and only confusing to convert it to a normal Doom line. Also there's already Strifetx.wad with all the textures in Doom and the original file I received from Nightmare also has the Doom switch textures still in it.

The thing conversion is simple but time consuming and there's the problem that Strife has a few hundred things while Doom only has 137. I guess you'd be better off adding as many things as possible with a decorate lump than converted them to the closest Doom equivalent to modify. Also Doom and Strife already use the same numbers for many similar things. You can see a lot commented out in default.rsp.

I'm a bit burnt out working conversions for now, but maybe I could still help you or give you some thing with map id# lists for the different games to work with.

Well, the DECORATE thing was the plan. I probably won't be "done" until about the time DoomScript comes around anyway, so it shouldn't be a big issue.

And I know so many Strife lines triggered scripts and not just normal map functions, but I was hoping you could write a converter that would convert all Strife line/sector types that DON'T match but have an equivalent function in Doom, and for any script-executing lines, maybe just have those ignored, or...

At this point, I don't know if it would be preferable to convert from Strife to Doom and then to ZDoom or straight from Strife to ZDoom. Converting from Strife to ZDoom directly would allow converting Strife script-executing lines/sectors to the ZDoom equivalent (ACS_Execute with zeroed arguments, of course, for me to fill in later), but using pure Doom format as the middleman, I'd be able to work in a much broader range of editors.

I'll pester you about it after the burnout fades. :P

All I know is I wanna play Strife with all the advantages of a modern port, including hi-res, mlook and actually running properly on my Win XP system. All you guys are doing, with all this "look what I have done with Strife now" talk is make me realise just how much I want it. :-P

Seriously though. All this work that has been done with Strife recently is very cool. The profile of Strife needs to be raised and we need to get something that feels like Strife even if a true source port is not possible. See the excellent Doom64 TC as a perfect example.

So yeah, more Strife stuff, more editing tricks and utils and UV, get ZStrife done dammit!!!!!111one

Ok Ok, yeah I know, we need "Doomscript" first :-(

Vavoom has some Strife enemies and weapons somewhat working. I wonder if multiplayer would actually work as it is now. You can at least take a look around Strife levels in open gl high res with it.

Gokuma said:

You can at least take a look around Strife levels in open gl high res with it.

Pssh, worthless.

Enjay: Heh, OK, as soon as I get it started. :P I kid, of course...

I've been playing strife for a while on my other win98 machine and I think I could code out the weapons, linedef and thing behavior. I was even planning on using the Prboom sources to mimic the strife game, but its that conversation/level switching system that got me stumped, forcing me to quit.

Deathman said:

I've been playing strife for a while on my other win98 machine and I think I could code out the weapons and enemy behavior. but the rgp element however got me stumped.

It's not a matter of could, really. Currently the behavior and such could be duplicated (maybe not the enemies with multiple weapons), and the levels could be reconstructed just as easily as any new levels can be built. However, I only asked Gokuma about modifying his converter in order to save myself some work. Don't worry, I'm already on this, heh.

As of now, I have made another update to strfedit.zip with some stuff and a huge chunk of quest stuff added to strfedit.txt.

What in particular was the problem with the level switching? Here's how it seems to me: The game is one huge hub and when you go to another level, it saves the state of the one you leave, carries your facing angle over to the next, and reloads state when you come back to the level before except places you at a map spot and maintains the facing angle you left the other level at as well as your inventory and attributes.

And while SeHackEd can't modify the game yet, what it can display so far gives a lot of insight on how things are set up and helps with hacking with a hex editor. Things still have the standard close attack and far attack frame. However it seems there might be some inaccessable attributes specific to different things. For example a crusader will do its flame thrower close attack from a little distance while reavers will only do their close up blade attack from right up close. Maybe there is no special attribute, and close attacks can simply be done from a further distance if it shoots a projectile instead of doing a melee attack. I could do a simple hack to test this theory. Then if any particular entity thing shoots multiple different Sigil shots it may simply be a code pointer in an attack frame to shoot random Sigil. The inquisitor seems to definately have some properties. Its flying frames are not specified under the thing. It just does them, kind of like an Arch-Vile just uses certain frames for doing its resurrection. It might also crush things it lands on top of without actuallt doing its close attack, or maybe that's just bull and it does its close attack in order to hurt things. The game's manual is wrong about it shooting lasers from its eyes.

CORRECTION: The inquisitor has nothing set for a close attack frame so that means it actually does crush things by landing on them.

EDIT: There's more to the level switching. See post further down.

Another correction: The crusader has nothing set for close attack, so it actually does have a special case alternate far attack animation. I think the flame thrower attack is specified as its far attack, and the triple missile shot is a special case like an Arch-Vile ressing or an Inquisitor flying. T

Ultraviolet said:

At this point, I don't know if it would be preferable to convert from Strife to Doom and then to ZDoom or straight from Strife to ZDoom.

I don't know how well the Strife line types match the ones available in Doom (or Boom) but if they don't match 100% it might be better to convert directly to ZDoom's format because with the parameters each line type has you will most likely be able to match much more types. I think that's worth much more than the availability of a wider range of editors.

How about disassembling strife.exe? hehe

Hirogen2 said:

How about disassembling strife.exe? hehe

Yeah, that would be fun. ;-) Unfortunately I don't have the time for that...

imo, I think it would be easier (and maybe faster) to create the code/port to match strife's behavior rather than trying to convert it to a doom port like zdoom.

I still would like to get Strife to operate on Prboom sources. Maybe I can give another try at making the port with the fully functional things/linedefs just for the heck of it.

Deathman said:

imo, I think it would be easier (and maybe faster) to create the code/port to match strife's behavior rather than trying to convert it to a doom port like zdoom.

I still would like to get Strife to operate on Prboom sources. Maybe I can give another try at making the port with the fully functional things/linedefs just for the heck of it.

Strife source code went *poof* a long time ago and was never released, so making a Strife port without a lot of gross-hacky-emulation that would be buggy and unreliable as shit is the only option aside from converting or reconstructing the levels... and that's a lot of levels...

Heh, changing text in scripts with a hex editor is just as easy as changing text in strife1.exe. Figuring out and changing what the scripts actually do other than just switching them around is another story though.

Some more info that should be helpful:
Gettable things aren't so much determined by sprites anymore. There's two things that determine what an item goes, where it goes (weapons/ammo, inventory, or keys), and the text it displays when you pick it up and or query it in your inventory with Q.
1. The sprite name, possibly only for weapons and ammo, determines what it gives you.
2. The class name pointer for each gettable thing always determines the text displayed and almost always what it actually gives you and where it goes. Unfortunately this can't be changed under a thing so it pretty much makes the thing itself, for example, thing 310 toughness (stat token) at hex address B5370 in strife1.exe, determine what you get. You can change the text else where but it won't change what the item gives you. I have to thank Janis for telling me this attribute/setting for things is a class name pointer.

One thing very cool is that any thing with a class name pointer can be made gettable. Although it would just be silly, you can make portable shop keepers you can pick up and drop out of your inventory. They'd only sell you items in levels that have scripting for it though and hopefully their script would still be intact after picking them up and dropping them back out. For fun I made rats into really nasty shootable bombs that you can pick back up and use again. What's funny is rats actually have a picture for going into your inventory instead of using the generic ? for unknown things.

I bought Strife a few months ago, but I stopped playing it because of the lack of mouselook and because it only ran on my old crappy computer. If you guys got a source port together, it would be *really* good. Thanks for all your efforts, and hopefully you'll be successful. If you ever need anyone to do some basic rudimentary stuff, I might be able to help. So if you ever need a grunt, drop me a line. :)

Gokuma said:

I have to thank Janis...

Janis... Janisdreg? Old member, IRC'er?

What's funny is rats actually have a picture for going into your inventory instead of using the generic ? for unknown things.

Haha. Well, maybe I can make an inventory rat easter egg of some sort in ZDoom...

Grimm said:

source port

Not likely. Gokuma is working on just modifying (or re-writing?) DeHacked to work with Strife, and I'm just trying to EMULATE Strife in ZDoom with a lot of cheap hacking. What you're talking about is at least a few years away, unless those Strife specs happen to somehow see the light of day...

Either way, having Strife in ZDoom will solve the no-mouselooking issue and the gamma issues I (and probably many others) have (very, very dark monitor, gamma correction level 4 in Strife is still waaaaay too dark).

Apparently Deathman and Janis Legzdinsh (Vavoom) are both working or have worked on Strife support in source ports. Janis and I have extracted a lot of info from strife1.exe. Ultraviolet is working on converting stuff. Nightmare converted the textures. Sparky made a Doom conversion of a level. I guess we'll get there eventually.

On second thought, the single player level transition is more complicated than I was thinking. It seems it also carries relative (not absolute) x or y position in relation from I'm guessing teleport new map line's center to the point of the map spot in the next level as if it was that center of the teleport new map line in the previous level. What's funny is it doesn't carry over z-position but if you exited in mid jump, it'll immediately make you jump in the next level.

The teleport new map line is given a tag that works like this...
The tag 2602 whould make it take the player to level 26 and map spot 02 in it.
In deathmatch mode the player just goes to a random deathmatch start instead.
In multiplayer mode (which is DM only) the teleport new map line has a different function. It seems to be like W1 Raise floor of tagged sector by a certain height. So instead of immediately taking you to another level, it lets you keep going and raises an exit switch out of the ground. The switch sector would have the tag 2602 in this example. Barricade things are placed in the level and set to appear in multi only to keep you from going too far. The normal exit switch special can be given a tag in Strife for it to take you to a certain level. So in this example its tag would be 26.

Player 1 start is apparently only used if a player starts on or warps to a level in single player mode, or if you hit a normal exit in the previous level. Coop player starts are apparently never used but I still put them in levels just in case. Hell, in map01 (Sanctuary) of Strife they mistakeningly put two player 2 starts and no player 4 start.

While tempted I'm not rewriting Dehacked, especially since there's already WhackEd being worked on and I'd need to learn some stuff first. I just did some little modification for Dehacked to load up strife1.exe and ran into some problems trying to get it to properly display sound names, sprites names, text strings, and the whole 1500 some frames (opposed to the first 900 some). Other than that, code pointers, and mixed up ammo amounts, it correctly shows all thing data, weapon data, and data for the first 900 some frames. Most of the data it doesn't display right, I can see with a hex editor. Except for cheat codes and miscellaneous settings (such as mauler cells/shot), which I have no idea where they are. Here is a forum thread about it with a link to a download which includes a not very stable compiled exe. I'm pretty sure it could be made to work with Strife perfectly. I just haven't figured it out.

Here is something that should come in handy. Hackstrf.cc is a program by Janis that's supposed to extract a ton of data and generate txt and code files. Hkstrife.cc is a copy I modified and put comments by my changes. However, I've been unable to compile either with DJGPP which I must be missing the correct libraries or something from. But just looking at the source gave me good info including more accurate offsets to work to work with, including the offsets for weapons altogether.

This thread on the ZDoom forum may be of interest.

Deathman, here is something that may be helpful.

Hmm, I'll check that out once I finish improving the doom64 code. Nice btw..

You guys definitely have my support on this, as I'd love to be able to play it again on my machine, along with source port features. All I can offer is a cheer, given my lack of expertise in coding, but that's better than nothing. :)

Let me know if you want me to get all frames to the flame thrower flame projectile and all the Sigil shots. I have to use a hex editor since I currently can't get SeHackEd to display past frame 966 correctly.

Have you managed to compile that strfhack.cc file yet?

*shrug* nope, haven't messed with it in a while

Heh Gokuma, did you read my pm's?

Just saw one PM from you. I rarely use them so I don't always notice them right away.

Well anyway, Im here in case everyone else suddenly drops dead, heh.

I replied.

BTW, while there's still no Sigil projectile frames, strifewp.txt has been updated.

Update: Added the Sigil and flame projectile frames