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

MTrop

Members
  • Content count

    603
  • Joined

  • Last visited

Everything posted by MTrop

  1. That was the goal, my friend! I think I gotta start making a tutorial page for DoomMake so that project creation can really be streamlined. After DSDHacked support in DECOHack, though. Almost done!
  2. STILL IMPORTANT: You'll need Java 8 or higher installed to run these! Main Website Github Repository Latest Releases (Windows CMD and BASH) The First Thread Installation (Same as Last Time) Unzip/untar the release to its own directory, and then add that directory to the list of directories in your PATH environment variable. You again? What's this about? Hey, everybody, I'm MTrop. You may remember me from enjoyable WADs such as this 22-year-old pile of junk that people somehow still like and this short romp that's pretty okay I guess. But did you know I'm a programmer? ...you did? Well that's good, because I've got more programs for ya! As with the previous thread, this is a set of utilities written in Java and built on this fantastic library that I also wrote (DW thread here). Since I went over a bunch of the utilities in the last thread, I'm only gonna go over the new ones here, and let me tell you: you're probably gonna want to use them. DMXConv SLADE3 does an okay job at converting sounds from WAV to Doom's DMX format, but you are like me and chuck your sounds in a project tree and want to convert all of them at once for importing later, this'll do it! Works best if you have FFmpeg on your PATH or somewhere on your computer - then you can convert practically EVERY SOUND FORMAT THAT EVER EXISTED to DMX! If not, it'll still use the existing Java SPI framework for conversion, if you want. dmxconv sounds/*.wav -o ./converted/sounds Typing `--help` will give you more options and explanations. Keep in mind that this is a one-way utility - it does not convert from DMX back to other formats. DECOHack I think you're really gonna love this one. Are you ready? Because I don't think ya are! Have you ever wanted to create some kind of insane mod for Vanilla Doom (and other classic Dooms) but wished that there was a better programmatic way to write weapon, ammo, sound, string, par time, and thing definitions with a DECORATE-like language? Introducing DECOHack, the thing that does exactly that! DECOHack takes a file (or series of files) written in a DECORATE-ish language and turns it into a DEH/BEX file that can be loaded into your favorite source port, or patched into your favorite executable via DeHackEd! Supports all patch schemes up to Extended (aka DEHEXTRA). decohack code.dh --output dehacked.deh Hate backpacks? Turn them into BFGs! #include "classpath:decohack/doom19.dh" #include "classpath:decohack/constants/friendly_things.dh" // copy BFG pickup into backpack thing MTF_BACKPACK : thing MTF_BFG { //keep ednum, though ednum 8 } Make an Imp with a worse attack! #include "classpath:decohack/doom19.dh" #include "classpath:decohack/constants/friendly_things.dh" thing MTF_IMP free states thing MTF_IMP "Worse Imp" { health 200 speed 12 clear states States { Spawn: TROO AB 10 A_Look Loop See: TROO AABBCCDD 3 A_Chase Loop Melee: Missile: TROO EF 8 A_FaceTarget TROO G 6 A_BruisAttack Goto See Pain: TROO H 2 TROO H 2 A_Pain Goto See Death: TROO I 8 TROO J 8 A_Scream TROO K 6 TROO L 6 A_Fall TROO M -1 Stop XDeath: TROO N 5 TROO O 5 A_XScream TROO P 5 TROO Q 5 A_Fall TROO RST 5 TROO U -1 Stop Raise: TROO ML 8 TROO KJI 6 Goto See } } The sky's the limit (within reason, as it is still limited to Doom engine quirks and limitations)! If you're worried about how many states you have left (in total or action-pointer allocated), you can run DECOHack with the `--budget` switch. Full help available via the `--help-full` switch. You can do a lot! It's all documented, even the worst of Doom's hardcodings! DoomMake You've stuck with me long enough - I think you're finally ready for the big guns. Have you ever wanted to start a new project, but didn't want to organize everything, and still have it produce WADs that you can maintain in a code versioning system like Git, compile together in an automated fashion, or keep providing builds via an ultra-nerdy thing like Continuous Integration? Well, in case that's you, you're in luck! DoomMake is here to help you build that giant project with all sorts of bells and whistles with a single command, and produce something compiled together and playable (and with some setups, a reduced texture set)! It leverages WadScript and turns it into a do-anything-you-want build tool that isn't tied to one operating system or environment. You can even call all the rest of the tools in the DoomTools toolset! You can start a new project with maps and new textures sourced from WADs: doommake newproj --new-project maps-texturewads Or even a giant vanilla mod from scratch with all sorts of things, and make it Git-repository-ready: doommake newproj --new-project maps-assets-textures decohack run git And then when you want to build your project in it's current state, you just switch to its project directory, and... doommake It's that easy! Want to feel its power? Try cloning and building this project for starters: https://github.com/MTrop/doommake-example As always, chuck some issues my way if stuff doesn't work, or if you've got some feature requests. Follow the GitHub repository to be notified of updates and releases. Happy Dooming, y'all! Make some cool stuff!
  3. MTrop

    Microsoft Windows 11 confirmed exclusive to 64-bit CPUs.

    When Microsoft inevitably makes Windows 12 to address all of the complaints about Windows 11.
  4. MTrop

    What does Vulkan do differently than OpenGL?

    Shortest answer: As an end-user, if your chipset vendor supports it and can parallelize GPU operations (practically all of them today), Vulkan offers better performance. Usually. If the code is written well. Short answer: Vulkan is an API that does things in a way that is more representative of how graphics cards today do graphic processing, with control over pipelining and threading and queueing and memory access strategies. OpenGL is an API that is state-driven, which worked well at its inception, but graphics cards aren't that way anymore, and are bottlenecked by OpenGL's single-threaded scheme and assembly line-like processing. Vulkan is "outside-in" for creating contexts - lots of boilerplate. OpenGL is "inside-out": small, it but gets hairy when you need to make something sophisticated. Long answer: There was a time when OpenGL was king. When it was written for humans. Somewhere along the line as more people made graphics cards that did more generic calculations than just vomiting color information into a chunk of memory, it became a miasma of vague numerals and needing to write lengthy programs for painting a single triangle. Where once was a dedicated place for vertices, colors, texture coordinates, and matrices, a tangled mess of arbitrary numbers matched to other arbitrary numbers crept its way in while an ailing compatibility layer held on for dear life as the specter of GPU-driven tech and transform callbacks threatened to overcomplicate everything so that we could simulate flapping cloth and push extra triangles to paint your favorite avatar's buttocks at varying distances. You could have taught it in schools. Now you need a a technical manual. Then along came Vulkan - if the first horns of the apocalypse were sounded at the genericization of OpenGL, Vulkan is the Third Woe. Any and all sense around drawing simple geometry is dashed against the rocks, several lines of code needing to be written to pass a single vertex and texture. Only the turbo-est of the turbo-nerds are able to parse every layer, every component, every last method of configuration before pen is put to paper - defining not only the mechanism by which the pen extends and retracts its tip, but every piece of pulp used to make the paper it writes to. It is only afterward, days into your training, that you realize that you're not even holding a pen, nor writing it to paper! Days turn to months as the graphics programmer slips away into the void, alienating their friends and family taming the many-headed, many-mawed beast that is Vulkan. I am one with the machine. The machine is me.
  5. MTrop

    DSDhacked [unlimited everything]

    Of course I love it. I made it. ;) Also, any port that discards DeHackEd in favor of a better language is pretty unnecessary unless the port author just wants to shed the shackles of needing to keep an older spec up-to-date. For mod authors, this means nothing, since mixing DeHackEd and DECORATE outside of addressing compatibility issues leads to disaster. We've got (G)ZDoom if you want a port with a better modding language, and solutions are out there for covering the gaps between DeHackEd and EDF and DECORATE and ZScript in terms of writing something legible and maintainable. We can't stop hobby projects, but an entirely new port would just introduce potential user fragmentation and divided effort when existing efforts should be concentrated on learning what each port's individual strengths are and addressing their weaknesses without losing their identities, at this point. The current zeitgeist is backporting engine features that can feasibly be added to an existing chain of Boom-compatible ports (and their spiritual descendants), and I'm not above killing some high-horses to make the glue between them!
  6. Just noticed this post. By all means, let me know what you put together! I may be able to incorporate some of it into DoomMake's default templates if they're universally useful. (I've really been meaning to put the command to clean the dist folder in the clean target - dunno why I haven't done that sooner)
  7. I guess since this thread's a tad more active, I can post an update. Latest version of DoomTools is up. Fixes the following: DecoHack -------- Changed for 0.18.1 * `Fixed` Editor keys were not being saved if a Thing body didn't have parse-able content right after body start. * `Changed` Copying a definition from the exact same one will not perform a copy, as there is nothing to do. If you have DoomTools (version 2021-09-21 and higher) installed and on your PATH, typing doomtools --update will grab it.
  8. @boris That's weird - it works when I try it in my mod, but not when it's a single Thing. I'll take a closer look. EDIT: Oh, Lordy - I figured it out. The comment key context is getting cleared at the wrong time due to how I'm starting the thing body parse. If you put those lines after one of those property lines, it'll work. Should be an easy fix.
  9. 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
  10. 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.
  11. 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.
  12. Should I go ahead and make that a reality? That's a really quick change on my part.
  13. 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.
  14. 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/
  15. 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.
  16. 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.
  17. 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...
  18. 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).
  19. 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.
  20. 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).
  21. 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).
  22. 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).
  23. 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!
  24. Watch out for the BUMP! Apologies - this is probably the last time I'll do this, but the latest release of DoomTools removes the final limitation in DECOHack where you couldn't pre-declare labels before they were used in actor "States" blocks. Now you can! State indices via labels are now assessed/reassigned after the "States" block is fully read on Things and Weapons, which means any labels used in that block will use the latest position defined within that block (the state name plus ":"). Anything not declared nor re-declared during that block will use the label's current state index assignment (in case of copied Things/Weapons and what-have-you). If a label is never declared nor defined on that actor after the States block is parsed, DECOHack will complain at you. NOTE: Be on the lookout for bugs. I tested this pretty well and didn't encounter any problems, but just in case you see the value "1234567890" anywhere in your compiled patch, that means the label back-filler didn't work for some reason. Whoops! Latest Release as of right now: https://github.com/MTrop/DoomTools/releases/tag/2021.09.08-RELEASE. Check the main website periodically for new releases (and some helpful docs, maybe some guides in the future): https://mtrop.github.io/DoomTools/
  25. MTrop

    DSDhacked [unlimited everything]

    My contention (via my reasoning with DECOHack) was that supporting DSDHACKED's unlimited resources without the MBF21 spec is essentially worthless. Unlimited resources was the next step to accommodate the crazy stuff that people could make in MBF21. While they're mutually exclusive, there is little to no reason or utility in raising the ceiling on a truncated, limited feature set, and its mutual exclusivity only leads to confusion, as is evident in the previous posts. Modders are better served when they are encouraged to NOT make several variations of a handful of gameplay archetypes. Nobody needs 14 different kinds of Imp or Zombieman. Furthermore, to keep them implemented separately would be to repeat the mistakes that already lead to confusion around feature support among source ports.
×