EDuke32 issueshttps://voidpoint.io/terminx/eduke32/-/issues2021-08-03T02:33:11-07:00https://voidpoint.io/terminx/eduke32/-/issues/184Duke3D: Activating a door while opening causes the sound to play at the wrong...2021-08-03T02:33:11-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Activating a door while opening causes the sound to play at the wrong timeThis is an issue that originates from DOS Duke3D.
Hitting "use" on a door that is in the process of opening will cause the sound to play at the endpoint of its motion, instead of on activation. Moreover, if this sound is set to loop, it...This is an issue that originates from DOS Duke3D.
Hitting "use" on a door that is in the process of opening will cause the sound to play at the endpoint of its motion, instead of on activation. Moreover, if this sound is set to loop, it will continue playing indefinitely after the door stopped moving.
[doorsound_bug2.map](/uploads/7c09def7c39ce9f7e5530efd9acb1fd5/doorsound_bug2.map)https://voidpoint.io/terminx/eduke32/-/issues/183Duke3D: Jump-crouch exploit still possible in certain areas2023-05-21T13:48:22-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Jump-crouch exploit still possible in certain areasI mentioned this on Discord, and I'm aware that this is tough, maybe impossible to resolve -- but I wanted to document it anyways.
The original jump-crouch exploit from DOS involved holding both crouch and jump during landing, thus bein...I mentioned this on Discord, and I'm aware that this is tough, maybe impossible to resolve -- but I wanted to document it anyways.
The original jump-crouch exploit from DOS involved holding both crouch and jump during landing, thus being able to pass through incredibly tight spaces. The severity of this has been reduced, however it is still possible to get into certain passages by jumping and holding crouch when landing. Unfortunately, these are usually shrinker passages.
Demonstration (E2L11): https://cdn.discordapp.com/attachments/461290354726010891/870759546459664424/2021-07-30_22-06-40.mp4
Another instance of this can be found in E5L4 (Mirage Barrage) of World Tour, which also involves a shrinker puzzle:
![duke0004](/uploads/387d0fa79362e69c46a01c30217ed696/duke0004.png)
Note that by simply crouching, it is not possible to enter these passages.https://voidpoint.io/terminx/eduke32/-/issues/181Duke3D: Jittery camera movement when on top of stretching sector (SE 20)2021-07-30T07:28:26-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Jittery camera movement when on top of stretching sector (SE 20)This is an issue that dates all the way back to DOS.
Open the test map (from E2L5) activate the keycard panel to make the sector stretch, then jump onto it and strafe in the direction it is extending. You will notice rather jittery came...This is an issue that dates all the way back to DOS.
Open the test map (from E2L5) activate the keycard panel to make the sector stretch, then jump onto it and strafe in the direction it is extending. You will notice rather jittery camera movement while it is active.
Video demonstration: https://cdn.discordapp.com/attachments/461290354726010891/870661445648547880/2021-07-30_15-36-29.mp4
Test map: [jittersector.map](/uploads/c95eed795f03d6a2d41984b0063a5e63/jittersector.map)https://voidpoint.io/terminx/eduke32/-/issues/180Duke3D: Solar panel sprite cutoff in E2L32023-09-01T14:59:17-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Solar panel sprite cutoff in E2L3Started with r7415 (74b3c44e).
The solar panel sprite that is placed here in E2L3 is cut off in the middle in Polymost as of r9487, when viewed from certain angles. Used to not be the case beforehand.
Before:
![duke0128](/uploads/d828b...Started with r7415 (74b3c44e).
The solar panel sprite that is placed here in E2L3 is cut off in the middle in Polymost as of r9487, when viewed from certain angles. Used to not be the case beforehand.
Before:
![duke0128](/uploads/d828b95346b087303530aa4e91b038bf/duke0128.png)
After:
![duke0129](/uploads/1de1a4d840da577781cbbc0ad7e94e24/duke0129.png)https://voidpoint.io/terminx/eduke32/-/issues/178Brightness Slider is broken2021-07-26T15:46:29-07:00M KBrightness Slider is brokenIn every build of VoidSW, the brightness slider does not work. It uses default brightness.In every build of VoidSW, the brightness slider does not work. It uses default brightness.https://voidpoint.io/terminx/eduke32/-/issues/172Duke3D: Hardcoded guts and scrap entities will collide with non-solid TROR tr...2021-08-01T13:26:12-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Hardcoded guts and scrap entities will collide with non-solid TROR transitionsSimilarly to #171, the hardcoded blood and gore sprites spawned by the `guts` CON command are not TROR-aware, and will collide with non-solid TROR transitions. (simply shoot the commander in the test map while flying to see the problem)
...Similarly to #171, the hardcoded blood and gore sprites spawned by the `guts` CON command are not TROR-aware, and will collide with non-solid TROR transitions. (simply shoot the commander in the test map while flying to see the problem)
![duke0005](/uploads/c115b543580240d2e2d833bf4bef65bb/duke0005.png)
This also applies to the scrap spawned by certain actors and objects. Other effects may also not be TROR-aware.
Test map: [trorcommander.map](/uploads/0eff3ebf65059a2a18358834cde8f09e/trorcommander.map)https://voidpoint.io/terminx/eduke32/-/issues/170Duke3D/Polymer: Opening the Load/Save Game menu clobbers tile 02023-05-21T13:47:11-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D/Polymer: Opening the Load/Save Game menu clobbers tile 0Opening the save menus does something that causes tiling for tile 0 to fail. All other tiles appear to be unaffected.
A minor issue by itself because tile 0 is likely not used in maps anyways, but maybe it is indicative of a more seriou...Opening the save menus does something that causes tiling for tile 0 to fail. All other tiles appear to be unaffected.
A minor issue by itself because tile 0 is likely not used in maps anyways, but maybe it is indicative of a more serious problem.
Before opening the "load game" or "save game" menus:
![duke0000](/uploads/fce2270b6193cdd8e277417cd855e230/duke0000.png)
After opening:
![duke0001](/uploads/c8574c74eb3cd350a222bf347fa535cc/duke0001.png)
Interestingly, you can still see a single tile instance of the texture render properly.
Edit: I forgot to mention that this only happens in the Polymer renderer.https://voidpoint.io/terminx/eduke32/-/issues/167First Rotatesprite Interp comes from center screen with 0 scale. (RS_FORCELERP)2023-05-21T13:46:50-07:00Jordon MossFirst Rotatesprite Interp comes from center screen with 0 scale. (RS_FORCELERP)If RS_FORCELERP is on, the first time a sprite with a particular guniqhudid shows up, it interps from the center of the screen, with 0 scale.
Case in point here. I'm using RS_FORCELERP on the Flamethrower's upper segment. First time I f...If RS_FORCELERP is on, the first time a sprite with a particular guniqhudid shows up, it interps from the center of the screen, with 0 scale.
Case in point here. I'm using RS_FORCELERP on the Flamethrower's upper segment. First time I fire, you can see how messed up it is. Second time, is fine.
This behaviour can also be observed in the Vanilla game with the shotgun. First time the shotgun's muzzle flash shows up, it shows floating at the screen's center for a frame or two.
My guess, is that the first frame a new guniqhudid is displayed, it needs to have the old position set to match.
![video](http://shadowmavericks.com/files/ShareX/PLAYER1_%20THERMAL%20BASE%20%28UNFINISHED%29%20-%20StrikerDM%20%28Development%20Build%29%20-%20EDuke32-OldMP%202021-07-10%2004-41-36.mp4)https://voidpoint.io/terminx/eduke32/-/issues/166[Linux] Issue with PCM Shutdown occurs when trying to quit Mapster322023-05-21T13:46:20-07:00Filip Homolka[Linux] Issue with PCM Shutdown occurs when trying to quit Mapster32The title is more or less how it goes, the issue can be reproduced by running mapster32 on linux, then quitting. Mapster never quits, just hangs, until the process is forcefully terminated. Poking at the issue reveals that the issue happ...The title is more or less how it goes, the issue can be reproduced by running mapster32 on linux, then quitting. Mapster never quits, just hangs, until the process is forcefully terminated. Poking at the issue reveals that the issue happens in `multivoc.cpp` `MV_Shutdown` function calls `SoundDriver_PCM_Shutdown` function, and never progresses from there. `SoundDriver_PCM_Shutdown`, defined in `drivers.cpp`, contains one line: `SoundDrivers[ASS_PCMSoundDriver].PCM_Shutdown();`, and this is where it hangs until killed.
There is a potential for this to be specific to few machines, however, Mapster32 is the only program that I have experienced this with. Windows does not have this issue.https://voidpoint.io/terminx/eduke32/-/issues/163Engine: Settings changes are discarded on game crash (or when terminating the...2021-07-05T10:22:58-07:00Dino Bollingerdino.bollinger@gmail.comEngine: Settings changes are discarded on game crash (or when terminating the process)This has been a thorn in my side for as long as I can remember using eduke32, all the way back to the mid-2000s
Basically, if you change any settings, like the volume, resolution, keybindings, you name it, and the game happens to crash,...This has been a thorn in my side for as long as I can remember using eduke32, all the way back to the mid-2000s
Basically, if you change any settings, like the volume, resolution, keybindings, you name it, and the game happens to crash, all of it will be reset to the previous values when you next launch the game. This can lead to the user having to redefine all his settings every session if said sessions happen to end with crashes.
This occurs because the `eduke32.cfg` and `settings.cfg` files are only written if the game closes normally. It should either be updated immediately on changing the settings, or there should be a handler, if possible, that can write to these files if a crash occurs. (though the latter is impossible if one kills the process, so I suggest immediately persisting the settings if they differ)
Fixing this would be a huge boon to everyone who happens to encounter a crash. Almost everybody who first launches the game is not going to close it immediately after changing the settings, making this situation highly likely. This applies to eduke32, VoidSW, Ion Fury, and any mod that runs on eduke32.https://voidpoint.io/terminx/eduke32/-/issues/161Engine: Possible stutter fix2023-05-21T13:46:02-07:00Jordon MossEngine: Possible stutter fixFor some time, I know we've been trying to figure out a way to resolve stuttering/frame pacing issues in Windows 10 (seems related to desktop composition, which gets disabled by eduke32 in Windows 7).
About a month ago, I tried to resol...For some time, I know we've been trying to figure out a way to resolve stuttering/frame pacing issues in Windows 10 (seems related to desktop composition, which gets disabled by eduke32 in Windows 7).
About a month ago, I tried to resolve this by calling dwmapi_DwmFlush() after calling SDL_GL_SwapWindow, and lo and behold, it worked very nicely. However, this has the effect of preventing the framerate from ever going above your refresh rate, regardless of the setting of r_maxfps.
I suggest giving this a try, and sending builds out to people experiencing frame stuttering, see if it works out.https://voidpoint.io/terminx/eduke32/-/issues/154Duke3D: Can't throw pipebomb through small opening in Red42023-05-21T13:45:38-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Can't throw pipebomb through small opening in Red4This occurs since r7480 (cdcc13e8), with the behavior changing again in r7484 (eca7133e).
It is no longer possible to throw a pipebomb through the crack in the image below. Instead, it gets stuck inside the crack, and never passes throu...This occurs since r7480 (cdcc13e8), with the behavior changing again in r7484 (eca7133e).
It is no longer possible to throw a pipebomb through the crack in the image below. Instead, it gets stuck inside the crack, and never passes through. Previous to r7480 the pipebomb went through fine. This is essential for level progression in this map.
![duke0008](/uploads/42f8747a9a1965f22e14702fb028298c/duke0008.png)
This is from the map !["Red 4" by Merlijn van Oostrum](http://dnr.duke4.net/maps/Red4:_Boat_Trippin.html). Attached is a cut-down version to demonstrate the problem.
[clipping_crackwall.map](/uploads/ed366e4416cee498e7edfcc62b53159a/clipping_crackwall.map)https://voidpoint.io/terminx/eduke32/-/issues/149Too easy to strafe-run into your own projectiles and damage or kill yourself.2023-05-21T13:45:12-07:00Jordon MossToo easy to strafe-run into your own projectiles and damage or kill yourself.Ever since the projectile collision code has been re-worked, it's been far too easy to strafe-run into your own projectiles (especially slow ones like the RPG, Devastator, and Shrinker), causing you to damage or kill yourself.
Video dem...Ever since the projectile collision code has been re-worked, it's been far too easy to strafe-run into your own projectiles (especially slow ones like the RPG, Devastator, and Shrinker), causing you to damage or kill yourself.
Video demonstrating the issue: http://shadowmavericks.com/files/ShareX/RPGClipping.mp4https://voidpoint.io/terminx/eduke32/-/issues/1472D inaccuracy with texture panning and firstwall2023-09-01T14:57:35-07:00Max Ylitalo2D inaccuracy with texture panning and firstwallScreenshots are from polymer/classic/polymost and finally 2D.
Issue is that texture panning does not match what you see in 2D compared to 3D.
Let's focus on the blue "seat" sector
Red walls represent firstwalls being used visually.
I be...Screenshots are from polymer/classic/polymost and finally 2D.
Issue is that texture panning does not match what you see in 2D compared to 3D.
Let's focus on the blue "seat" sector
Red walls represent firstwalls being used visually.
I believe this is caused by how the engine processes firstwalls and the alignment of R and panning.
The seat aligns when the firstwall is at the proper 0,0 panning position, this happens when the redwall is encountered before the green wall in clockwise rotation.
When the green wall appears first, it still considers redwall as the firstwall but what would've been .point2 before ends up being the actual firstwall in this case.
This can be replicated quite easily when X flipping sectors for geometry that has been aligned with clockwise rotation in mind.
On one shot, I drag the wall ever so slightly, this "fixes" the panning to be where it should be visually in 2D mode.
![capt0124](/uploads/f34a7815dc364c4858d0f84dcfd9b079/capt0124.png)
![capt0123](/uploads/3c07c601299ad23717dac9d8ccd04465/capt0123.png)
![capt0122](/uploads/e43dec298fc682e8e13339b9d5df3519/capt0122.png)
![capt0125](/uploads/6449a3baa363b16cba7e967471164437/capt0125.png)
![capt0126](/uploads/abf35f529db5675cc5f15f9a65ee425b/capt0126.png)https://voidpoint.io/terminx/eduke32/-/issues/142Polymost: Sprite ordering issue with wall-aligned sprites2023-08-16T23:31:03-07:00Jordon MossPolymost: Sprite ordering issue with wall-aligned spritesSeems that in Polymost, wall-aligned sprites that are in front of other wall-aligned sprites get rendered behind, rather than in the proper order, unless you're point-blank to said sprites. This issue doesn't occur in software.
Far (Pol...Seems that in Polymost, wall-aligned sprites that are in front of other wall-aligned sprites get rendered behind, rather than in the proper order, unless you're point-blank to said sprites. This issue doesn't occur in software.
Far (Polymost):
![duke0102](/uploads/ab97c393d42b5deb09212d1fe163b6a0/duke0102.png)
Close (Polymost)
![duke0101](/uploads/07a947c1d65a1dbfe7f0c9d79e009bba/duke0101.png)
Far (Software):
![duke0103](/uploads/ca6e1e46a7e0656127a868cfd7160cbe/duke0103.png)https://voidpoint.io/terminx/eduke32/-/issues/136Engine: Wrong sprite rendering order in classic mode, where sprites are in cl...2023-05-21T13:42:13-07:00Dino Bollingerdino.bollinger@gmail.comEngine: Wrong sprite rendering order in classic mode, where sprites are in close proximity to maskwallsFound by MetHy.
Sprites that are in close proximity to a maskwall appear to suffer from some sort of rendering issue where they are drawn behind sprites that are further away. It doesn't seem to matter how far the camera is away from th...Found by MetHy.
Sprites that are in close proximity to a maskwall appear to suffer from some sort of rendering issue where they are drawn behind sprites that are further away. It doesn't seem to matter how far the camera is away from the sprite.
This does not occur in Polymost.
Examples:
![duke0006](https://media.discordapp.net/attachments/461290354726010891/772453030674432020/duke0011.png?width=1120&height=630)
![duke0008](/uploads/eafbd9187ab46ffdfaad6f698435f09a/duke0008.png)
In addition, sprites may also be drawn in front of a maskwall when they are actually behind it. Happens in Rednukem as well:
![duke0007](https://cdn.discordapp.com/attachments/461290354726010891/772452968863236136/duke0284.png)
Test Map: [MASKWALL.map](/uploads/977ab24335a346739d5acdc4d4bb91a4/MASKWALL.map)
The RR instance can be reproduced in the first level, near the hidden moonshine.https://voidpoint.io/terminx/eduke32/-/issues/135Duke3D: Ordering Issue with PROJECTILE_RPG_IMPACT and DAMAGESPRITE events2023-05-21T13:38:31-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Ordering Issue with PROJECTILE_RPG_IMPACT and DAMAGESPRITE eventsThe following block of code is present in `actors.cpp`, inside the function `ACTOR_STATIC void Proj_MoveCustom(int const spriteNum)`, starting at line 3109:
```cpp
A_DamageObject(otherSprite, spriteNum);
...
if (pProj->workslike & PRO...The following block of code is present in `actors.cpp`, inside the function `ACTOR_STATIC void Proj_MoveCustom(int const spriteNum)`, starting at line 3109:
```cpp
A_DamageObject(otherSprite, spriteNum);
...
if (pProj->workslike & PROJECTILE_RPG_IMPACT)
{
actor[otherSprite].owner = pSprite->owner;
actor[otherSprite].picnum = pSprite->picnum;
if (pProj->workslike & PROJECTILE_RPG_IMPACT_DAMAGE)
actor[otherSprite].extra += pProj->extra;
A_DoProjectileEffects(spriteNum, &davect, 0);
if (!(pProj->workslike & PROJECTILE_FORCEIMPACT))
{
A_DeleteSprite(spriteNum);
return;
}
}
```
Note that in the following: `actor[otherSprite].owner == htowner`, `actor[otherSprite].picnum == htpicnum` and `actor[otherSprite].extra == htextra`.
Notice that `A_DamageObject()` handles projectile damage and calls both `EVENT_DAMAGESPRITE` as well as `EVENT_POSTDAMAGESPRITE` respectively at the start and the end of the function. The former event is supposed to be executed before the damage is added to the `htextra` struct member (and also, before `htowner` and `htpicnum` are set), while the latter event is supposed to be executed after these members have been updated.
The above block of code however is executed for any custom projectile that has the `PROJECTILE_RPG_IMPACT` flag, and breaks the assumptions made for `EVENT_POSTDAMAGESPRITE`. Namely, the `htowner` as well as `htpicnum` members are updated a second time, thus preventing them from being changed inside `EVENT_POSTDAMAGESPRITE`, and if the flag `PROJECTILE_RPG_IMPACT_DAMAGE` is also given, then the damage is incremented after the event, meaning that `EVENT_POSTDAMAGESPRITE` does not have access to the full damage the projectile does to the enemy.
As a result, this block of code bypasses any changes made to the overall damage in `EVENT_DAMAGESPRITE`. For example, if we tried to code different damage resistances for certain enemy types, `PROJECTILE_RPG_IMPACT_DAMAGE` would bypass this resistance and apply the full damage, regardless of what is done in the CON code.
However, if we were to reorder this code such that `A_DamageObject()` is executed only after the `PROJECTILE_RPG_IMPACT` block, then we break the assumption about `EVENT_DAMAGESPRITE` instead, as some damage has already been added to `htextra`.https://voidpoint.io/terminx/eduke32/-/issues/133Duke3D: Shrinker projectile cannot enter spaces it previously fit into2023-05-21T13:37:44-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Shrinker projectile cannot enter spaces it previously fit intoThis is another one of those edge-cases that are unusually common with Duke usermaps.
In a 3-episode mod called FM4X, there is a shrinker puzzle that reflects shrinker projectiles in a ring. The passages these projectiles have to enter ...This is another one of those edge-cases that are unusually common with Duke usermaps.
In a 3-episode mod called FM4X, there is a shrinker puzzle that reflects shrinker projectiles in a ring. The passages these projectiles have to enter are quite small, and starting from commit r7461 (48d1db93) the projectiles hit the wall instead of passing through.
Note that r7461 is a bugfix on commit r7409.
The location in question where projectiles are failing to pass through:
![duke0000](/uploads/5ddd84293f2205e6a710a88fd427b11b/duke0000.png)
Map excerpt:
[shrinkersprite_collision.map](/uploads/aac0c72f543e49cceddc6fd3462dbf22/shrinkersprite_collision.map)https://voidpoint.io/terminx/eduke32/-/issues/126Mapster32/Polymost: Texture (DEF) tiles can cause the 3D Mode rendering to fr...2023-05-21T13:37:25-07:00Dino Bollingerdino.bollinger@gmail.comMapster32/Polymost: Texture (DEF) tiles can cause the 3D Mode rendering to freak outWhile in Polymost mode, if you go into 3D mode while viewing a glowtile, then the next time you enter 3D mode the textures will freak out, see the video.
https://www.youtube.com/watch?v=ai5IYEAwJuQ&feature=youtu.be
When you then re-ent...While in Polymost mode, if you go into 3D mode while viewing a glowtile, then the next time you enter 3D mode the textures will freak out, see the video.
https://www.youtube.com/watch?v=ai5IYEAwJuQ&feature=youtu.be
When you then re-enter 3D mode after not having viewed a glowmap, the textures return back to normal.
The following zip defines glowmaps for the Octabrain actor and can be used to test this bug: [octabrain_glowtiles.zip](/terminx/eduke32/uploads/f754b15e607fc4fa2922e459c8f94b4c/octabrain_glowtiles.zip)https://voidpoint.io/terminx/eduke32/-/issues/125Engine: Texture (DEF) glowmap transparency is rendered as a blue box on initi...2023-05-21T13:36:55-07:00Dino Bollingerdino.bollinger@gmail.comEngine: Texture (DEF) glowmap transparency is rendered as a blue box on initial loadUsing the DEF command `texture`, one can define a glowmap for sprites. When these are loaded in for the first time, there is a noticeable blue square that is very briefly visible. On closer analysis, the blue parts are rendered where the...Using the DEF command `texture`, one can define a glowmap for sprites. When these are loaded in for the first time, there is a noticeable blue square that is very briefly visible. On closer analysis, the blue parts are rendered where there is supposed to be transparency. Example:
![glowtile_bug01](/uploads/d7fd9b390e80ee2999da859cccb92b32/glowtile_bug01.PNG)
The following zip defines glowmaps for the Octabrain actor and can be used to test this bug: [octabrain_glowtiles.zip](/terminx/eduke32/uploads/f754b15e607fc4fa2922e459c8f94b4c/octabrain_glowtiles.zip)