Coraline

Members
  • Content count

    1111
  • Joined

  • Last visited

About Coraline

  • Rank
    Senior Member

Recent Profile Visitors

1647 profile views
  1. Hey Marscaleb - sorry for the delay here! Our wiki page on MD2 Models has all the information you need as far as what commands do what in the game. If your coordinates aren't aligning, use MODEL_BIAS: Add this to every z coordinate: MODEL_BIAS=24.0; Useful if you don't want to position from Quake 2's original 24 units in an external editor. Keep in mind that using more than one material group on a mesh/model is only supported with MD5 models. MD2 and MD3 model formats can only use one skin + a bright map, a normal (bump) map, or specular map. MD5 can also use those too, but as far as using more than one skin on a model, it is not possible with MD2. I have been majorly rewriting the MD3 code (since changes to the model physics for MD5 broke it somehow) and it'll be possible to also attach "links" to the models like you could in Quake 3/etc, so that will eventually be possible for those who don't like using the MD5 format. To load MD5 models, remember that it needs to be written as such: testmd5.md5mesh, and testmd5.md5anim. You can also abbreviate those if you aren't using the PAK/PK3/PK7 format to simply TESTMD5 and TESTMD5A. Then, the engine will automap all of the required skins for the model that it uses (as long as they are defined in IMAGES.DDF first) -- I've used a model that had up to 25 materials before, so you can imagine how robust you can make them with EDGE. =)
  2. Sorry about that -- it broke right around the time we did our move to SDL2. I will try to make this a priority so you can play split-screen with the port as soon as I can. Input separation is on-going in the source at a deeper level, but I should be able to cook something up rather quickly so that second player is forced to use joystick, for the time being.
  3. Oh yeah you're right @Gez, i knew that..!! ... I think my post got a little jumbled up while I was writing it. I understand the concepts between the two, but my post came out garbled and instead meshed all together. It was totally unintentional. Sorry about that.. even with my medication, ADHD still scrambles my thoughts up, even if it's right in front of me. I hate having this affliction, because I can be working/researching/etc on chunks of code or whatever and the very next second I can completely lose my train of thought or get excited about something random and never recover from it. :/ Anyways, I didn't know Strife: VE used glVIS. I gotta check it out now. I've had it in my Steam library since it was released and never got around to checking it out. Looked pretty from what I remember, though.
  4. EDGE itself doesn't utilize REJECT in any way, though, so for my situation it's fine that zdBSP doesn't build it. Is REJECT particularly useful for OpenGL-based ports, given that most of us generate our own data/visibility on-the-fly? While we are on this subject, I always wondered if adding support for glVIS sets would speed up unnecessary BSP collection (in EDGE, that is), even though pre-calculating would take awhile. Did that ever catch on or is it a relic from Vavoom? I'm not quite ready to tackle the problems EDGE has with polygon visibility with larger maps, and if glVIS would even grant a slight framerate boost then IMO it'd be worth it. Though, the downside is that I'd have to write it in, meaning that glBSP would be extended for the port. I didn't know people still used glBSP these days -- that's good to know. ^_^ Not saying it's bad at what it does -- it's more of a situational bias for me than a reflection of the program. @Gez: didn't know the REJECT lump was so volatile, or that it could get so large. I only thought that might have been a GL-only thing. Can the Vanilla engine capably load so much REJECT data or is that a hypothetical thing for other software-based ports?
  5. @kb1 I'm not sure of Risen3D's specifications, but your suggestion sounds great overall. I'll just keep both of them. Since I know IWADS render just as fast under glBSP than they do zdBSP (and if they don't, then something is seriously wrong anyways), glBSP can be the default for those. I can have zdBSP take over node generation under most circumstances since it does output GL nodes. The trade-off is that custom WADS won't generate a GWA file, but with today's computing speeds, I don't see it as too much of a problem. For those of you that don't know, GWA files act as a "cache" wad that has the glnodes generated, so glBSP doesn't have to run everytime EDGE loads a WAD that needs GL information. That system runs wonderfully under, say, the Sega Dreamcast which has a very limited amount of RAM, but as most people who run the source port nowadays have a pretty decent system, I can just set zdBSP to rebuild everytime. Plus, zdbsp seems better overall for things that EDGE supports now, such as PolyObjects, UDMF, rendering 'tricks', etc. ;-) I see zdBSP generates a temp file to write that information to as well...I wonder if I can just hijack that and also store it as a GWA file (maybe GW2 format) in case people on older systems like the fast loading times (since node info doesn't need to be rebuilt with GWA). . . hmmmm :-3
  6. Yes (for EDGE), you would just use SECOND_ATTACK in the DDF entry; defined as the secondary attack in WEAPONS, and the attack logic itself via ATTACKS. You can also customize the secondary attack's reload state, if so desired.
  7. If you're running a fairly powerful machine, EDGE can achieve a semi-constant framerate:
  8. @Graf Zahl is the spec completed, or rather suitable for parsing? I would like to take a stab at writing a parser for EDGE. Does UMAPINFO rely on MAPINFO at all? Maybe I should start with MAPINFO and work my way up from there. .
  9. I wish they would, or someone would, release the 32X source code. It would be very cool to be able to work on that version and fix it up. Also, because I don't own a 3DO or a Jag. AFAIK some "Mars" code exists in Jag but I think it's missing system-specific stuff. .if I'm wrong please correct me :) Oh well, I can only dream xD
  10. The reason for the question poll is simple - for map authors who wish their maps to be GL compliant (even with level editors), would you choose zdBSP or glBSP to generate GL-compliant nodes? And, for OpenGL engine authors only, would you prefer glnodes to be generated with glBSP, or zdBSP? The reason I ask specifically is I am thinking about swapping glBSP (as EDGE's internal nodebuilder) for ZDBSP, since it can generate both GLnodes and UDMF/PolyObject support out-of-box. EDGE already has a very simplified zdBSP nodebuilder integrated for UDMF maps to build at run-time, but if those maps are not UDMF, EDGE will default to glBSP. So it's not a catch-all library (yet). I have thought about extending glBSP personally, but it would be a lot of work. zdbsp already generates nodes that EDGE seems to take to better than glBSP. For instance, running Frozen Time through EDGE's default glBSP (not glBSPX) results in a low framerate and a bunch of rendering errors (black holes). Generating the same glNodes through zdBSP (which glBSP ignores since they exist already) results in a Frozen Time which is rendered correctly (no voids, bridge is rendered correctly), and it sees a slight framerate boost (note that the low framerate in that map/et al is due to EDGE's internal BSP walker and not a nodebuilder, though generating good glNodes certainly helps). I know it seems like a no-brainer (just replace already!!), but I would like to hear what everyone else recommends. I think glBSP was a fantastic tool for its time, and I'm totally not trying to downplay its impact or the authors of that program. Also of note, the rendering problems definitely get fixed up if the WAD is ran through glBSPX, which can fine tune node granularity generation, but it takes twice (or more) as long to generate in the amount of time zdbsp takes as its default. And as we all know, glBSP does not support UDMF. I can write in that support though, since it _does_ support Zdoom/Hexen/PolyObjects, but I'm just wondering if it will be worth the effort. Seems I should first find out if people prefer glBSP to begin with. ^_^
  11. @Jon sure thing! Here's a quick tutorial on that: 1) Make a platform in your map of a height of around 112. Give one of the lines an appropriate texture for a ladder. 2) Place a two-sided linedef on the map, just in front of the line with the ladder texture. Don't give it any textures so it stays invisible to the player. Make sure the line is two-sided and that it's not set to impassable or block player. 3) Give this line a type of 472, which corresponds to our pre-defined custom Ladder of 120 units high in Lines.ddf. This is the code for the line (validated here): [472] // EDGE Ladder, 120 units high TYPE=WALK; ACTIVATORS=PLAYER; LADDER.HEIGHT=120; Now, just press "JUMP" to start moving up the ladder. Hope that works out - if you need any other assistance feel free to let me know. @kb1: The 3DGEWiki has the current linetype list available here. These linetypes are the default that ship out with EDGE. Also of interest is that linetypes 600-799 are not hardcoded in that list. So there could be potential there. The HUB linetypes bring up the rear to occupy 800-825. Regarding the sudden skip from 600 into HUB linetypes... I don't remember why they ended up not occupying 600-725...I guess I could change that, and it would free up starting from 800^.. If we could just bump the new linetypes much farther down the chain (I think I saw a thread Graf had mentioned about it) it'd be preferable. Maybe from ~900 on? However, seeing as EDGE 2.1.0 (the next major version) has not even reached Release Candidate yet (sigh), there is still time for me to potentially change ALL of the conflicting linetype numbers and move them forward as to retain compatibility with other ports/standards. It would definitely give 3DGE modders enough of a heads up that default linetypes would be changing well before that version releases. I'm absolutely open to whatever the main authors of this think is best. I know nothing is set in stone yet, but I'm just saying that you guys have my support. =) On the issue of the namespace - I tend to agree with @Graf Zahl in just calling it "UDMF - Doom" and using UMAPINFO. Calling it "prboom" or something seems a bit strange, because in my eyes, it would just create more confusion (is PrBoom standard now? Assumes port is 100% Boom-compatible? But I'm not using PrBoom, I'm using Doom Legacy? and so on). But, @Quasar makes a very valid point in that other ports that don't support UDMF would give users the wrong idea. . . However, if the overall goal is to define to a new standard that isn't necessarily an explicit part of UDMF, why not just call it "Doom - Modern"? I think that is the cleanest way to go here -- that way it's not nailed down to a port, there's no confusion, and "modern" is pretty easy to comprehend (but feel free to trade modern for any other synonym that might fit the bill). If it is planning on having a wide-adoption, calling it "Doom - Modern" might actually be distinguishable enough. I would be okay with calling it "Boom, format2", "prboom+" or whatever, but wouldn't ports require 100% Boom compatibility in order to really use that distinction? At least, that namespace suggestion seems the least confusing for comprehension's sake. ^_^ But alas, I'm very rarely not confused. ;-) #ADHDLife
  12. Yeah, it's just "edge". No pronunciation difference. ^_^ And, I am always open to hearing constructive criticism regarding the port -- however, maybe this thread isn't the best place for it. And don't get me wrong, there's a ton of reasons it's not as popular as it once was, or maybe as popular as it can be. I also know there's major issues with it at the moment, but we are trying to work through it. We just take things one day at a time. ^_^ @Jon: Also, if the ladder type clashes I'll go ahead and push it farther back as to not conflict with more current trigger types. Not the first time EDGE's custom linetypes had to have been pushed back, so it's no big deal ^_^
  13. Sayyyyyy, there ain't a way to make 3DGE/RTS take health from the player without inducing the 'pain' sound and slightly-red screen is there?

    I've a feeling there ain't, hence me posting this here: feature request? I really want me an overcharge system similar to Wolfenstein: The New Order here. :3

    1. Ichor

      Ichor

      Maybe use a custom pain state on the DoomPlayer code.

    2. Coraline

      Coraline

      @Jayextee Sounds fairly easy to do, I'll just make a version that neither calls the SFX manager nor the colormap change, and make it more specific in RTS ;) Have you tried using LOSE_BENEFIT (HEALTH) ? 

    3. Jayextee

      Jayextee

      LOSE_BENEFIT HEALTH(1) is what I've been trying, yeah. Makes it look like you're in nukage with the screen going red and the grunting. ^^;

  14. I can imagine ACS will come next for 3DGE. We already have proper support for Hexen/ZDoom format maps - the thing that I'm thinking about is that if its going to be worth expanding much more of [ACS] past whatever Hexen needs, since RTS in 3DGE will always come first. Not sure if it will be worth the effort or what I'll have to do to support both it and RTS. .
  15. Port Authors: how do you guys handle the grab chunk? It works great for PNGs that are not player weapon sprites. Might have to alter some code further down the chain. A printf let's me know that the grab offsets are applied correctly (checking in SLADE and grabpng), but for some reason HUD weapons are SOL. Any suggestions? :-)