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

Altazimuth

Members
 View Profile  See their activity

  • Content count

    759

  • Joined

  • Last visited

Posts posted by Altazimuth

  1. Posted

    6 minutes ago, Vader said:

    I think I found the culprit for the secret exit not working for me... I was using the german version of the Doom2 IWad wich censores the secret Wolfenstein maps and thus directly goes to map 16.

    I'm going to sleep now so can't reply further but that looks like it may be the case. It looks like Boom is what introduced that behaviour initially, via a variable called "haswolflevels", so maybe dsda-doom exhibits the same thing. It probably should be fixed in some capacity, though I'll need to get my mitts on the German IWAD to do so.

    0

  5. Posted

    This thread is intended to be a round-table between maintainers of ports with UMAPINFO support.

     

    The ports I know of behaviour of are dsda-doom, Eternity Engine, GZDoom, Odamex, and Woof!. Knee-Deep in KDiZD in particular demonstrates an edge-case in episode-handling behaviour (Eternity it requires modification to do so) that the spec does not explicitly define the intended behaviour of. It only defines a single episode, and different ports handle this differently. There are two approaches that different ports take.

    • GZDoom and dsda-doom show no episode select, but will respect the episode start, so will launch the single episode on the appropriate map.
    • Eternity, Woof!, and Odamex all pop up an episode select with only an individual episode.

    The core thing I want to do here is try and maybe get a Rev 2.2 which either clarifies this behaviour, or if we can't come to an agreement at least explicitly states the behaviour is implementation-defined.

     

    I'm tagging a list of people who I know work on ports with UMAPINFO support. Apologies if I forgot to tag you, though others here with better knowledge than me please feel free to tag others. I want discussion of this to be as inclusive among the people actually having to develop support for this as possible: @fabian, @AlexMax, @Graf Zahl, @rfomin, @printz, @jval.

     

    My personal opinion: I honestly don't mind if it becomes officially implementation-defined. My guess as to the most "sensible" answer is that dsda-doom (via PR+UM) and GZ have the reference implementations, so their behaviour should be considered the correct one and codified as such. By the same token though, I really don't think it's so overwhelmingly important that ports should have to conform to this very specific behaviour.

     

    So what do others think? Should it remain implementation-defined, or should there be a default and if so what should that default be?

    0

  7. Posted · Edited by Altazimuth

    Can't say off-hand. If the frame you referenced is present and the sound plays appropriately normally (so is a normal sound that works and not an ogg or whatever) I don't see why it wouldn't work. Without the ability to look into this example proper I don't know if I can really help further.

     

    Honestly the old cast call system doesn't feel too fit-for-purpose these days in a world where you don't have to define a bunch of EDF frames. Might be a good idea to make it where you can do a "frames" thing and it'll attach some new frames or something, though I don't wanna marry myself to any such ideas. I guess in a pinch you could do loose frame blocks just for this stuff.

    0

  8. Posted

    That thread title is comically alarmist. Encrypted passwords and such have been leaked, yes, but that doesn't mean everybody is instantly pwned, and to use such inflammatory language isn't going to achieve anything except for making people panic when they don't need to.

    It is sensible to change your password now and exercise caution, but this is not the end of the world, nor Doomworld.

    32

  12. Posted

    It's got the folks you'd expect working on it to varying extents. I said this in my tweet but I'll say it a-goddamn-gain: Huge shoutout to @AlexMax for doing a phenomenal job, going truly above and beyond for this game and who, without, the game would be in nowhere near as good a state as it's currently in. As those in the know might expect, @Kaiser was also instrumental for laying down phenomenal groundwork (and is continuing to do great work). Other usual suspects from our team will likely become more involved with various parts as time goes on. I'm doing the usual for me of various loose odds and ends.

    8

  18. Posted

    This marks the addition of the last outstanding major modding feature from MBF21 to Eternity. The only things left are a few comp options and a few fixes. You can now run Vesper and the like in Eternity and they shouldn't be broken!

     

     

    I make no guarantees about things not being broken I tested most codepointers but some of them I just sorta didn't since I considered them so simple so there's a possibility that I screwed those up.

    11

  20. Posted

    There's really not a great deal I miss in terms of wider community trends. I think the community is in a terrific place now, possibly better than it's ever been in a variety of ways. The one wider community thing I really miss from when I first started playing online in 2008 or so, that immediately comes to mind at least, is there being populated casual CTF servers.

    Most of what I miss is more personal: people who have since left the wider Doom community, sub-communities that have dissolved, people no longer filling roles, etc.

    3

  23. Posted ·

    10 hours ago, boris said:

    but maybe @Altazimuth can say something about it

    Yeah, I'd discussed this, but not on forums, with kraflab and co. I had some concerns about this that, to my knowledge, have been remedied somewhat. I've been slowly plinking away at MBF21 support but work and depression has kept me from making progress at any sort of decent clip.

    I'll be trying to tackle DSDhacked after MBF21 but I won't lie, I am still somewhat concerned about feasibility of implementing this into Eternity.

    2
×