xepop Posted March 25, 2015 Bug in save/loading routines: Order of thinkers in thinkercap is not preserved. This leads to possible desyncs as rng depends on them being in correct order. 0 Quote Share this post Link to post
fabian Posted March 25, 2015 Afterglow said:Is there a known issue with neighbouring sector sky heights differing? e.g, sector #1 is 256 and neighbour sector #2 is 384. Raised surfaces visible in sector #2 should be visible from sector #1. Would you mind telling us which map this is? 0 Quote Share this post Link to post
entryway Posted March 25, 2015 xepop said:Bug in save/loading routines: Order of thinkers in thinkercap is not preserved. This leads to possible desyncs as rng depends on them being in correct order. Patch? 0 Quote Share this post Link to post
Memfis Posted March 25, 2015 Afterglow, the "see through sky" trick needs a little workaround when you use different brightness levels in the area. I can't say that I fully understand how it works but here is an example of how it can be fixed in some situations. (left area: bugged, right area: fixed) 0 Quote Share this post Link to post
Rez Posted March 25, 2015 xepop said:Bug in save/loading routines: Order of thinkers in thinkercap is not preserved. This leads to possible desyncs as rng depends on them being in correct order. Is this an old bug, maybe inherited from BOOM code? Cuz there's a bug way back there that sometimes causes an unsave: save game reload what loads proves to be the previous save, not the one you just made (which is nowhere to be seen) Also, occasionally a very large DSG will become a partly-blank file which naturally does not work. Anyway, could your bug the the cause of these as well? 0 Quote Share this post Link to post
xepop Posted March 25, 2015 entryway said:Patch? I don't have a proper solution yet. Currently my workaround of reordering thinkercap in the end of P_UnArchiveSpecials segfaults on some tics when loading. Rez said:Anyway, could your bug the the cause of these as well? I don't know enough of doom's inner workings to say. I just hack it until it works for my needs. 0 Quote Share this post Link to post
Afterglow Posted March 26, 2015 fabian said:Would you mind telling us which map this is? An unreleased map of mine. I noticed the same bug in another map in the set. I'll try to cut out a section to put a demo together for you before today is through. 0 Quote Share this post Link to post
TimeOfDeath Posted March 26, 2015 Afterglow said:An unreleased map of mine. I noticed the same bug in another map in the set. I'll try to cut out a section to put a demo together for you before today is through. Unfortunately it's not a bug, like Memphis said that's how doom.exe handles adjacent skies with different brightnesses + ceiling heights. In your map, you could make the stair sectors 384 ceiling and put triangle sectors along the left walls at 256 height. 0 Quote Share this post Link to post
noshutdown Posted April 7, 2015 hello andrey, prboom+ is by far my favorite sourceport, and i would express my thanks to you and others guyz working on the project for your efforts. i have an idea on an automap feature although i wonder if its been suggested by others in the past years: since glboom+ has textured automap, why not replace all triangle "things"(in iddt cheat mode) on the map with corresponding sprites and make it look like a top-down shooting game? this may be quite some work, so maybe you can divide it into a few incremental stages: stage 1: monsters, pickup items and doomguy have standing sprites without facing directions. stage 2: corpses, decorations, projectiles and explosions have sprites, just like this map on compete-n. stage 3: monsters and doomguy have standing sprites with facing directions. stage 4: monsters and doomguy have animated sprites. do you think this idea worth working on? 0 Quote Share this post Link to post
entryway Posted April 7, 2015 noshutdown said:why not replace all triangle "things" Do you know about 'icons' mode? It uses separate icons for ammo, armor, health, keys, powerups, weapon, monsters, map marks, probably something else. 0 Quote Share this post Link to post
Memfis Posted April 7, 2015 :o Is that a remake of Icarus in progress? :) 0 Quote Share this post Link to post
Doom_user Posted April 13, 2015 I recently noticed that translucency effects for things like BFG attacks and Imp fireballs get disabled if you use one of the vanilla comp levels. Since these effects are visual only and don't affect demo compatibility, perhaps an option could be added to allow them even when using a vanilla comp level. 0 Quote Share this post Link to post
Memfis Posted April 13, 2015 It looks like jump in PrBoom-Plus is 8 units higher than in ZDoom. Is this a mistake? 0 Quote Share this post Link to post
Linguica Posted April 13, 2015 It's not like there is a canonical jump height... 0 Quote Share this post Link to post
Memfis Posted April 13, 2015 True, but if that feature was added for compatibility with jumping wads, it's better not to allow jumping higher than was intended imo. Check out MAP02 of Daniel Level Serie 01 for a good example. In PrBoom-Plus you can immediately jump on to the central platform and get the red key. In ZDoom you need to search for a switch that raises a bridge to the platform first (ok, with a tricky strafejump you can avoid that but clearly that was not intended by the author). Also it would be cool if there was some way to record with jumping enabled... 0 Quote Share this post Link to post
Rez Posted April 14, 2015 Never_Again said:There is: use Zdoom. <*ick*> Why not make max jump height configurable? 0 Quote Share this post Link to post
fabian Posted April 14, 2015 The jumping feature has been taken from Hexen, where "jumping" sets vertical momentum to 9 fracunits. I don't think it makes any sense to port the code over in pristine and then change this one value only. I remember we had this discussion before, maybe in the Crispy Doom thread. I think the consensus was that jumping is considered as cheating anyway, like a one-time IDCLIP, and is only supposed to get you out of a stuck situation. As such, it doesn't make sense to restrict its height to a different arbitrary value. There is another jumping code path , though, that can be found in Strife. Instead of the jumping code in Hexen, which sets vertical momentum to 9 fracunits, it merely adds 8 fracunits (and has a different check for allowing the next jump). So, standing jump in Strife is less high. My initial patch implemented both code paths and a switch to choose between them, but Andrey eventually removed the Strife path. Edit: Regarding demo recording, enabling jumping also allows for some in-air movement control that you normally do not have. So, having this feature enabled without actually jumping even once will already cause demos to desync. 0 Quote Share this post Link to post
Rez Posted April 14, 2015 Why is that? Cuz jumping doesn't cause desync in its great-uncle Fusion, far as I've noticed. 0 Quote Share this post Link to post
fabian Posted April 14, 2015 Most probably because Fusion introduced its own demo format which was incompatible to anything else. Edit: Right there in G_GAME.C. static void G_WriteDemoTiccmd(ticcmd_t* cmd) { [...] if (demo_version > 203) demo_p[4] = cmd->buttons2; // Hakx 8/23/1999 Extended buttons support [...] } 0 Quote Share this post Link to post
Rez Posted April 14, 2015 fabian said:Most probably because Fusion introduced its own demo format which was incompatible to anything else. Speaking as one of the Fusion team -- feel free to steal it, or anything else. We don't mind. :) 0 Quote Share this post Link to post
noshutdown Posted April 15, 2015 entryway said:Do you know about 'icons' mode? It uses separate icons for ammo, armor, health, keys, powerups, weapon, monsters, map marks, probably something else. no... i havn't played the 2.5.1.4test version yet, i am still playing previous 2.5.1.3. 0 Quote Share this post Link to post
Xaser Posted April 15, 2015 fabian said:The jumping feature has been taken from Hexen, where "jumping" sets vertical momentum to 9 fracunits. I don't think it makes any sense to port the code over in pristine and then change this one value only. ZDoom seems to operate on the same scale, judging from the native DECORATE code ("Player.JumpZ" in Hexen's player def is 9; all others including Strife use 8). If the issue was the other way around (jump height good in PrBoom, bad in ZDoom), it'd be easily moddable to match, but alas... 0 Quote Share this post Link to post
fabian Posted April 15, 2015 Xaser said:jump height good in PrBoom, bad in ZDoom define "good" and "bad"... Anyway, I don't insist on jumping momentum being 9 fracunits, and I don't think Andrey does, either. If all other source ports supporting jumping have agreed that 8 fracunits is right, then maybe we should adjust that value in PrBoom+ as well (and Crispy doom, FWIW). Andrey, you should really consider to release to current code snapshot as 2.5.1.4, please. People are still using 2.5.1.3 and there are around 300 SVN commits between this and now. 0 Quote Share this post Link to post
dew Posted April 17, 2015 Damn! Generalized door action with "keycard and skullkey are the same" seems screwed up and opens with just red+blue in MBF compatability (complevel 11). Here it's action 15311, but door speed, repeatability and closing the door again don't matter and it affects all those variants. It does not happen at complevel 9! I can't tell you if this happens in vanilla MBF though. edit: Jesus christ, this shit is actually on the wiki. Never mind. :/ I'm gonna go vomit on a puppy. 0 Quote Share this post Link to post
noshutdown Posted April 22, 2015 i wanna know when will the 2.5.1.4test version become an "official" release? and how many new bugs found in recent test versions? are known demo desyncs being worked on? 0 Quote Share this post Link to post
noshutdown Posted April 26, 2015 TimeOfDeath said:What known demo desyncs? one reported here: http://sourceforge.net/p/prboom-plus/bugs/240/ but yeah, such cases have become pretty rare in recent years. 0 Quote Share this post Link to post
Linguica Posted April 26, 2015 I think it's high time to polish up the current codebase and release 2.6, if only for the wigglefix (which is really essential for playing software mode in high resolution). 0 Quote Share this post Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.