• Content count

  • Joined

  • Last visited

Community Reputation

222 Excellent

About scifista42

  • Rank
    Why don't I have a custom title by now!?
  1. Use Thing_Hate on them right after spawning them.
  2. 1. There is no "proper" nodebuilder for all maps - it depends on map size, specific geometry, monster count, target port/compatibility, and whether you prefer good in-game performance, performance during saving the map, or small file size. "Zero reject" is saving fast because the REJECT lump is just being filled with zeros instead of being computed out of map geometry (which ZDBSP can't do on any setting), so line-of-sight checking within the game will be slower (but it is only noticeable in maps that are very large and/or contain very many monsters). The zero filled REJECT is useless, but still a valid lump that every port including vanilla can read (as opposed to the "No reject" setting, which saves file size by making an empty REJECT lump, but this makes the map crash in vanilla and certain classic ports). 2. No.
  3. How about lesser loading time, too? All players want it to be as short as possible, and compilation in general is not guaranteed to only take a negligible amount of time. I disagree with this way of thinking. UDMF allows defining unlimited data structures, but many of the engines/parts-of-engines/programs (I will say just "programs" from now on) that read it do have limits and do expect the structures to follow certain rules in order to process them as they're supposed to. The reasons why the program couldn't parse UDMF itself can be various - high priority focus on time/memory/file size efficiency, being an old / now unmaintained program, issues with implementation, whatever. UDMF has a potential to accustomize to the needs of any such program - not necessarily by forcing the program to parse UDMF, but just by defining the structures, which would be processed by a compiler and the program will only process the result of the compilation. I see it as a good thing to have this possibility and to take advantage of it. Destructivity of the process can be prevented on the side of an editor, via configs enabling only certain features that the program can process in its own format - practically what we already have. Note that, as opposed to the target program, the editor could benefit from working with UDMF despite only working with limited features when editing files for a specific target program, also for various reasons - easily implemented support for multiple target programs with different limits, separated maintenance of the editor and the compiler.
  4. Well, binary format maps tend to be smaller in file size than UDMF maps, so this could be used simply to reduce file size of gonna-be-downloadable wads before uploading them.
  5. As long as the non-supporting editor only erased/rebuilt REJECT without modifying VERTEXES/LINEDEFS/SIDEDEFS/SECTORS, storing the custom REJECT info in a separate MREJECT lump should be safe enough.
  6. Since these bridges all lack "middle railings" and self-referencing linedefs can freely overlap each other, this kind of overlapping bridges could be made without a multitude of sectors, which probably made the feat not only possible, but relatively easy to make.
  7. What I mean is that the map editor would update it during every elementary change of map geometry, not just after every REJECT lump rebuild.
  8. I imagine that if the mapper splitted a MREJECT-affected sector into 2 parts, the (compliant) map editor would automatically update the MREJECT lump to affect both parts of the original sector in the same way the original sector was affected, and similarly for other actions.
  9. I've just visited this page that sorts DW members by the total number of likes their posts got from others, and scrolled through the first pages (24 people displayed per page). I've found out that I recognize completely everybody on the first 3 pages and almost everybody on pages 4-16. The first page where the number of people whom I didn't recognize came close to 50% (12 people out of 24) was only around page 17.
  10. I like the idea, especially the concept that the lump could be processed both by map editors while building a REJECT lump (for vanilla compatible maps), and by advanced ports while loading a (port-specific) map without a REJECT lump.
  11. No. He calls A_SpidRefire after every shot, and it forces him to enter See state when his target is dead. The refire randomization can make him fire a couple more shots, but that's it. Unless you're playing in a source port with such a random number generator that keeps giving the same or very similar numbers repeatedly for a long time. The vanilla RNG doesn't do this.
  12. This happens when you accidentally click "Start new topic" instead of "Reply to this topic" and don't fill the new topic's title (and if you do fill it, your post gets published as a new thread instead of going into the thread you wanted it to go to).
  13. Are you talking about showing screenshots / video footage, or providing downloads to the maps themselves?