-TDRR-

It's probably exclusive to version 1.1 of doom.exe.

3 words: y e s.

Ah, that's nice, thank you. Might also help out quite a bit with people thinking that official TAOS is supported by K8Vavoom! I'll also mention K8Vavoom in the title of the thread, so people know it'll work for it too.

Not even I would, and I use SLADE a bit too much :p Ah, it makes sense. -ignore-zscript? Or you mean --ignorezscript? That's gonna be definitely useful. I think I already told you this, but TAoS for Zandro exists and it's probably the better option for K8Vavoom. I didn't remove the ZScript lump I think so it'll require -ignore-zscript, I might try later but no real testing 'cause framerates won't be good at all :p Episode 2 is likely to be 100% beatable, and besides a crappy boss (That I myself modified because the original ZScript one was hard to do in DECORATE) it's the same experience as modern GZDoom.

Maybe a -ignorezscript param would be useful? It's a huge loss to not be able to run QC:DE with properly Quake-ish lighting!

Wait, does it instantly abort execution if it notices a "ZSCRIPT" lump? Doesn't that break D4T, QC:DE and Bloom (the Blood+Doom mod) before they even get a chance to start up? Besides that and the usage of A_Warp in D4T (for cosmetic reasons mostly), I don't see anything that would otherwise prevent them from running mostly correctly in K8V.

They don't, surprisingly. I think this is a relatively recent addition, maybe around ZDoom 2.7? I know because GZDoom 1.8.6 does not crash with Zandronum 3.0's new functions (That were added 3 years after GZD 1.8.6's release!), nor does Zandro crash with modern GZD ACS functions (floor and ceil are notable examples, as well as ScriptCall). Either way, "GetSourceportId" is not really viable in my opinion, since you simply can't go back and update the older versions with that, so it just adds even more unnecessary complication if you need to support those. What could be done is that ACSUtils also adds this function to be able to identify K8Vavoom too, so we can have a way to know which sourceport is in use in a single ACS function but without killing support for the older versions (And Zandronum which doesn't look like it's gonna have an update very soon). Nice, so just this should give the desired result? I'll try that. function bool IsK8Vavoom (void) { if(StrLen(GetCVARString("game_name")) == 0) return FALSE; return TRUE; } EDIT: fixed up the code to not blow up and break horribly if it's actually K8Vavoom EDIT2: fixed another very obvious mistake that broke it, a.k.a directly comparing strings with the == operator but this isn't BCS so of course that doesn't work

The situation with the performance appears to have gotten a bit better, and while it's still stuttery at times it's kinda playable now. Also, the TDBots now actually load up and play, even the latest Zandronum version v26b works, though I'll have to change some of the functions so they can actually attack, but there aren't any crashes anymore! There's a couple bugs that might mess up some other mods though, if K8Vavoom does not support all of Zandronum's features, then I don't see why GetPlayerAccountName should be supported, as it's the way mods differentiate between Zandronum and ZDoom but in this case it just makes them break since none of the other Zandro functions are implemented (Like ConsoleCommand, most importantly). In short, GetPlayerAccountName should always return zero, unless you're gonna implement the rest. On the subject of sourceport identification, could an ACS function that always returns TRUE be implemented? Since it wouldn't be available in ZDoom and Zandronum they will return FALSE there, giving a nice way to check if the current sourceport is K8Vavoom. Or, maybe just check for a K8V-exclusive CVAR that defaults to TRUE (or higher).

In all honesty, all I want is that Zandronum catches up with GZDoom's DECORATE, and nothing else. I personally don't want Zandronum to suddenly start requiring OpenGL 5 billion to run freaking Doom from 1993 less efficiently than Doom Eternal, I believe that if it ain't broke, don't fix it.

ZDoomLE is an older, unsupported fork of ZDoom 2.8.1. I don't recommend using it since the performance differences between LE and 32 are very, very small and anyways 32 has multithreaded software rendering and draw distance options to make up for it. This is because ZDoom Classic is based on an ancient ZDoom version (Much older than even the one the last version of Skulltag was based on), while ZDoomLE is based on ZDoom 2.8.1, so it still supports various mods. As I said, ZDoom32 also has support for most of these and some more, being based on ZDoom 2.9-pre and with some newer additions too. I'm not sure if Golden Souls' code and assets are allowed for reuse (Been a very long time since I last checked but it's not AFAIR), but anyways it's not really that necessary as we got a ton of examples of ZDoom 2.8.1 compatible mods already, and that version still supports the vast majority of things current GZDoom supports for it's mapping (Not so much in scripting, but still). Again, limiting visibility with the map itself is not necessary at all since ZDoom32 includes draw distance options for a reason, and they are extremely helpful in almost every case I've tried so far. If you wanna try them out, they are located in the "display options" menu, scroll down and you will see 2 sliders "wall distance cull" and "sprite distance cull", these sliders affect Software mode only. For OpenGL, go to the same menu, then "OpenGL options" and then into "preferences", and you will see sliders that are named the same as the previous ones. Hm, that's definitely not ZDoomLE, look at the bar at the top, it says "ZDOOM32 2.8.5c"! Not sure why there's a yellow tint however, that did not happen the last time I played through GS on ZDoom32. Does this occur in any other mod? What's your graphics card?

Make sure you have LZDoom 3.85, and go into the "display settings" menu, then into "opengl options", and then into "preferences". There should be "wall distance cull" and "sprite distance cull" options, just set them to your desired value and that's it. In the console you can also use: r_linedistancecull r_spritedistancecull for software mode, while for OpenGL it would be: gl_linedistancecull gl_spritedistancecull 1000 is as low as I recommend going, try moving in increments of 500 since anything lower does not provide any noticeable benefits.

ZDoom32 only supports mods that would run in GZDoom 2.3 (This is not counting the total omission of ZScript support of course), but it makes up for that in spades by including significantly faster renderers (It does not have softpoly, but there's both paletted and truecolor carmack so it's not a big loss), and great options for draw distance for both renderers (These are also in LZDoom, but you will probably get some more mileage out of them here). In short, use it if you are gonna run some mods from the GZDoom 2.3 era and need some extra performance, or just use it for highly detailed pre-GZDoom 2.4 maps or Boom/Limit-removing maps. In fact, it's what I used to play through Eviternity's larger maps, and it worked really well and at high framerates.

I would recommend the legacy version link got replaced by either LZDoom or ZDoom32, both of which are fairly actively updated versions of GZDoom for older computers, with even performance, stability and feature benefits over the legacy versions of GZDoom. (Both allow you to, for instance, set a line draw distance so larger maps can run way, way faster!)

While I do think this is terrible, and really unexpected coming from Torm, I'll still enjoy these maps like the first time I played them. Sure, they have copy-pasted parts of other maps, but all in all I think that this only minimally impacts how incredibly enjoyable they are put together. But yeah, I feel pretty disappointed about this and really, really, REALLY hope that his future maps aren't done this way, it's forgivable if he really feels sorry and stops doing things this way, but it's certainly not if he's trying to make himself look less guilty and still continue with the same plagiarism over and over again. And the whole inspiration thing, well, one thing is inspiration, yeah, but another thing entirely is literally copy-pasting someone else's work, and even worse, not giving any credit.

I'll take any enemies except ones that are bullet-spongy and are liberally used on all of the map, because that just causes a tedious slog, unless you are given an equally strong weapon to deal with them. If you want an example of how NOT to do custom enemies, Super Sonic Doom has some terribly spongy enemies that will easily drain your ammo. Monsters like D4V however, ones that include new behavior and very slightly altered health are my absolute favorite kind of new monster. Also, monsters like those in Rowdy Rudy's Revenge are also very welcome, I'm all for any monsters that change up things a bit.