Unless for some reason -fast -respawn doubles ammo even though individually they don't.

oops, i forgot about that. I usually use -fast and -respawn on -skill 1 to play people's levels in a Nightmare-like mode that's not too masochistic. Skill 1 doubles ammo like skill 5 does. Do some source ports let you cheat on Nightmare? I'm sure ones with a console have some kind of override command for cheat codes right?

40oz said:
If you run Doom on -skill 4 with the -fast and -respawn parameters, you can achieve the same effect of playing Nightmare, and you will still be able to use cheat codes. I can be more specific but I need to know which source port you use.

I'm afraid that I lack the skill to make something that pretty (with floor textures), but can I offer you a utility that will export the map in a very simple manner (think editor/SLADE or automap style)?

sector666 said:
I hope my problem isn't too niche. I'm making a texture pack for Doom 64 ex which includes a bunch of custom skies. As Doom 64 renders its skies in realtime, I could really use something that makes a 64x64 preview png for every skydef in a wad. If it had an option to insert the previews into the wad too that would be perfect.

I had started doing this by hand myself but with a lot of skies something automated would be much more sensible.

...

If you think you might make this I could get into some more specifics that would be useful (stuff like adding a T to indicate skies with thunder).

I'll pencil it in. It does seem pretty niche, but it might prove to be interesting enough to attempt.

MTrop said:
Any MD2 exporter I could make will be terrible. It would do no optimization or welding, nor would it optimize it into separate OpenGL commands. You're better off using MD2Tool to do it.

By MD2 exporter we are talking about exporting 3d models from modern versions of Autodesk Maya into md2. MD2Tool does not do that. It isn't really needed seeing as bcwood is able to create MD2s from maya files but something like that would allow both of us to create MD2s which would speed up our work.

MTrop said:
I forget if I asked you want you would want it to do or make easier, exactly. Something about skins or whatever? Saving of any settings?

We are working on a 3d Conversion Doomsday Engine mod called Doom Ascension. There currently is no md2 exporter for current versions of Maya so our MD2 conversion process is quite tedious and involves throwing our models around to different programs until we get something usable. I realize that this isn't really something you are looking to delve into but I just thought I'd throw it out there.

MTrop said:
So, long story short, when used in conjunction with TexSpy, it should grab only what you need to run the map, like if you typed something like this:[code]texspy map*.wad -textract | textract textures.wad -base doom2.wad -o out.wad

I'm trying to use texspy and textract in order to cut the fat off of a compilation WAD containing many maps. The maplist has changed over time, but old textures still remain from maps that are no longer a part of the compilation. My goal is to clean out these resources that aren't needed.

Can you explain whether and exactly how that could be done with your tools, texspy and textract? Can you provide the commands for a compilation.wad example? I would greatly appreciate it.

jac0b said:
I'm trying to use texspy and textract in order to cut the fat off of a compilation WAD containing many maps.

...

Can you explain whether and exactly how that could be done with your tools, texspy and textract? Can you provide the commands for a compilation.wad example? I would greatly appreciate it.

Sure!

While TEXtract won't really remove things per se, it can definitely copy the texture resources from a WAD and set them aside.

TEXtract takes a list of texture and flat names, and then exports them to another WAD from a source and base. TexSpy can provide a list that TEXtract can read, so you don't have to put one together yourself!

...which means it will read in from the list "texturelist.txt", carry over only the texture information in BASEIWAD.wad, extract actual textures from TEXTURERESOURCES.wad, and output it all into OUTPUT.wad, which will contain ONLY texture info, if it is a new WAD.

But instead of a list, we can use the pipe "|" character to pipe TexSpy's data into another process (in this case, TEXtract). So, in your case, if you were modifying DOOM 2:

I also noticed issues with animations in game. It appears that only the first texture within an animated sequence as described in animdefs is copied into the new texturex.

If you process this, please let me know how it turns out and what I need to do to end up with an output.wad that contains a texturex, pnames, and graphics files called for by the input.wad's maps, cutting all the fat.

code:0.9.3BETA
Put "BETA" in the version to make it a proper "beta".
If a WAD wasn't found (and can't be created), this would just end. Now it
outputs an error message.
In some cases, TEXtract would not export the data correctly. Now it does.

This version should output the patches. Strange that it didn't work before. It works now. It won't read ANIMDEFS just yet, though. Still, if you know the names of the textures, just add them to the list that TexSpy would generate, and it'll pull them.

EDIT: Also updated TexSpy and ThingSpy due to a change in the main Doom library.

The CMD output shows textures being copied, but again they only appear within texturex. The patch graphics were not transferred. Feel free to try yourself and see what I mean. Hope it's not user error on my part.

jac0b said:
The CMD output shows textures being copied, but again they only appear within texturex. The patch graphics were not transferred. Feel free to try yourself and see what I mean. Hope it's not user error on my part.

When I tested TEXtract with your WAD, I noticed that your "PP_START" header lump was in the wrong place, and included all of your sound, map, and music resources in the patch namespace as well. I had moved it to where it should have been before I tested.

...Or maybe it's a file buffer issue? (WARNING: Incoming techie talk) WadFiles are RandomAccessFiles, so maybe there's something being saved twice over before one operation flushes? I'll have to look into it some more, but I know I had it working with your WAD at some point, which makes this pretty frustrating (and I did witness it NOT working at some point, too).

Thanks for testing, though! I'll get to the bottom of this soon enough!

EDIT: Did some testing - it looks like it is indeed some kind of buffering issue. A fix will some soon.

Scratch that - it is definitely the placement of your PP_START marker. The PP_START marker should be at the position right after SNDINFO and before NSKY1. It works after that.

Though I'm not exactly sure why that is - it may be tripping up the exclusion algorithm for what not to include. It's a little too tempting to just say, "garbage in, garbage out," though.

So, I've uploaded the MyIdGames program - hopefully it is useful to a bunch of people. See the main post. It should be easy enough to use, but you should still read the README, anyway.

WADSort is almost done, but it ruins badly-organized WADs (for instance, a namespace marker placed in the wrong location). Not sure if it is even worth doing, because if you are going to put together a WAD, you are going to organize it anyway. But, I suppose it could be useful to those who just throw resource together and want to end up with something organized in the end.

Next up is MD2Tool GUI, finally, or maybe the WAD replacement detector, if it's quick enough.

WADSort is now available! It sorts all sorts of known lumps, map data and lumps in namespaces.

WADSort re-arranges lumps IRREVERSIBLY. If you are unsure about the
arrangement of the lumps in the source WAD and whether this utility will sort it properly, back it up yourself, or use the "-backup" switch.

The utility that figures out what replaces what is coming. So is the MD2Tool GUI.

I am looking for a tool that can dump the complete set of properties of all things, lines, etc. in a WAD map in a human-readable format and in a reproducable way. I want to use it to spot the difference between two (not too different) WAD maps using e.g. "diff -u".

fabian said:
I am looking for a tool that can dump the complete set of properties of all things, lines, etc. in a WAD map in a human-readable format and in a reproducable way. I want to use it to spot the difference between two (not too different) WAD maps using e.g. "diff -u".

That's doable, but I'm wondering if I should roll some map-centric stuff up in an all-encompassing tool, or as smaller individual ones...

fabian said:
I am looking for a tool that can dump the complete set of properties of all things, lines, etc. in a WAD map in a human-readable format and in a reproducable way. I want to use it to spot the difference between two (not too different) WAD maps using e.g. "diff -u".

In order for the comparison to be independent of order of appearance of things and other elements of a map (the positions and types might be the same, but they might have been saved with a different order), such an utility would need to define some sort of absolute metric based on a thing's or element's properties, and not its sequential number e.g. things are first sorted by type, then by x coordinate, then by y coordinate (and there could still be ambiguity in the case of overlapping), sectors should be sorted by center, then area, then height, etc. in order for two visually identical maps (but with VERY different sequential numbers) to be comparable.

Maes said:
In order for the comparison to be independent of order of appearance of things and other elements of a map (the positions and types might be the same, but they might have been saved with a different order), such an utility would need to define some sort of absolute metric based on a thing's or element's properties, and not its sequential number e.g. things are first sorted by type, then by x coordinate, then by y coordinate (and there could still be ambiguity in the case of overlapping), sectors should be sorted by center, then area, then height, etc. in order for two visually identical maps (but with VERY different sequential numbers) to be comparable.

In general you are right, but my specific case is simpler: I'd like to suggest some map modifications to the Freedoom project. And instead of the usual manual and error-prone changelog (i.e. replace Thing X by Thing Y, increase light by Z, ...) I'd like to submit a machine-generated but human-readable diff between both maps, i.e. before vs. after.

I got used to submitting source code patches to open-source projects and find that submitting a binary file with some accompanying text just feels wrong. :)

fabian said:
In general you are right, but my specific case is simpler: I'd like to suggest some map modifications to the Freedoom project. And instead of the usual manual and error-prone changelog (i.e. replace Thing X by Thing Y, increase light by Z, ...) I'd like to submit a machine-generated but human-readable diff between both maps, i.e. before vs. after.

The problem is that the "diff" will be generated against an already "compiled" binary, not a descriptive source file, so unless you have 100% predictable editing tools (e.g. things get saved always in raster-geometric order), especially if collab editing with other people is involved, no such method will be 100% reliable. Actually, it can prove a surprisingly ill-posed problem if everybody uses different editors

I think that this is something a lot of people could use, not just me.

Is it Console or GUI-driven (command-line or windows and junk)?

GUI-driven would be ideal.

What would it do?

This utility would allow the user to successfully merge PWADs with IWADs, resulting in a stable IWAD resource that can be played in multiple ports. What could possibly be better? Well, if you could merge both ways, IWAD into PWAD and still have it remain usable in most ports (I've tried this...doesn't work). WinTex and XWE are not ideal in this regard and their GUI leaves something to be desired.

How would this be useful to you or others?

A lot of people, myself included, don't have access to a stable, quality wad merging tool. In that same vein, a lot of people ask for certain wads with certain features so they can strip them into a separate PWAD to merge into an IWAD. This would make it easier for them to do so for themselves. Easier and streamlined being the key words and point of this request.

Maes said:
The problem is that the "diff" will be generated against an already "compiled" binary, not a descriptive source file, so unless you have 100% predictable editing tools (e.g. things get saved always in raster-geometric order), especially if collab editing with other people is involved, no such method will be 100% reliable. Actually, it can prove a surprisingly ill-posed problem if everybody uses different editors

I see Maes's point - it would be extremely unhelpful to the user if map elements were changed and the ordering gets jumbled - delete a sector and everything can potentially move. And if the diff detects differences, there's no way to track them to objects since each object is not explicitly ID'ed on creation. It may be less useful than we thought.

Job said:
...PWAD to IWAD Merger...

Are we talking making IWADs from PWADs? I can see how that would be useful for standalone projects, but I thought that most ports can do that virtually with DEUSF-like merging options (like what Chocolate Doom does). Do you have a real-world example so that I can understand the issue better?

MTrop said:
Are we talking making IWADs from PWADs? I can see how that would be useful for standalone projects, but I thought that most ports can do that virtually with DEUSF-like merging options (like what Chocolate Doom does). Do you have a real-world example so that I can understand the issue better?

This isn't intended as sarcasm, I just think I may not have been clear ad I could. What I'd like is this:

It would be great if this went both ways (regardless of order) to produce an enhanced IWAD. My recent example is stripping PSX Doom sounds from a wad, file by file, to create a lump/PWAD with only those resources. I then attempted to merge that with the Doom 2 IWAD in both Want ex and Deutex and ensured only the same files were replaced, but that new Doom 2 IWAD would not play. In this case, I tried it with GZDoom, but it errored out. I hope I did a better job of explaining this time.

There are probably a handful of other features I could suggest, but the issue I mentioned is frustrating for me.

I have to ask -- why are you doing that? As MTrop mentioned, most if not all actively maintained source ports provide options to do that "virtually" using features of their respective resource managers. Even Chocolate DOOM. Is this for use with ye olde doom.exe ?