Duke4.net Forums: DukeVR - Red Mission 2 - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

DukeVR - Red Mission 2  "How is this level completed?"

User is offline   Lunick 

#1

This mod seems to have flown under the radar for a while and there's no gameplay videos of it on YouTube. It's divided up into three missions with the Red Missions being the hardest although level 2 has me stumped.

The level looks like this
Posted Image

On the side there are pipebombs to use and an escalator that can be turned on or off
Posted Image

Using NOCLIP I can see that an explosion needs to be made on the top level but I can't figure out a way to get the pipe bomb to there, does this level use a vanilla quirk that doesn't work in EDuke32?
Posted Image
3

User is offline   Ninety-Six 

#2

I'll be honest. I went through DukeVR about two or three different times in the past, and I never once figured this out. I would try for like half an hour each attempt, until saying "fuck it" and just cheating through it.

Mikko Sandt never mentioned this in his review, just saying "some might seem impossible but just use your brains." I've always I was missing something obvious, and maybe we still are.


One idea I had over the years was to try and stack the pipes. You are given a whole box instead of just one, and since you can start and stop the conveyor it does seem like maybe you are afforded the chance to build a tower and send it through.

Haven't gone back since I had the idea to try it out yet, though.
0

User is offline   Lunick 

#3

I think you could be onto something with the stacking but, the "3D Realms time" for the level is 45 seconds which makes it seem there is a faster method somehow
0

#4

The solution is indeed to turn off the conveyor and stack the pipebombs up. This no longer works in current eduke32 revisions however.

With a revision from 2007 I was able to finish the map in exactly 45 seconds using this method.

This post has been edited by Doom64hunter: 22 May 2021 - 11:14 PM

3

User is offline   Lunick 

#5

Thanks! I just tried with Rednukem and it works fine as well. I guess Nightfright is gonna have to do something about DukeVR's inclusion in the Addon Compilation.
0

User is offline   NightFright 

  • The Truth is in here

#6

If it used to work before it'd be wiser to make it work again through the port. And if it's based on a bug, we should have compat fixes as they exist e.g. in GZDoom, maybe. There are other issues with pipebomb behavior which currently make Red4 from the Red series unbeatable, which can hardly be intended. In general, a lot of things broke in the last two years, and my list of port-related issues with the addon compilation keeps growing the more testers are digging their way through the mods. Anyway if it had to be done via editing, I wouldn't have the slightest clue how to fix this. It's not a problem with the map, but gameplay mechanics and how EDuke32 handles them.

But good to know I have to put DukeVR on my EAC issues list. The latest EDuke32 build I can recommend so far is r7432 if you want to avoid problems like this one. At the end of the day, I might have to include that build with the compilation (which I would only do reluctantly).

This post has been edited by NightFright: 23 May 2021 - 02:51 PM

2

User is offline   FistMarine 

#7

This is one of the reasons why I don't like playing old maps/mods in EDuke32 these days, because they get broken over time and if a map happened to make use of an old behavior that breaks in a random EDuke32 build, then it will be impossible to complete without using cheats. Many years ago, since I discovered JFDuke3D & EDuke32, I only used them to play Duke3D in general (hadn't discovered DOSBox yet and when I did, I only used it for original episodes/levels and expansions, only last few years I started playing user maps and mods in DOSBox) and whenever I would play an old map/mod, chances are it would be broken, though thankfully that was rare for user maps but still not pleasant to encounter such a game breaking bug. However, half of the mods were often broken, such as Last Reaction & Water Bases where the episode titles would be glitched (though it didn't affect the levels themselves) and the new octabrain variant (that looked identical to regular octabrain) would spam blasts at you whenever it gets hurt, meaning it could insta kill you if you weren't careful.

Another example, there was an old map (I have no idea what it was called and I can't find it again after all these years) that I played many years ago on EDuke32, where I had to submerge into water at one point and I got stuck inside water with no way to resurface, it was a place intended a progression since it contained an access card. Now this may be a map that could have been made for original 1.3D release and it would be broken even in 1.4/1.5 but this is very rare and I don't think there are many 1.3D user maps that play differently in Atomic Edition, though I would still advice to play 1.3D maps & mods in 1.3D (especially since 1.3D mods won't work in 1.4/1.5 and vice-versa). However when you play a map in EDuke32 (especially a newer build since 2018 or so), there is a bigger chance that map may be broken, due to recent clipping changes. Note that I always use the Atomic Edition DUKE3D.GRP when I play in EDuke32 (and other ports), as there is pretty much zero reason to use other versions than the latest.

What's worse is that even new maps and mods made for EDuke32 aren't safe from this. There have been cases where some older EDuke32 maps/mods require a specific snapshot in order for them to work correctly. Some EDuke32 mods come with their own snapshot, which is what I use to play them. However I've even had recently many weird things going on when playing the latest version of DukePlus (though I will post that into its topic soon). Because of that, I generally try to avoid most of the cases by doing this:

90s maps/mods and most early 2000s ones: Play them in either Duke3D v1.3D or v1.5 in DOSBox
Mid-late 2000s maps and mods: JFDuke3D 2005 build
Late 2000s maps and mods to present: EDuke32

When comes to playing EDuke32 maps and mods, I use a specific snapshot released at end of each year since 2015. Here are the snapshots I use (which guarantees 99% compatibility)
2015: r5498
2016: r5974
2017: r6576
2018: r7299
2019: r8494
2020: r9297
2021: ? (Final December build)

The exact same thing applies to Doom and other games from that era. Using the intended source port for playing a custom map or mod is the way to go.

Doomhunter64, I'm curious what EDuke32 2007 build are you referring to? The old version 1.4.0? This makes me wish that EDuke32 was like other software out there, occasionally having new releases instead of having to use SVN builds since 2008-2009 or so, as previously it was using version numbers. I always found a bit strange having to download a specific build from the thousands available, especially since it is impossible to tell which build is the one recommended for playing certain maps/mods or the one that was most stable at some point. There were some users who claimed that a certain 2014 build was the one most stable but I don't remember what was that build and I'm ok with the one from December 2015 that I use for everything EDuke32 related until that point, so I don't think I'm missing much from not using that specific 2014 build. I know there's many others who also prefer a certain EDuke32 build, maybe they know a lot more technical details when comes to EDuke32, I'm only familiar with the recent clipping changes since past 2-3 years ago and since then, I try to be a lot more careful when playing community maps and mods.

As for the DukeVR mod, I never played it but I was considering to go through it sometime and just to prepare, I downloaded the original version of it from Dukeworld and I will give it a try in v1.5 in DOSBox. I actually remember once seeing on YouTube (in 2008 or so) a gameplay video of the DukeVR mod by someone called Teleemahn (I think, not exactly sure about the name). He had a bunch of Duke3D playthroughs (including the official expansions, which was my first exposure to them) and some random mods showcased, this was one of mods showcased. But then he disappeared along with the videos he uploaded.

Also, I almost forgot: I highly suggest Rednukem as an alternative when comes to playing old maps/mods. I haven't used the port much but based on what I have seen and tested so far, it looks solid and should be the way to go when playing older stuff that is broken in EDuke32. I'm just not sure if it can play EDuke32 maps (at least the ones that have limits increased, not talking about TROR or Polymer stuff).

EDIT: Also forgot to take into account NightFright's EDuke32 Addon Compilation. This is a special case and very difficult to explain thoroughly. It requires a specific EDuke32 build that must not break one of the many entries in the compilation. NF says to use r7432 but I wouldn't mind testing a bunch of addons with latest 2020 build (r9297) just to see if they are working fine. Anything broken may require either editing/fixing the map or reporting the bug to EDuke32 devs to be fixed.

This post has been edited by FistMarine: 24 May 2021 - 11:42 PM

1

User is offline   NightFright 

  • The Truth is in here

#8

We seem to know that EDuke32 r7470 works fine with DukeVR still. Just unclear which build was the one that broke it.

This post has been edited by NightFright: 25 May 2021 - 12:08 AM

0

User is online   Danukem 

  • Duke Plus Developer

#9

I haven't played Duke VR, but I did a quick test in vanilla with latest snapshot and pipebombs are able to stack on top of each other. That being the case, why is it not working in that map? Maybe it can be fixed with a few lines of CON script. Presumably you are already loading some CON for that mod anyway, just to get the maps to play as an episode. EDIT: My test was done by just throwing the bombs, but not using a conveyer belt. Perhaps the new conveyer behavior makes the sprite push inside of the one on the ground instead of stacking on it.

This post has been edited by Danukem: 25 May 2021 - 01:56 AM

1

User is offline   Aleks 

#10

View PostDanukem, on 25 May 2021 - 01:54 AM, said:

I haven't played Duke VR, but I did a quick test in vanilla with latest snapshot and pipebombs are able to stack on top of each other. That being the case, why is it not working in that map? Maybe it can be fixed with a few lines of CON script. Presumably you are already loading some CON for that mod anyway, just to get the maps to play as an episode. EDIT: My test was done by just throwing the bombs, but not using a conveyer belt. Perhaps the new conveyer behavior makes the sprite push inside of the one on the ground instead of stacking on it.


I think it might be even more interesting than this and might be linked with the elevator required in Duke VR to raise the pipe bombs. During beta testing of Submachine, we've noticed a weird behaviour with falling sprites on sectors that would move up or down - during execution, these sprites would fall one level down. I was able to mitigate it by adding invisible floor aligned sprites right below eachother to make sure the sprite won't fall down to the sector floor at any possible activation. I've tracked this behaviour back to r9239 version, which is fairly recent - latest snapshot that works fine without it is r9218.
1

User is offline   Ninety-Six 

#11

View PostFistMarine, on 24 May 2021 - 11:30 PM, said:

and the new octabrain variant (that looked identical to regular octabrain) would spam blasts at you whenever it gets hurt, meaning it could insta kill you if you weren't careful.


I didn't realize that was broken.

View PostFistMarine, on 24 May 2021 - 11:30 PM, said:

Using the intended source port for playing a custom map or mod is the way to go.


The problem with that approach is that the DOS executables (and the more pure source ports) lack a lot of modern quality of life improvements, as well as overall stability. The DOS executables were a lot more prone to fatal crashes, and there are significant control problems in both the DOS versions and the more pure source ports. Doom admittedly has it far worse than Duke does in that department, being one slip-n-slide of drunken movement and the severe lack of customizable bindings (you can't even use the numpad). Duke is a lot easier to customize, but the mouselook is wonky, even with adjustable X and Y sensitivity scalers.

And then there's the lack of modern conveniences, such as stat tracking, widescreen support, various bug fixes, smaller enhancements, minor visual improvements, etc., that make the experiences a lot less frustrating overall.

I like to tinker and experiment with the DOS versions, but more out of curiosity and some minor nostalgia, rather than for serious play. I will if I absolutely have to, but I'd rather play in a port that lets me track my progress (as a completionist), has widescreen support and higher resolutions overall (so it doesn't look like the main character needs glasses), and allows for custom minor improvements, such as Darkus' fantastic fixed GAME.con or Fox's lingering gib code (which I don't think are compatible with the DOS version), or being rid of the obnoxious blockmap bug and correcting the blood colors in Doom.


I might give RedNukem a try, though I don't actually know a whole lot about it other than it exists and is based more directly on the source code vs. eDuke32 which apparently is based off the original eDuke which was built from NAM/WWII GI? Or something to that effect?

This post has been edited by Ninety-Six: 25 May 2021 - 08:09 AM

3

User is offline   ck3D 

#12

View PostNinety-Six, on 25 May 2021 - 08:08 AM, said:

I might give RedNukem a try, though I don't actually know a whole lot about it other than it exists and is based more directly on the source code vs. eDuke32 which apparently is based off the original eDuke which was built from NAM/WWII GI? Or something to that effect?


I think it's at least also based on the old JonoF port? IIRC in the early naughts most people still used Build but some were already experimenting with alternative editors such as Mapster (the original), Newbuild or Makemap. I remember back when Dukeroch used to be popular as a launcher, too. Then Jonathan Fowler's port suddenly broke what had been hard limits (1024 sectors 8192 walls 4096 sprites) for over a decade, and so obviously most everyone moved onto that to be able to play and make maps that were twice to four times larger than possible before. Then ??? as I sort of slipped out of the community for a few years and when I came back, eDuke32/Mapster32 was the norm (and rightfully so, Mapster32 really makes mapping so much easier and faster than everything else, let alone OG Build), and I remember at the time it felt like an updated JonoF. There was also Lezing's LEBuild for a hot minute (there certainly still is, in fact: http://lzg.duke4.net/leb10.htm), which looked like an interesting alternative, but IIRC it wasn't nearly as WYSIWYG as JonoF/Mapster and so relatively few were those who ever figured it out.

This post has been edited by ck3D: 25 May 2021 - 01:36 PM

3

User is offline   Ninety-Six 

#13

Wasn't Megaton also somewhat based on JonoF?

I know this is diverting a bit from the original topic (but it seemed to have been solved already), but now I'm kind of curious about the entire Build engine family tree.
0

User is offline   ck3D 

#14

^ I actually didn't answer much I don't think, just recounted my naive perspective as a basic long time end user trying to keep up with the evolution of tech and operating systems, but the actual connection from port to port, editor to editor, I'm sure was always more complicated than that in detail (just like most community efforts always really rely on more than they publicly look in the end), for instance just the other day I was surprised and at the same time not so surprised to see Jonathon* (can't edit my former post) Fowler's name next to TerminX's as someone trying to get third party rights from 3DRealms a while back: https://dukenukem.fa...King_Collection and apparently he updated JonoF for World Tour support some time ago, too, a bit out of my view when for no real reason I was assuming he had long dropped out of the scene, which means you never really know the relationships going on in between all the established devs working on stuff (unless you follow this or that Twitter I guess, but I don't use Twitter), or every once in a while you get projects like LEBuild that just pop up out of nowhere and onto the family tree when someone just says fuck it and rewrites their own thing from scratch, resulting in amazing little oddities. But besides my observation and experience from a distance, I'm not especially qualified to comment on the actual history and connection from editor to editor and port to port, surely some others on here would be a lot more than I am.

But there's some history on the Wikipedia page for Build: Source release and further developments section

And also logs and notes on the development of the engine itself straight from Ken Silverman's on his website: http://advsys.net/ken/build.htm

A proper family tree now is something I would obviously like to see myself. My first thought is that would especially look good on a website where on every branch/entry you would click, you'd be redirected to an interview with the person responsible or at least just more general info.

This post has been edited by ck3D: 26 May 2021 - 01:52 AM

0

User is offline   ReaperAA 

#15

View PostFistMarine, on 24 May 2021 - 11:30 PM, said:

The exact same thing applies to Doom and other games from that era. Using the intended source port for playing a custom map or mod is the way to go.


Actually, this is much less of an issue with Doom wads. Especially if we talk about vanilla/limit-removing/boom compatible wads, then the modern Boom-compatible ports like DSDA-Doom, PrBoom+, Eternity Engine, GZDoom should be able to run pretty much every vanilla/limit-removing/boom compatible wads there exists (even from the 90s).

The only issue comes with wads/mods made for advanced Doom source port. Very old ZDoom mods may or may not work fine in GZDoom. Likewise, there are certain mods that use a modified version of a source port (like there is the Caverns of Darkness mod for Eternity Engine) that doesn't work in the base source port. Even then, the issue is less pronounced than it is in the case of EDuke32 mods. I have played ZDoom mods going as far back as 2012 that worked fine in newer GZDoom.

This post has been edited by ReaperAA: 27 May 2021 - 01:42 AM

0

User is offline   FistMarine 

#16

View PostNinety-Six, on 25 May 2021 - 08:08 AM, said:

I didn't realize that was broken.

The problem with that approach is that the DOS executables (and the more pure source ports) lack a lot of modern quality of life improvements, as well as overall stability. The DOS executables were a lot more prone to fatal crashes, and there are significant control problems in both the DOS versions and the more pure source ports. Doom admittedly has it far worse than Duke does in that department, being one slip-n-slide of drunken movement and the severe lack of customizable bindings (you can't even use the numpad). Duke is a lot easier to customize, but the mouselook is wonky, even with adjustable X and Y sensitivity scalers.

And then there's the lack of modern conveniences, such as stat tracking, widescreen support, various bug fixes, smaller enhancements, minor visual improvements, etc., that make the experiences a lot less frustrating overall.

I like to tinker and experiment with the DOS versions, but more out of curiosity and some minor nostalgia, rather than for serious play. I will if I absolutely have to, but I'd rather play in a port that lets me track my progress (as a completionist), has widescreen support and higher resolutions overall (so it doesn't look like the main character needs glasses), and allows for custom minor improvements, such as Darkus' fantastic fixed GAME.con or Fox's lingering gib code (which I don't think are compatible with the DOS version), or being rid of the obnoxious blockmap bug and correcting the blood colors in Doom.

I might give RedNukem a try, though I don't actually know a whole lot about it other than it exists and is based more directly on the source code vs. eDuke32 which apparently is based off the original eDuke which was built from NAM/WWII GI? Or something to that effect?

Yeah, it was one of the things that got fixed in the EDuke32 Addon Compilation version of the mod. The mod behaved strangely in EDuke32 because it also showed the two episodes with glitched titles (as far as I remember from when I played the mod first time many years ago), though this one might have been fixed in EDuke32 in last couple of years, not sure when but I highly recommend just playing the addon compilation version in EDuke32 to get some extra improvements on top of it as well, like a new soundtrack for the Water Bases episode. Otherwise, if you plan to play the original version of the LR&WB addon (available at gamers.org and dukeworld, don't bother with Moddb repacks by random people), play it in vanilla Duke3D 1.5 in DOSBox or something (man how much I wish I still had that old Windows 98 PC, maybe one day I might build an old Windows 98 PC just for the DOS and early Windows games because even DOSBox is unreliable for playing certain DOS games).

I get what you mean and I agree with your points. I also dislike the lack of level stats (monsters killed, secrets found and time elapsed) and various bugs/glitches that exist in DOS versions of DOOM and DUKE3D but I noticed that many modern ports of the games just don't have that nostalgic feeling because of the many changes they did, it feels like you're playing a slightly different game or recreation in another engine, at least that's how ZDoom feels to me and this is coming from someone who discovered ZDoom (I think it was an unofficial 2.0.96x build that was used for some mods) back in 2007 as the first source port and while I loved many enhancements it brought, I also felt there's been many regressions, when comes to certain changes (the lack of demo loop, centering weapon when firing, etc) or fixes or features (bullet holes, blood splats, projectile decals) they added. Even back then I felt that I was missing that original feeling and wished I could re-experience the Doom engine games, Duke3D and others just like how was back then when I was a few years old. I hadn't heard of DOSBox yet at that time (other than seeing it on some YouTube videos in 2010 or so when they showed the original Doom or Duke3D) and I didn't know of source ports Chocolate Doom or PrBoom+ yet, even though I may have heard of them at that time by watching some random YouTube videos. I guess I wasn't curious enough to download and try them out, plus the fact why I didn't initially like PrBoom+ was that it's set up a bit poorly by default (so you must mess with some settings to get it right, luckily it takes a minute to change a few settings related to Video modes, disable transparency, enable ENDOOM screen, while leaving everything else by default), complevel thing also confused me back then because I wouldn't know to tell if the parameter had any effect in game and the way YouTubers had it configured (and they most likely ran GlBoom+ which is very ugly, a lot uglier than GZDoom is with texture filtering on, which I always disable BTW, GZDoom doesn't look too bad once you disable the texture filtering).

OK, to clarify, some Doom source ports (at least the vanilla/boom compatible ones) still retain the original vanilla feeling, so they might as well replace the original executables (especially with the new Unity ports that are a great way to re-experience the original games, wish I owned these ports though) and no one would complain about the absence of them (except the hardcore purists, I'm NOT a hardcore purist BTW as I don't want to play on low resolution on source ports for example). Sadly, this isn't really the case with Duke3D. We lack a proper vanilla source port that can play all the DOS versions (or at least both 1.3D and 1.4/1.5 rather than just 1.4/1.5). Other than RedNukem (that only plays Duke3D 1.5 and uses the EDuke32 interface), the closest thing would be XDuke and its various forks (I think there were other older ones like icclus.org and Rancidmeat but who cares about them?) but the most notable one is called Chocolate Duke3D and it sucks. They (XDuke family ports) are all very underwhelming, filled with various bugs (example: missing spinning icon when loading a saved game, the demo cameras don't work during playbacks, though the latter one is apparently a bug inherited from the official Duke3D source code) that I don't recommend them. I once read somewhere that even the original levels are broken (I think E2L4 or E2L5 was one of the levels mentioned) but I can't confirm that myself because I never played XDuke or Chocolate Duke3D other than just testing the first level and that was back in 2012-2013 when I was looking for a Chocolate Doom equivalent for Duke3D instead of only using DOSBox. I am hopeful one day we get a proper Chocolate Duke3D that is based off original source code and has a few improvements but still retains the vanilla Duke3D feeling.

I don't know but to me the original DOS versions of Doom and Duke3D play just fine with default keyboard controls (no need to rebind the controls), meaning just arrow keys for movement, though I do admit is slightly harder to dodge enemy attacks and shoot them while you are dodging, as I use the < and > keys for strafing in those cases or even just trying to dodge backwards if I have enough room to dodge. In Doom, as far as I know, the mouse moves you forward and backward, making traversing on catwalks really painful if you were playing the DOS versions with a mouse or certain source ports that have this enabled by default, like Chocolate Doom and PrBoom+ (not a problem in ZDoom ports where I always have mouselook enabled and smoother controls). I realize there is an utility called novert but I just don't see why you have to download a separate utility to fix the broken mouse movement. Mouse aiming is also wonky for BUILD engine games, I did play through Duke3D and SW (that was in 2014 or so, which was also when I played SW first time) with mouse and I found annoying how in Duke3D 1.3D the mouse aim was inverted (so you needed to go in SETUP.EXE for mouse controls and put a value of -1.0 or something like that), though Atomic 1.5 didn't have this problem, so the mouse aiming was a bit more reliable but still a bit wonky and since then I never bothered again with mouse in the DOS version of any FPS game, I just do it keyboard only and I can do just fine, I rarely die in original levels (other than in first two levels of Ultimate Doom and maybe some levels in Final Doom and Master Levels, though I haven't played the latter two in quite a long time to remember painful levels). For the record, I use mouselook in EDuke32, along with the new modern controls that are set up by default and it is a very smooth experience, especially for the new custom maps and mods created for it, meaning I have a much higher survival rate and it makes it easier to engage with the monsters than just peeking around the corners. But there are occasional changes that break certain maps over time, meaning we go to the issues I mentioned above and I don't want to repeat myself again.

I appreciate being able to play the game natively on the OS instead of having to mess with emulators but sometimes it is nice to have the original executables around, at least for the original levels and certain older maps/mods. I always try to look for solutions and choose the best way that makes sense for me, whenever I get back to the original levels or feel like playing a new map/mod once in a while.

View PostReaperAA, on 27 May 2021 - 01:39 AM, said:

Actually, this is much less of an issue with Doom wads. Especially if we talk about vanilla/limit-removing/boom compatible wads, then the modern Boom-compatible ports like DSDA-Doom, PrBoom+, Eternity Engine, GZDoom should be able to run pretty much every vanilla/limit-removing/boom compatible wads there exists (even from the 90s).

The only issue comes with wads/mods made for advanced Doom source port. Very old ZDoom mods may or may not work fine in GZDoom. Likewise, there are certain mods that use a modified version of a source port (like there is the Caverns of Darkness mod for Eternity Engine) that doesn't work in the base source port. Even then, the issue is less pronounced than it is in the case of EDuke32 mods. I have played ZDoom mods going as far back as 2012 that worked fine in newer GZDoom.

I agree. In general most stuff should run just fine in the latest version of a particular port (GZDoom in your case, latest version should run pretty much everything with an occasional broken map every now and then). There are some exceptions of wads that only work with a certain version of the source port, though in some cases they come with their own port included as well, at least the standalone mods. I haven't tried running Caverns of Darkness in recent versions of Eternity but I recall not too long ago I downloaded the wad and its executable, put it into its own COD folder (and dropped DOOM2.WAD in it), loaded in DOSBox (as it's a DOS executable) and it crashed during loading. The same issue occurs with another old port (SMMU, aka Smack My Marine Up, which I wanted to test only for the Quake-like start map included) and I'm not sure why. I guess it needs a DOS extender utility? I think Mr.Flibble can help here explain better because last year he helped me make an old EDUKE mod from early 2000s run in DOSBox without crashing. I'm getting a bit off-topic, so I will just ask Mr.Flibble in another PM about running those two (I can run BOOM and MBF in DOSBox just fine for example, so it's just COD and SMMU executables that are crashing dosbox 0.74-3).

I know there's also many older ZDoom wads that require specific older ZDoom versions to run correctly (I use ZDoom 1.22, 1.23b33, 2.0.98 and 2.1.7 for older ZDoom wads up until 2007 or so, then I use ZDoom 2.8.1 for the rest that came since then) but I've also had a few older GZDoom wads (from early 2010s) that randomly crashed GZDoom 1.9.1 (which is the minimum version I use for every old GZDoom wad and it was released in early 2016), while they worked fine in GZDoom 2.4.0 (released in 2017). Do you have an explanation for that? Because I have no idea what's up with that and I use GZDoom versions 1.9.1, 2.4.0 and 3.7.2 for wads released until 2018-2019 or so (not using 4.x series yet for the newer wads as I wait until the final 4.x release, sorry I can't play yet amazing stuff like Faithless Trilogy). If you wonder, the problematic mods in question were Phocas Island 2, Realm of Cheogh (Cheosgh?) and Putrefier. They crashed GZDoom 1.9.1 either upon starting a new game (Putrefier) or halfway through (on PI2, I could access the first map with difficulty options but crashes upon loading next level, then on Roch it crashed at various points so it was hard to beat even with cheats (GOD, FLY, NOCLIP) because I had to be careful to not trigger some monster pop-up traps or some cutscenes that caused the crash) but they worked just fine in GZDoom 2.4.0 without any issues from the small tests I took (PI2 allowed starting the next map just fine, Roch no longer crashed on those monster pop-ups or cutscenes), plus I completed Putrefier (100% everything) that way recently, will go back on PI2 and Roch at a later time.

Bottom line, I always try to have a minimum version of certain source ports (in more vanilla ports like Chocolate and Crispy, I usually have the latest version installed since there is no need to keep an older inferior version of the port, on Eternity I'm stuck with 4.00.00 until I finish some older Eternity wads and then I will upgrade to 4.02.00 for more recent releases, while for PrBoom+ I still use 2.5.1.4 for most wads out there, then I will use the umapinfo fork for newer releases).

Sorry for getting off-topic, maybe some of these posts should be split into a separate topic since the DukeVR issue was resolved long ago. I can only advice for others with a similar problem, to use the original executable when encountering a broken map/mod under EDuke32 or any other source port for any other game.
0

User is offline   Ninety-Six 

#17

The nostalgia aspect isn't that strong of a pull in my case. While it's nice to remember what it was like back in the old days... in all honesty I do that more to maintain an appreciation for how far we've progressed with these source ports. To better appreciate actually being able to reliably shoot things in Doom without half your bullets going through the target, or explosive damage that works how it was supposed to in Duke.

I'm not a fan of becoming frustrated by things outside my control, if that's not obvious from several straight years of ranting about certain mods being exactly that. I like being able to smooth that stuff out. And moreover, I prefer the intent of the original game design over the result (And I mean the intent of the vanilla game, vs. the intent of modders). I doubt id liked the chainsaw being rendered useless half the time, just as I doubt 3DR intended the battlelords to be shrinkable.



As for LR&WB, the episode titles worked fine when I played it. If I ever give it a shot again, maybe I will use the compilation version. Though I wish the fixes were also available separately, or the installer could be selective about what you want to install. I already have a large duke 3d-dedicated folder (and sub-folders) full of mods and maps already. A lot of what I would get from the compilation would be redundant. I am only really interested in the fixes.
0

User is offline   ReaperAA 

#18

View PostFistMarine, on 28 May 2021 - 02:50 AM, said:

I've also had a few older GZDoom wads (from early 2010s) that randomly crashed GZDoom 1.9.1 (which is the minimum version I use for every old GZDoom wad and it was released in early 2016), while they worked fine in GZDoom 2.4.0 (released in 2017). Do you have an explanation for that?.

Probably some bug in the 1.9.1 version which might have been fixed by the time 2.4.0 came.

Also note that there could be mods out there from 2015-2016 that may not run on 1.9.1 as they may use features (likely rendering features) that are not available in the 1.x version of GZDoom but are present in GZDoom 2.x as it version 2.0.0 had already released sometime around 2015. Version 1.9.x was just a compatibility release for old hardware that could not run OpenGL 2.x (kinda like LZDoom is nowadays) and version 1.8.6 was the last major GZD release before 2.x was released.


View PostFistMarine, on 28 May 2021 - 02:50 AM, said:

(not using 4.x series yet for the newer wads as I wait until the final 4.x release, sorry I can't play yet amazing stuff like Faithless Trilogy)..

No need to wait though. The previous release of GZDoom (4.5.0) was very stable (probably as much as it is gonna get), so you shouldn't really wait for that final 4.x version. Besides, the major number change only happens when something really really significant is added in GZDoom. In 4.x, it was the introduction of Vulkan renderer and the localizations. So you never know how much you would have to wait for that "final 4.x" version.

View PostFistMarine, on 28 May 2021 - 02:50 AM, said:

while for PrBoom+ I still use 2.5.1.4 for most wads out there, then I will use the umapinfo fork for newer releases).

There is also DSDA-Doom, which is fork of PrBoom+ that supports umapinfo and also has some other features. Most importantly, it supports Heretic.
0

#19

Pipebomb stacking is fixed as of r9804.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options