Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited

About MTrop

  • Rank
    Self-Described Legend

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I would also expect this as well. This is a strange bug, especially since it did a copy from itself to itself. I'll have to take a look. EDIT: Added an issue: https://github.com/MTrop/DoomTools/issues/52
  2. There is currently no way to convert a DeHackEd patch to a DECOHack source file. There is critical information lost in a DeHackEd file that would enable me to create a human-readable patch of some kind that makes sense, such as how states link to Things or Weapons. It can be inferred through some references, but in order to be correct, I would need to try to group together states in a meaningful way via the "Next State" indices (which is not always helpful), and then create stubbing for each Thing or Weapon that points to those states. All of that would require a lot of work and assumptions that I can never be sure of 100%, and even then, you'd still need to break up the results into something meaningful to yourself. Maybe one day when everything else is done I'll look into seeing if it is feasible in some way, but for the moment (and the future), it can not and will not be done. I'm sure you'll find it's still easier to port everything to DECOHack by hand. A lot of time spent modding is in design, rather than implementation, anyway.
  3. Yeah, maybe one day there could be consensus, but for now I'm just gonna go by whatever's in https://zdoom.org/wiki/Editor_keys as a basis.
  4. Should I go ahead and make that a reality? That's a really quick change on my part.
  5. Ooh - that's a good point. Didn't catch that. Next version! Or maybe we should rope one of the main SLADE devs in here, in case they also adopt DEH scanning for their map editor? I'd hate to discard a feature entirely - RGB would be more flexible everywhere, if adopted in both editors at some point. EDIT: It looks like SLADE supports the DB color id, but yeah - still misleading. I don't think I check for "value correctness" though, so it's not as big a deal, but it needs correcting for clarity.
  6. DECOHack v0.18.0 now supports this in the same way DECORATE does via the special comment directives in Things: //$Angled //$NotAngled //$Category <String> //$Group <String> //$Color <Integer> //$Colour <Integer> //$Sprite <String> //$EditorSprite <String> Update it here: https://mtrop.github.io/DoomTools/
  7. MTrop

    DSDhacked [unlimited everything]

    "In a vacuum" was probably an exaggeration on my part, but yeah - a much simpler DECORATE from the '04-05 era would be a more ideal starting point. Weirdly enough though, I would probably still stay away from the merging of Things and Weapons into "Actors." That feels like a product of ZDoom's early actor code and inventory systems merging and not how Doom functionally separates the two, despite the shared state table. At the moment, the only thing solid enough for the later-gen ports and easily accessible to the Boom-era-lineage ports is the DeHackEd format, and while it is painfully low-level, it is still a decent enough abstraction as an A-to-B mapping medium, even if the interpreting ports won't exactly implement it as such. The "unlimited" nature of DSDHACKED will already force implementing ports that already had a contiguous state table into needing to use a sparse index lookup at the very least.
  8. MTrop

    DSDhacked [unlimited everything]

    DECOHack's final feature set is incomplete and it would be a moving target for implementors. It was really never meant to be anything more than just a different (and hopefully easier) way to make DeHackEd patches without a GUI slowing me (or anybody else) down. Besides, even if DECOHack's exact DECORATE-inspired language were implemented in ports, you would have to emulate its logic for cobbling a patch together, and the results may not be 1-to-1 in terms of what it has to do regarding state allocation and all the other low-level stuff that needs to happen to create a functionally equivalent DeHackEd patch, not to mention implementing all of DECOHack's other procedural niceties like bulk-redefining fields and whatnot. As stated before, DECORATE is high-level. DECOHack has to make concessions (and have additional supporting language) to make it as flexible as low-level DeHackEd, because its goal is to be a DeHackEd patch creator (its ultimate goal is to be as flexible as Fraggle's DEH9000). Every implementing port would have to ensure that their implementations of DECOHack have equivalent results just for safety's sake. You don't have to worry about all of that if it compiles to a singular common output that every port can already interpret unambiguously. And if you wanted to use an uncompiled DECOHack-ish definition language for modding Doom in your favorite port family, why would you even want to care about the fine details of Thing table indices, State table indices, and so forth? It's a needless complication for a modder to endure when they want to just make stuff. That's why we have DECORATE! To reiterate, DECOHack is for making DeHackEd patches (especially within the limiting confines of DeHackEd), and even if MBF21/DSDHACKED didn't exist, it would still have a use. Any other purpose would be a waste of time for port authors to implement to ensure some kind of consistency when they don't have to. And if a "New DeHackEd Language" or "DECOLITE" were made, it should be made in a vacuum, and not take DECOHack's lead as a strict basis for it. Adopting its forced anachronisms would be a mistake in the name of progress.
  9. MTrop

    DSDhacked [unlimited everything]

    For what it's worth, a lot of points brought up about DeHackEd being this ancient "standard" format are pretty salient, but even if it weren't referencing a contiguous set of resources, it's still a low-level mapping of "stuff to other stuff". The moment when things get mixed with the more modern implementations of that stuff is when things get hairy. GZDoom's got pretty dang good DEH tolerance/support plus how it handles DECORATE/ZScript overriding, and Eternity's gonna have some terrible (yet very workable) growing pains, so I'm not too worried. God help you if you try to implement DECOHack's flavor of DECORATE into your port, which I don't recommend at all, especially when I still have that "0" in front of the version number. Everything's documented, but I really gotta write up its grammar one day...
  10. MTrop

    DSDhacked [unlimited everything]

    Here you are, happy to oblige: https://github.com/MTrop/DoomTools Main website here: https://mtrop.github.io/DoomTools/ It's included in a bunch of other tools (and the parser needs a tiny code revamp), but it's completely functional. Original thread, as well: EDIT: I wish I had a better (public) project to show off, but here's an example one: https://github.com/MTrop/doommake-example The project format is not up-to-date, but it still runs (most of the project code is in scripting logic).
  11. MTrop

    DSDhacked [unlimited everything]

    I don't know why this discussion even exists when I've taken up the mantle in making DECOHack (a DECORATE-flavor-to-DeHackEd converter). It was the easiest task for me to take because: A) I wanted to make it since forever. B) The burden of converting a better definition language to a common one is taken off the table for port authors who would puff their chests out and potentially complain about needing to backport a superior, human readable-and-writable definition language. So I'm gonna keep plugging away at it, if you don't mind, while this slapfight continues. You're welcome.
  12. MTrop

    MBF21 DeHackEd thing explode on spawn

    Apologies for the month-old bump, but more people need to know about this Doom Engine weirdness. I tried to make a patch one time that essentially removed nearly all of the place-able things in Doom, and ran into the engine quirk immediately. Here's what I think is happening: The Spawn State is set every time an object is created, which will not call its action pointer. HOWEVER, something special occurs for objects spawned on map start - Doom has to initialize the spawn state and simulate one frame before the wipe to the map beginning. It will subtract the current duration by 1 on all of those spawned objects, which creates a problem for objects with an initial duration of 0 - it will make the duration negative, which means Doom will not update that actor unless it somehow changes state again from outside itself (being shot, etc.). So, that's why the duration of 1 is needed on the spawning state, most commonly on place-able Things (but not usually on Things spawned during gameplay).
  13. If you are using a project created in a recent version of DoomMake, there should be a line in your project's "doommake.script" file that calls ZIPFILES() to package up your distributable ZIP. It takes a list of files, so you'll have to add the patch file to the list. Hopefully the scripting language is understandable enough! A quick guide is here: https://mtrop.github.io/DoomTools/rookscript-guide.html A reference to all of the DoomMake built-in functions are here: https://mtrop.github.io/DoomTools/doommake-functions.html (look in the DoomMake-specific functions section for ZIPFILES). Automatically? I'm not sure. If it works in Chocolate but not in other ports, it may be a port-specific problem (with port-specific solutions) if changing the offsets in the graphic itself does not yield correct results. You can change offsets in SLADE in either Doom-format graphics or PNGs and DoomMake will either convert or import the graphics, preserving offsets as-is, or you can provide a DImgConv metadata file with the convertible graphics to override those offsets (see DImgConv's `--help` for details).
  14. Yup. There's an optional parameter in the MERGEFILE WadMerge command that specifies an entry name for the merged file: MERGEFILE [symbol] [path] [opt:entryname] Reads file from [path] into [symbol]. [symbol]: The symbol to add to. [path]: The file to add. [entryname]: (Optional) If specified, this is the entry name to use to import as. ................................ Returns: OK if merge successful, BAD_SYMBOL if the destination symbol is invalid, BAD_FILE if the provided file does not exist or is a directory. So that MERGEFILE line could be written as: mergefile out $1/assets/patch/myreallycoolpatch.deh dehacked ...and it will be imported as "DEHACKED" (all entry names are automatically converted to upper-case).
  15. Huh. Weirdly enough, that's a use case that I haven't considered! Usually the patch in DoomMake projects would come in the form of a DECOHack-compiled patch. Not to worry, though - you might need to do some small tweaking to your project. Since it sounds like you put together an asset-driven project at the very least, you should have a file in the project's "scripts" directory called "merge-assets.txt". Open that file and add a line to it after the "mergedir out $1/assets/_global nomarkers" line: mergefile out $1/assets/patch/dehacked.deh Then, create a directory called "patch" under the project's "src/assets" directory. Add your DeHackEd stuff (including the patch file) to the "patch" directory. After you do this, only the dehacked.deh file will be merged in, and you can keep WhackEd's metadata files in there too so that you can keep editing with WhackEd!