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

JPL

Members
  • Content count

    64
  • Joined

  • Last visited

4 Followers

About JPL

  • Rank
    Mini-Member

Recent Profile Visitors

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

  1. I'm guessing the file corruption in some of the files in the disk images is plain old media rot, it's happening with more and more floppies as they enter the third or fourth decade of their lives.
  2. JPL

    A little level design tips thread.

    This thread is great, and thank you Vorpal for the kind words about arcadia. I'm not nearly as experienced a WAD author as many folks here but here's two ideas I care about: - Once you have the basics down, develop a personal style. No shame in borrowing stuff someone else does but if you develop an idea or technique on your own, often you'll understand it more deeply and your use of it will be both distinctive and effective. - In most WADs, it's hard to overestimate the visual importance of your sky art. Decide on which sky to use at the start and think about how its color and texture inform the geo that will be seen in front of it. (Also consider making or borrowing a custom sky; very good bang for buck to make a WAD stand out more!)
  3. JPL

    DECK: Doom Engine Creator's Kit

    Correct, nothing has happened since then. I need to finish other projects before I can justify restarting this one.
  4. I think hot-reload of textures, sprites, and sounds alone would be a pretty large win. These are the assets you do lots of little tweaks to in your art/audio software, and changes to them don't affect game state so you don't have any of the issues you'd have with hot-reloading maps and script. If there's a real perf hit to regularly (~1Hz, no point in anything finer) checking files for changes, put the checks behind a "developer mode" cvar that defaults off. Of course this is probably only applicable to ZDoom family, I always work with loose files in directories and forget other ports don't support that.
  5. Lots of context to this discussion I probably lack, but I think any potential scripting system needs to be evaluated just as much in terms of its user interface as its capabilities and engine integration. ACS and ZScript are very powerful, as a veteran designer-programmer it's a super fun toolbox to play with and almost everything on my wishlist for those could (and probably will) be done pretty easily and incrementally. However, when I try to imagine what would make the biggest difference re: People Doing New Cool Stuff With Doom, it's on the tools + UI side. Here are things I think form barriers to entry for creative dev-literate / dev-curious users: Engine and editor are wholly separate. Changes to maps/mods must be saved in-editor and then launched in-game. All assets - textures, sprites, sounds etc - require an engine reload to see changes. ACS changes require a recompile with an external tool. If you're doing heavy level scripting with ACS, you must flip back and forth between not just a text editor and a map editor, but between the text-based mindset of scripts and TIDs and the visual/spatial world of sectors, things, and lines. Editors offer basic visualization of connections between objects and map features (ie showing which sectors a line's special affects) but manipulating this data is still done by changing numbers in fields. This is a bit worst-of-both-worlds: none of the code-like benefits of text-based scripting and none of the visual/spatial benefits of in-world scripting. This might be easily solved with good editor viz, eg color-coding sectors by tag, but that may not scale to more complex map work. I realize all of these would be quite a lot of work to remedy, and having worked with the full spectrum of code-based (Lua/ZScript), GUI-based (Bioshock/GameMaker), and purely visual (Unreal4 Blueprint) scripting I'm well aware of the challenges of each - don't take my points above as belief that visual scripting is inherently better - but I do think it's worth asking where the big gaps still are for Doom's dev experience. It's also a question of values: where do people want Doom to be in 5-10 years? Many are probably happy with the current size, composition, and output of the community. I think growth could bring many positive effects. I think there are tons of people out there who'd love designing Doom levels (or standalone games using Doom-like tech) and can grok sectors, lines, and things but find the vanilla scripting system a bit too arcane and ACS too much like "real programming". If anyone is interested in a system whose benefits require editor UI work, also note that I believe any form of non-code-based scripting should have an underlying representation that IS code-based, so it can be stored sensibly, diff'd and merged, processed with proven methods like parsers and lexers, etc. So all the above discussion of a standard language / concept vocabulary seems useful.
  6. Okay, new build is up with deflate compression (and a new ENDOOM with better credits): https://bitbucket.org/JPLeBreton/wadsmoosh/downloads/ Also for those interested in doing a 162-level run through every possible map in the complete WadSmoosh IWAD, see the "Doom Complete Playthrough" mod I just posted on my page: http://vectorpoem.com/doom
  7. Thanks for the discussion folks, I'll try out Deflate and commit once I've tested on Win/Mac/Lin.
  8. JPL

    Keymaster, and other small mods

    It's definitely possible, if semi-rare - the Arrow must be placed beyond a barrier that only opens when all of one type of monster dies, and the keymaster must be one of those monsters - and there's no way I can think of to detect and avoid such situations without writing code that somehow fully understands the progression structure of a map, which would depend on some very very advanced map data parsing... nobody's cracked that yet. If that were possible there's all kinds of cool mods that would be possible! As is I just kinda have to offer that "may not work with 100% of maps" disclaimer. With pseudorandom spawns enabled, this doesn't occur on skill 1/2/3 in Doom2 MAP07, but I'd guess there are other popular maps where it does happen. If anyone finds a specific example let me know so I can mention it in the readme as an example.
  9. That would make it a PK7, I suppose? I avoided using Python LZMA because it's not installed by default on macOS and some Linux distros, and my goal for those users was to make sure the program can be run from the included source script using whatever Python is built in to the OS (usually Python 2.7). There's also a bit more of a launch speed penalty when booting GZDoom and loading levels with a PK7 IWAD, but it's not a huge issue.
  10. Figured it was time for WadSmoosh to have its own thread here. The original release has been on idgames for almost a year but I've since done many small fixes and improvements that add up to a lot, so I'm looking to verify that the current dev build is rock solid then upload an update to idgames. Download dev build Main project page + README Screenshot: What does WadSmoosh do? It merges your official (released by id) PC retail IWADs into a single PK3 IWAD for ZDoom called "doom_complete.pk3" that contains (if you own all the official releases) Ultimate Doom, Doom 2 and its two addons, and Final Doom. GZDoom 2.4 and later recognize the WadSmoosh IWAD automatically. What doesn't WadSmoosh do? Merge any non-official, console and/or freely available content. Please don't ask me to add support for smooshing Lost Episodes, PlayStation or Doom64 TC, etc. See this post in another thread for my thoughts on the need for an easy-to-use arbitrary WAD merging tool - tl;dr WadSmoosh was built to do a single thing well and I'm not going to overhaul it into SLADE-lite. I'm also not interested in adding support for other source ports - a lot of what makes WadSmoosh possible is ZDoom-specific - unless I deem the changes required trivial. WadSmoosh's Python source code is included with every build so you can modify it as you wish. Feel free to fork it on Bitbucket. Bug reports and pull requests for fixes are welcome! The testing I'd like to do before calling the current dev build good enough for a 2.0 update on idgames is mainly just making sure it provides the same behavior as if you were running with Doom.wad / Doom2.wad - I want users to be able to use this as their daily driver IWAD and not worry about compat. There are a couple tough exceptions I can't fix cleanly though: Final Doom contains texture definitions that conflict with Doom2's, so I renamed those and replace them at runtime with ACS. This means that the few mods that require TNT.wad or Plutonia.wad may not look exactly as they do with those original IWADs - Plutonia 2 for example doesn't show the correct sky, but nothing major breaks. Doom 2 PWADs that redefine SKY1/2/3 in a certain way (via the TEXTURE1 lump) won't show the right sky. As of this week WadSmoosh has an options screen section where you can enable something called "legacy sky support" which should fix this up. For the vast majority of WADs you can leave this off. Wish this could have been auto-detected in ACS or ZScript somehow but them's the breaks.
  11. JPL

    Keymaster, and other small mods

    I understand this is something people might want to do. I haven't implemented it in WadSmoosh because it increases the program's scope and complexity to the point where it would need a UI of some sort, which makes it a whole different beast to support and maintain. It kinda seems like there might be a WAD tool niche somewhere between WadSmoosh (no GUI, does one thing) and SLADE3 (industrial strength GUI, does hundreds of things), a sort of "mix tape" tool where you can shuffle maps and assets between WADs, build new episodes, etc. I imagine the GUI could be quite simple but the stuff it'd be doing under the hood would be non-trivial, especially once you start having to merge different possibly-conflicting texture definitions. Not something one could bang out in a weekend. So I feel it's sanest to say WadSmoosh's mission begins and ends with manipulating the official retail data. The source is included so you can always customize if you really want to. But yeah until someone creates that tool I describe above, this will require intricate knowledge of how the WADs you want to merge are put together.
  12. Hi folks. I've mostly been active on the ZDoom forums but figured Doomworlders might be interested in this. I set up a page on my site for all the Doom stuff I've made: http://vectorpoem.com/doom Probably the most interesting mod I've posted on there recently is Keymaster, a ZScript-powered mod that adds a wrinkle to any existing level: you have to hunt down a specific random monster before you can exit the level, and you have to find a specific random item before you can kill that monster. Here's a stream recording of me playing through eps 1-3 with it. Feedback on that or any of the other stuff I've posted there is welcome.
  13. JPL

    Does anybody make ENDOOM screens anymore?

    FYI: I just posted a thread here about my general ASCII editor, Playscii, which can now import and export ENDOOM lumps. Very different interface from PabloDraw but you may like it.
  14. JPL

    Base of Sacrificium

    Great map! Synthesizes Episode 3 elements with a few subtle Ep2 nods thrown in too. Good challenge for pistol start.
  15. That's a mapping compilation theme, there: only a single linedef action per map, an exit. You could do whatever you wanted with level geo and things. A barrel or a deaf monster blocking a doorway and facing away from the player would be a "door". Keys wouldn't be meaningful.
×