• Content count

  • Joined

  • Last visited

Everything posted by Jon

  1. In both console and pc games now, even if there's a game on the disc you end up downloading a new one in patches soon afterwards
  2. Really interesting thread, thanks for sharing. I'm getting a lot out of this (DWF) thread at the moment. read a bunch of that academic book last night, was surprised but pleased to see the BSP algorithm being employed as one way to do it; I then went on a diversion and read a UG dissertation on randomly generating Dark Forces maps. Fascinating. Also a bunch of architecture academic papers on shape grammars.
  3. You don't need the monster closet sectors to be physically connected to the game area if you are teleporting them in. Just edit the linedefs defining the sector they are within to match a sector number within the game area and sound propagation will work into those closets even though they are disjoint.
  4. OK, The diff of your archive against the RC1 archive is more reasonable (166 files changed, 8810 insertions(+), 727 deletions(-) ignoring whitespace), does that sound like the kind of size of your mod? The diff of the git ref I was using as an anchor (the one that versions to 7.59) against the 7.59-RC1 ZIP is too huge to be right. Or the zip distributions include a bunch of stuff not included in the git repo. It's all a bit tricky to figure out. I might create a synthetic, separate branch of just release ZIPs in sequence, and could branch off that for importing your mod.
  5. Thanks! I see a 7.59 RC1 here I'm going to wager that's what you built off and 7.59 was never released (or got renamed 7.666?)
  6. Thanks for doing this. Did you definitely base your 7.59 edits on top of 7.59? I can't find a 7.59 release or source ZIP, and there are no tags in the git repo. But I tried comparing your sources to commit a4173f60ebdcb8d6ba74ea7d6af1626ab7892317 ("Version bump to 7.59") and the number of changes is enormous. I know you said "substantial" but it looks more like this is not the base (" 1767 files changed, 81815 insertions(+), 394918 deletions(-)") I'd like to import your modifications into a separate branch in the Oblige mirror we've set up, for preservation purposes.
  7. Just a brief point of order: although the two things are very often used together, "procedural" and "random" are different things. A procedurally generated map means, "generated by procedures". All WadC maps are procedurally generated, for example, but most don't actually use randomness.
  8. I managed to piece together a proper mirror of Oblige's git repo. I've put it here: (that existing mirror was close.. but the mirrorer was doing merge commits of the upstream repository into theirs, so it wasn't a "true" mirror)
  9. Thank you for the offer. As of right now seems to be up so I've cloned the git repo (slowly). Once it's done I can compare to see whether it captures all the historic versions or not; but I've also grabbed your 7.59 edits. Edit: possibly spoke too soon. The git URI appears to clone very slowly and fail in the middle (for me). I found a mirror at but that top commit (a merge commit by the mirrrorer) is suspicious so I question the mirror's fidelity. I'll try cloning from another host.
  10. I think you mean Source. I hadn't heard of Shape Grammar before, thanks! I've added it to my to-investigate list, right next to L systems.
  11. The current implementation of wadcat (in the latest release, v0.4.0) writes out to the last argument you supply to it. so, running "wadcat a.wad b.wad c.wad" would concatenate a.wad and b.wad into the output file c.wad. I'm planning to change this in the next release to be more in line with the UNIX cat tool. Both for consistency with that, and to reduce the risk of a user accidentally overwriting one of their existing WADs. Instead, all command-line arguments will be input WADs, and the output will be written to standard output. However, since nobody ever wants to display a PWAD's constituent binary in a command prompt, you will be required to redirect it (or wadcat will report an error instead). E.g. "wadcat a.wad b.wad > c.wad" will work. "wadcat a.wad b.wad" will complain that you haven't redirected the output.
  12. Last night I wrote (in a kind of speedmapping style) a tool "lswad", the first of what will perhaps be a suite of simple tools in the UNIX philosophy for manipulating Doom WADs etc., I'm calling "hwadtools". Inspired somewhat by xwadtools, but a bit more modern (xwadtools seems to be a PITA to build or use on modern systems). I'm mostly doing this as an exercise in writing Haskell programs. "lswad" is a simple tool that lists the contents of WAD files. Example: It's actually inspired by a similar tool I wrote in C perhaps 10 years ago, which was probably inspired by xwadtools at the time. I found it handy enough that I was still using it recently. Source code and binaries for Windows (64-bit), Linux (64-bit) and OS-X are here: Like I said I've approached this a bit like speed mapping, I could gild the lily a lot more but I decided to get this out as soon as it seemed functionally complete. There are no doubt bugs and a few style warts. Bug, questions, comments, suggestions for other tools to add to the suite, etc. are all welcome. Finally I aim to collect/collate a related project "badwads", containing carefully constructed problem WADs to expose bugs in WAD-handling tools (things ranging from invalid magic to directory offset past the end of file, and suchlike). If you know of any or have any such WADs already please let me know!
  13. Thanks for the comments! Your projects sounds really interesting. That's certainly something I can consider. It's related to another idea I was thinking about which was to have a switch for all the tools to output in a structured format for machine consumption. Something like --json for example. That's a great idea. A big piece of work but a valuable tool it would be. I'll put it on my list.
  14. I don't know who explained what, feel free to share a link, but here's the definition of sampling, and Bobby Prince didn't do that. I don't know anything about Duke3D. I see Bobby Prince is co-credited with SFX; however, my post was directly in response to a post about Doom's music.
  15. V0.4.0 released: This released adds a "wadcat" tool. I wasn't sure whether to write this one, I was pondering its utility since it doesn't do any rewriting (so if you cat two MAP01 PWADs together, you get two MAP01s). Then I saw two things: xwadtools had one, and I stumbled across a random PWAD on /idgames that mentioned it had used the xwadtools wadcat to build it. Also I had in the back of my mind it could be useful for something else I was planning, so I wrote it.
  16. Bobby Prince didn't sample anything.
  17. A bit like decompilers that generate source code from compiled programs, the output is unlikely to be very legible to humans.
  18. version 2.2 is finally available link to ZIP (627 KB) and source files release notes: I guess the headline feature is having experimental filled sectors in the drawing pane. Demo There's also a new Preferences scheme and a new UI for settings preferences meaning wadc.cfg is deprecated I've also tried to improve the documentation and there's a much more extensive gallery of the examples Two new large programs for 2.2 * A labyrinth demo A Labyrinth demonstration * My "Bird Cage" heretic level from the Heretic Upstart Mappers Project
  19. Thanks for letting me know: I've fixed that (and need to more permanently fix my generation script)
  20. There's a lot of "technically", "theoretically", "probably" going on in this thread. the music is unambiguously under copyright. You have no more right to redistribute it than any other portion of the IWADs. Enforcement is another matter. Evidently a huge amount of redistribution goes on either under ID's radar, or they don't care, or both.
  21. Very cool! Please consider throwing any interesting experiment maps at me and I'd add them to the examples directory :)
  22. Yes that's possible, at least one-time. Trickier would be to regenerate and replace some stuff via WadC, but that'd depend on how much work you'd spent on it in the other editor.
  23. Ok. so we all know the kind of things you can achieve with a traditional editor. Trying to achieve the same with WadC is difficult, because it's not great or fast to churn out arbitrary lines. what WadC is good for is for generating structures that would be a serious pain in the ass to build by hand: very intricate or repetitive structures, like fractals etc. the challenge is trying to make an *interesting* map from things like that, because repetition and patterns on their own would not be interesting to play. the other area of interest is with randomness. For example I'm looking at writing some rules for various dungeon room shapes and then using randomness to generate a map of such rooms interconnected. Would it be interesting to play? We'll see. When I've finished I could generate a huge number of levels like that, then jump in , warp or clip around, and see if there are any particularly interesting bits; then figure out which algorithm and seed generated the interesting bits, and tweak, cut, combine etc and try again. Kind of like Brian Eno approach to algorithmic music, "gardening" some stuff: controlling initial conditions and leaving other stuff to chance. finally it can do the heavy lifting for some wad effects that are really awkward to do by hand. Write the code once for an intricate poly object, like a door, and reuse it as often as you like. Or, I have a library that makes it really easy to apply boom 242 water to all sectors you draw. Set a global "water level" and the code does the rest (including: doing nothing if your sectors are all above the water level). My unfinished sewer level in the "beta" directory has (from the top of my head) thousands of control sectors.
  24. If you can confirm you've looked at the examples linked above first, and the description on the homepage linked above, I'll then spend the time to try and explain it.
  25. And items/inventory, z axis height checks, jumping, limited vertical mouse look, cd audio, polyobjects...