WhackEd 4

[VGA]

I created a Doom Retro preset:
http://1drv.ms/1T6lqbG

This is basically the MBF preset with new unused states up to 3999!

Spoiler

The port author has made some small hardcoded dehacked changes to make the barrel smoother, create more smoke trailes for the rockets and added blood splats, I modified the preset to reflect those changes. Load doomretro.wad as a PWAD if you want to check out the blood splats.

Actually *new* usable states should be considered from 1089 to 3999.

EDIT:
Also, can you make the Thing lists alphabetically sorted? I lose so much time looking for stuff. It took me 1 minute to find the Barrel entry last night.

[exl]

I've added the Doom Retro tables. I really should find a more succinct way of describing that data, the Doom Retro table is 1.7 MB of JSON. :|

[VGA]

Errm, is there a way to rename sprite sets in Whacked? Like what you could do in Dehacked?

http://www.aspectsweb.co.uk/dehacked/deh09.html

[exl]

For non-Boom patches you can edit the sprite names in the strings table. I believe Boom doesn't support this though?

[VGA]

I don't know, heh. I was thinking about a functionality you could add: the user selects two deh/bex files and the program shows possibly conflicting changes. I mean, the program creates a list of modified strings, misc stuff and states for both patches and checks to see which ones coincide, if any.

I don't know how you have coded Whacked but maybe this is easy to implement?

[scifista42]

It should be relatively easy to implement, and doesn't depend on the way how WhackEd is coded. If you ever looked at a DEHACKED patch in plain text format, you'd notice that each thing, each state, each string, and each everything that gets modified / redefined in this very patch is preceded by an identifier of this thing / state / string / whatever. Finding out conflicting ones between two DEHACKED patches would be a classic algorithmical problem of finding identical numbers in two different sequences of numbers, respectively finding identical strings in two different sequences of strings, etc.

[VGA]

I don't want to code a cludgy string comparing programm for this. Also the syntax for DEH and BEX and the different blocks are a little inconsistent.

I'm guessing Whacked parses the files and creates nice python data tables of everything, it should be straightforward to do a comparison between these.

[exl]

I have patch merging on my todo list for some future version, is that your suggestion's end-goal? It would display and interface that shows conflicting changes in each table in a uniform manner, and allow the user to choose the table entry from which patch to keep.

[wallabra]

you could use a Translation creator and a resorce WAD would be made and automatically loaded with color-translated sprites of some monster so you can easily recolor a monster like the Chaingunner red cloth to grey. This would help in making some distinction between monsters that were edited via DEHACKED or whatever is BEX...

[VGA]

exl said:

I have patch merging on my todo list for some future version, is that your suggestion's end-goal? It would display and interface that shows conflicting changes in each table in a uniform manner, and allow the user to choose the table entry from which patch to keep.

Yes, my end-goal was to check two patches for potential conflicts so that the user knows if they can be used together without one overriding some of the other's changes.
If you also implement the ability to merge them in one new patch, that'd be useful, too!

@ Gustavo6046
No, I don't think you understand what I meant.

[VGA]

@exl

I found a fatal bug

Traceback (most recent call last):
File "src\whacked4\ui\editors\thingsframe.py", line 629, in goto_state_event
File "src\whacked4\ui\editormixin.py", line 182, in goto_state
File "src\whacked4\ui\editors\statesframe.py", line 825, in goto_state_index
File "src\whacked4\ui\editors\statesframe.py", line 355, in filter_update
File "src\whacked4\dehacked\statefilter.py", line 111, in update
File "src\whacked4\dehacked\entry.py", line 60, in __getitem__
KeyError: 'Cannot find patch key "parameter1".'

It happens half the time when I am dealing with a specific frame with a RandomJump code pointer. Something is seriously screwed up, when I select that code pointer the parameter fields show up but if I go to another state and then come back to the one with the RandomJump, the parameter fields don't show up.

Easiest way to recreate the crash is if you select a state from the Things window, that has RandomJump code pointer.

EDIT: Also I just noticed that zeroing out the code pointer doesn't null the parameters. Because I set the code pointer back to RandomJump and Whacked remembered the parameters from an earlier session.

[wallabra]

It was just a suggestion!

[exl]

VGA: thanks for the bug reports, keep them coming! :) As for the state parameters not being reset; the way I see it parameters are like other state fields so resetting them when selecting an action doesn't make that much sense.

[VGA]

exl said:

VGA: thanks for the bug reports, keep them coming! :) As for the state parameters not being reset; the way I see it parameters are like other state fields so resetting them when selecting an action doesn't make that much sense.

Hmmm, but if the user changes to a code pointer that doesn't have parameters, then they should be nullified. Otherwise they creep into the patch and are later parsed by the game without being needed. Anyway, no big deal. As long as the crash is fixed, hehe!

I have another bug report as I am venturing deep into the dark innards of dehacked: Whacked should allow frame number up to 28, since it starts at 0.
https://www.doomworld.com/vb/doom-editing/59450-maximum-number-of-frames-for-sprite-animation/

I don't think something like TROO^1 is valid.

Quasar said:

Each sprite name is limited to 29 frames: A-Z and [, \, ].

http://zdoom.org/wiki/sprite

You can have 29 frames of animation for any one sprite name, one for each letter of the alphabet plus [, \ or ].

[exl]

Thanks, fixed that too plus some other bugs. Here's an early 1.1.1 release: http://www.teamhellspawn.com/exl/whacked4/files/whacked4-setup-1.1.1-temp.exe

Added: A Doom Retro engine configuration (thanks to VGA).
Fixed: missing parameter names for the PlaySound and PlayWeaponSound state actions.
Fixed: the sprite label property not updating after selecting a sprite in the state editor.
Fixed: a crash when jumping to a state with the RandomJump action.
Fixed: choosing a 30th sprite frame.
Fixed: state parameters dissapearing when selecting a state.
Fixed: state action editing was possible in non-extended patches.

[VGA]

Thanks, no more crashes!

Do you know what would drive productivity up?

1) Being able to copy/paste the properties of a state.
2) Being able to select some states, right click and select "link frames" or something. And that would make each state's "next" point to the next higher one that is selected, until the last one.

For example, I select states 4,5,9,10 (order of selection doesn't matter). With that button Whacked would make each lower one point to the higher one, the last one's "next" stays the same I guess.

[exl]

Linking states that way is a very good idea! The copy and paste is great too, but I'm unsure what the behaviour would be when you've copied multiple states and then paste one, or multiple. Perhaps just allow copying only the first selected state and paste it's properties on one or possibly multiple selected states?

[VGA]

Hello, I was running out of sprite names so I asked Brad and he added 100 more, SP00 to SP99.

Here is the updated Doom Retro cfg:
http://www.megafileupload.com/euhF/tables_doomretro.zip


About the copy paste, I think all lines should be copied and when pasted they should be pasted all at once again. If the lines selected when copying are more than the ones when pasting, then the extra copied ones would be ignored. If they were less, then only that nummber of lines will be modified, the rest of the selected lines will be unmodified.

So if the user selects 9 frames (f.e. a death animation), he can then select haphazardly some blank frames from 1300 to 1350, not caring too much, then he pastes over and the frames from 1300 to 1308 get modified/overwritten, not the rest.

[exl]

That sounds good, I'll add it to the list.

[VGA]

As I was adding XDeath states to monsters that didn't have them, I noticed that with the way Doom calculates the chance for them, it's almost impossible for most of the monsters to even reach XDeath requirements.

I created an issue here:
https://github.com/bradharding/doomretro/issues/233
Brad added a new thing property "Gib health":
https://github.com/bradharding/doomretro/commit/64cba7dbb9e952a6d56ddccf25c650c64ffdc389

Errmm, do you have a way to programmatically add this property to all things, with a default value of their negative spawn health?

[exl]

In the past I used my text editor's macro functionality for that, considering how verbose the table JSON has gotten.

[VGA]

exl said:

In the past I used my text editor's macro functionality for that, considering how verbose the table JSON has gotten.

Can you do this reasonably easy or should I take over this modification to the Doom Retro cfg?

I can create an autoit script to add the new property, using a json library. It's 144 things total from what I've seen.

[exl]

I think I'll use that commit you linked to to fill it in myself when I get around to it. It will need a few small changes to WhackEd's code to work anyway.

[VGA]

Whacked is too strict when loading pwads for the previews. It does not accept *****0 lumps replacing rotations. I noticed this trying to use SKELC0.

Chocolate Doom refuses to load such a wad with an error about replacing rotations with 0 lump. But all other ports I've tried (prboom+, ZDoom, Eternity, Doom Retro) allow this just fine. So I ask for Whacked to allow it, too, or to provide some "feature" or "hack" to be employed in the tables json.

So the previews show the proper sprites in the editor, as what the game will show :D

[scifista42]

VGA said:

Chocolate Doom refuses to load such a wad with an error about replacing rotations with 0 lump.

That's because vanilla and Chocolate Doom don't support sprite replacements at all, unless ALL sprites from the IWAD are replaced or reincluded in the PWAD. In Chocolate Doom, you can simulate reincluding the non-replaced sprites by loading the wad using "-merge" parameter instead of "-file". In vanilla, you'd either have to put all IWAD sprites manually into your wad or use a tool named DEUSF to do the same thing automatically (this is typically left to the players to do themselves, so that the mapper doesn't need to distribute his wad with all IWAD sprites included), either way the wad would have to be saved that way.

[exl]

VGA said:

Whacked is too strict when loading pwads for the previews. It does not accept *****0 lumps replacing rotations. I noticed this trying to use SKELC0.

Chocolate Doom refuses to load such a wad with an error about replacing rotations with 0 lump. But all other ports I've tried (prboom+, ZDoom, Eternity, Doom Retro) allow this just fine. So I ask for Whacked to allow it, too, or to provide some "feature" or "hack" to be employed in the tables json.

So the previews show the proper sprites in the editor, as what the game will show :D

Sounds like that should be a configurable setting in the Patch settings dialog. Another feature for the list!

[VGA]

How can I change the Heal state of the Archville in Whacked?

And, out of curiosity, how did people do it with ye old Dehacked? I don't see that special state for the Archville...

[scifista42]

No matter which monster/object calls the VileChase codepointer, this codepointer is hardcoded to always start healing animation on frame 266 when a corpse is approached, unless frame 266 is modified to have next state = 0 and duration = 0, then no healing animation takes place, but the corpse is resurrected anyway, and contrarily to natural expectation, the healer doesn't disappear, but continues from his See state.

[VGA]

Oh, that explains it, thanks.

[plums]

Hey exl, another thread I just started reminded me that the last time I used WhackEd4 (before recent updates), I had problems with some vanilla-compatible string lengths. IIRC WhackEd4 gave you an extra 3 characters for all vanilla map names, but regular Dehacked doesn't give you that much space for all of them. For example "level 17: tenements" is actually the maximum length for that string already.

Is this something that could get fixed? If it's helpful I can provide string lengths for map names at least. You could probably parse them out of Chocolate Doom's source as well.

edit: A look in Chocolate Doom says the string lengths are just on 4-byte boundaries, so that is maybe easy to compute.