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

andrewj

Members
  • Content count

    2056
  • Joined

  • Last visited

About andrewj

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. andrewj

    Eureka 1.21 Released

    Thanks for this. It proved what I suspected the problem may be: NOTEPAD is adding a unicode BOM (byte order mark) to the beginning of the file, because the file uses a few unicode characters. But Eureka's file reading code cannot handle (diffuse?) a BOM, so you get an error. I will able to fix this now. Hoping to get a release of Eureka with all the recent fixes out fairly soon :)
  2. andrewj

    Eureka 1.21 Released

    Do you mean the 3D view does not light up sectors (etc) from the dynamic lights? Or do you mean that the ZDoom config is missing some thing types? If it is the former, then I can say that rendering dynamic lighting in Eureka's purely software renderer is simply not feasible. The names of actions are already remembered, and can be seen in the status bar (at very bottom right side of the window) whenever you invoke the Undo or Redo commands. For example, after doing Undo it may say "Undo: deleted 4 things". Where else should the message be? I guess this autosave file would be separate from the current file? Anyway, idea noted. Ok I think that covers everything from Pegleg's summary. But I will keep looking back in time for anything else....
  3. andrewj

    Eureka 1.21 Released

    The Hexen source code disagrees with you, please see the P_PlayerInSpecialSector() function in the file p_spec.c 9 is the correct sector type of secrets. When I use Hexen here, I see sector type 1 as "Phased Light" and there is no type 8 at all. That issue was fixed a while ago. If you hover the mouse near the linedef, the sector will be highlighted and can be deleted. Also I plan to have a preference setting to enable the sidedef ADD and DEL buttons (they can also be enabled, in version 1.21, by directly editing the config file).
  4. andrewj

    Eureka 1.21 Released

    I have tested that here and I don't think MS-DOS newlines are the problem. I suspect something else is happening. If you put the problematic config file in a ZIP and attach it here, I will try to reproduce the error.
  5. andrewj

    Eureka 1.21 Released

    They are not "deleted", the zero value is still there, it is just being shown as blank (since zero is the default value). Would it be better if all 5 arguments were explictly shown for any non-zero special? I think it would be bit uglier, but if it prevents confusion then it would be worth it. I will look into that (and at the very least, ensure it is not a fatal error). I agree that it is not nice when a detected programming bug causes the program to shut down and for people to lose their work. I'll try to handle them more gracefully.
  6. andrewj

    Eureka 1.21 Released

    I was away from DoomWorld for a long while, not sure I'm really "back" but while I'm here I'll answer as many things as I can -- starting with the most recent things and going back in time. For a free tag number, easiest way is to select the sector or linedef, then use the "Check / Tags" command in the menus. There will be a line at the bottom with an "Apply" button. The other way was mentioned: pressing ; followed by f. The "SolidMask" crash -- it was reported a while ago, and I have reworked that code and I'm sure the problem cannot happen anymore (though I could never reproduce it here). The crash which could occur in the 3D view is also fixed. I traced that one back to the sorting code in GNU C++ STL library, though my comparator function was not strictly transitive so maybe I cannot blame the GNU folks for that. So I wrote my own sorting function that can handle it, and I haven't seen a crash yet, but performance has taken a hit. more later.....
  7. andrewj

    Announcing AJBSP

    No I don't, sorry. There may be good programs around which can convert a DOOM map to an OBJ file. Once upon a time I experimented with it, but never finished it (for example, my program never added texturing information).
  8. Boom and MBF contain code to detect when a seg vertex is "off" a linedef, and to correct the position to be "on" the linedef. For MBF, see the P_RemoveSlimeTrails() function in p_setup.c. Interestingly, neither of them fix the angle. Hence it is quite possible that if a node builder sets the "angle" to be exactly correct for a seg, then the code in Boom and MBF (and other ports that adopted it) will now be producing segs with a bad angle, and causing the same issue you were trying to fix.
  9. andrewj

    Announcing AJBSP

    Sounds reasonable to me. Last night I was thinking that perhaps all that was overkill, especially when there is only a single package right now that really benefits (wadc). But you are the Debian guy, so ultimately it is your decision, and I am still happy to support an "-o" option in AJBSP. @anotak You don't need my permission to bundle AJBSP with another program, but I am Ok with that.
  10. andrewj

    Announcing AJBSP

    @zokum Firstly, and least importantly, I disagree about in-place modification. When you run a DOOM map editor or even a text editor, you are directly modifying the same file. If the file is precious, a wise person makes regular backups of it, and AJBSP provides an option to backup each file before processing it. Neither AJBSP nor Eureka does "continuous BSP calculation". Eureka builds the nodes only when you save the file, and that is optional (can be disabled). I may look at your blockmap compression code, but I don't plan to make AJBSP be a tool with heaps of knobs that users can tweak -- other node builders have that covered. It sounds like ZokumBSP has a strong focus on vanilla DOOM mapping, whereas AJBSP is more for modern source ports. So I think they are more complementary than competiting with each other.
  11. andrewj

    Announcing AJBSP

    Ok, I can see that a common minimal interface would be useful. I am willing to add an "-o" option as a compatibility option for specifying the output filename. The default behavior (without the option) would stay as it is now: modify the input files in-place. I think it is a bad idea to check that the input and output filenames are the same and for that to enable an in-place modification. I can't think of any other Unix tool which works that way, e.g. "cp" will produce an error if you try to copy a file to itself. What I did with glBSP was a user interface mistake. So I suggest that you leave out any mechanism for in-place modification of input files from the common minimal interface. Just have the "-o" option to specify the output filename.
  12. andrewj

    Announcing AJBSP

    @printz No, UDMF would require major changes (and major testing), which I don't want to do. @AlexMax The code is already there for ZNOD, but why would you want it? I thought XNOD format had made ZNOD obsolete.
  13. andrewj

    Announcing AJBSP

    Let's see.... AJBSP modifies a wad in-place, where glbsp created a new file with the nodes added. the --fast option works differently than in glbsp 2.24, and does not look at any existing nodes. if the BLOCKMAP overflows, it is left as an empty lump. glbsp would "truncate" it, producing a valid blockmap but mostly useless since large parts of the map are excluded. AJBSP supports the XNOD format, which glbsp does not. AJBSP only supports V2 and V5 of GL-Nodes, glbsp supports the obsolete V1 and V3 formats. AJBSP command-line options are different. The first thing (directly modifying the input files) is the main thing to watch out for.
  14. andrewj

    Announcing AJBSP

    @Linguica Thanks for the MacOS binary. The blockmap compression is just the basic one which glBSP had for a long time, all it does is detect duplicate blocks and uses the same index for them. @therektafire I clarified the original post, I'm looking for detailed information that I can place in the INSTALL document, and possibly a Makefile or project file to add to the repository. I will look at the Eureka thread sometime. @ETTiNGRiNDER I don't expect much development to the core node building stuff, but any improvements to AJBSP will flow back into Eureka (indeed a few bug fixes and code tidy-ups already have). @jmickle66666666 Main motivation is that I wanted the BSP code from Eureka, which I know works pretty well (as I worked quite hard to make it as reliable as possible, because it can run everytime somebody saves their map) -- I wanted that in the form of a CLI program. Plus it might be good if AJBSP replaced the glBSP package in Debian and other Linuxes.
  15. andrewj

    Announcing AJBSP

    AJBSP is a simple nodes builder, mainly for modern DOOM ports. It can build standard DOOM nodes, GL-Nodes, and XNOD format nodes. The code is based on the BSP code in Eureka DOOM Editor, which was based on the code from glBSP but with significant changes. The command-line interface is completely new, and is not compatible with glBSP or any other node builders. Web site: https://gitlab.com/andwj/ajbsp#readme Binary packages: https://gitlab.com/andwj/ajbsp/tags/v0.95 If somebody wants to help, there are two things that would be great to have: a MacOS X binary [already done, thanks Linguica!] detailed information on how to compile this under Windows, to add to the INSTALL document and possibly a Makefile or project file to add to the repository too. A couple different methods (like VSCode vs MSYS) would be even better. [now have CMake+VS info, thanks Coraline!]
×