[Hendricks266]

Fix committed.

[FistMarine]

Could you also look into the bugs I reported, please?

[deuxsonic]

I've noticed that the crystal in the shrinker/expander doesn't strobe with Polymer if art mapping is disabled. Is there another way around this? The ATOMIC on the main menu logo strobes fine in this situation.

[Hendricks266]

FistMarine, on 05 June 2016 - 09:17 AM, said:

1) Sliders bug

As I've mentioned the previous dozen times you've reported this to me, I can't reproduce the problem so I can't figure out what is wrong. At most I can look at the code that handles these sliders and make guesses.

FistMarine, on 05 June 2016 - 09:17 AM, said:

2) Pixelated death screen

This isn't a bug, though TX and I agree it is undesirable.

http://svn.eduke32.com/comp.php?repname=eduke32&compare[]=/polymer/eduke32/ source/game.c@4934&compare[]=/polymer/eduke32/source/game.c@4935

To save memory on Android, we changed the way some of the engine's data structures are managed so that they only take up as much space as they need at the time, instead of always taking up the maximum. The game-side tilt screen code depended on having extra space to work with.

Fortunately, in normal play you don't spend much time dead or pressing Look Left or Look Right.

FistMarine, on 05 June 2016 - 09:17 AM, said:

3) Chaingun switch bug

This is near the top of my list, thanks to your excellent bug report and the problem being a simple one.

[FistMarine]

Hendricks266, on 16 June 2016 - 07:51 PM, said:

As I've mentioned the previous dozen times you've reported this to me, I can't reproduce the problem so I can't figure out what is wrong. At most I can look at the code that handles these sliders and make guesses.

Well, if you use the arrow keys to move the slider left and right, it doesn't work at certain times and it gets stuck, so you can't move slider at all. It only works properly with the mouse, you can set any value you want. Just with the arrow keys it doesn't work right.

Hendricks266, on 16 June 2016 - 07:51 PM, said:

This isn't a bug, though TX and I agree it is undesirable.

http://svn.eduke32.com/comp.php?repname=eduke32&compare[]=/polymer/eduke32/ source/game.c@4934&compare[]=/polymer/eduke32/source/game.c@4935

To save memory on Android, we changed the way some of the engine's data structures are managed so that they only take up as much space as they need at the time, instead of always taking up the maximum. The game-side tilt screen code depended on having extra space to work with.

Fortunately, in normal play you don't spend much time dead or pressing Look Left or Look Right.

I understand now.

Hendricks266, on 16 June 2016 - 07:51 PM, said:

This is near the top of my list, thanks to your excellent bug report and the problem being a simple one.

No problem. I'm glad I could be helpful. It was easy to reproduce the bug.

Anyways, I also found out few other minor menu issues but I will report them next week after I finish with my last 2 exams.

[filipetolhuizen]

Don't know if anyone noticed this, but most textures which hide a secret or translucent, such as glass or force field are now appearing cut in half most of the times with the lower left of them missing.
EDIT: Sorry, it has already been reported here: https://forums.duke4...act-weird-pics/

[Nukey]

I've got one:

1) Open any map with >= 2 corruptions
2) Open the console and type "corruptcheck tryfix 1"

It will fix corruption 1, but then it will also fix corruption 2 without being asked.

Any value > 1 works as expected, only 1 seems to have this problem.

[FistMarine]

Found another menu related bug:





It can be reproduced by holding the forward button and at same time pressing ESC button to bring up the main menu. To make all options appear, just move the down arrow key. After that, you can't reproduce the bug again, unless you delete the config file.

[Paul B]

I would just like to bring attention to my post in https://forums.duke4...te/#entry254126 which demonstrates a glitch with pivoting S.E's. I have a sample map showing a functional set of Gears and another set of Gears which are identical but not working correctly in the same map. I believe this surfaces an issue somewhere buried in the code. I hope this map can assist in providing a fix.

Thanks.

[FistMarine]

Has the menu bug been looked at? I just found out while playing DukePlus that the bug also happens with other menus.

https://forums.duke4...post__p__255098
Screenshots:





It can be reproduced the same way: Hold "move forward" button and at same time, press either F2, F3, F4 or F11 keys to access a menu. You will get a glitched menu.

[FistMarine]

Some bugs reported in other topic:

-Music doesn't play correctly
-Autoaim is broken

Other bugs that still persist in latest build:

1) Slider bug. The bug was partially fixed, I can move the slider to the right fine but to the left it stops at random values such as 2.10 (gamma in Color Correction menu). After that you must use mouse to change the value or it gets stuck here.

2) Spaces in Configure Keys. When you go to change your controls, you will see some commands have nothing at all defined. You can use DEL key to delete the command and then it will show fine as line instead of space. Before the bug was introduced, non defined commands always showed as - but now they show as nothing at all.

[Mblackwell]

Autoaim in was fixed last night and should be in the newest build.

I tried to bisect the music issue but it's a Windows only bug apparently. Henricks and TX will have to figure it out!

[FistMarine]

Good that autoaim bug was fixed. Tried out latest build r5854 and autoaim works properly again!

Anyway here are screenshots about the spaces in Configure Keys that I meant earlier:




First screenshot shows an empty space assigned on fire button. On second screenshot I deleted the empty space with the DEL key and it shows a line as intended. I remember this got introduced last year but I can't remember when.

[Mblackwell]

Just noting this here so I don't forget:
I found a rendering bug in the Classic Renderer (in vanilla duke) where certain sprites (explosions, smallsmoke, fire, etc) render in front of every other sprite. This is caused by changes in revision 5723. (I bisected it last night)

[Danukem]

Mblackwell, on 06 September 2016 - 08:57 AM, said:

Just noting this here so I don't forget:
I found a rendering bug in the Classic Renderer (in vanilla duke) where certain sprites (explosions, smallsmoke, fire, etc) render in front of every other sprite. This is caused by changes in revision 5723. (I bisected it last night)

Are you sure it's just classic? Some of us have been complaining about a similar (maybe identical) issue in all renderers for quite a while now. I've actually gone back and removed smoke effects from several of my mods because of it -- the smoke and other effects will completely block view of sprites behind it even when transparent.

[Danukem]

@FistMarine: Can you confirm whether the level progression bug reported here still exists? Thanks. EDIT: Goddamnit that sounded like an officespace thanks but it wasn't intended that way.

[TerminX]

Level progression bug was already fixed.

[Mblackwell]

Trooper Dan, on 06 September 2016 - 10:58 AM, said:

Are you sure it's just classic? Some of us have been complaining about a similar (maybe identical) issue in all renderers for quite a while now. I've actually gone back and removed smoke effects from several of my mods because of it -- the smoke and other effects will completely block view of sprites behind it even when transparent.

I could not reproduce it in Polymost. Quickest test is to boot up E1L1 and the flames from the ship crash will be in front of the fence.

There was a bug previously where transparent objects would get drawn in front of EVERYTHING in all renderers but I believe that was fixed a few months ago.

[Mark]

its a problem in Polymer also. I have a tunnel model in front of a brick wall sector. In front of the tunnel I have a flame sprite. From certain angles the flame sprite's transparency allows the player to see through the tunnel model to the sector wall behind it. If I keep my smoke or flame sprites smaller and lower to the ground the glitch is far less noticable. Thats been my workaround so far.

[Mblackwell]

That sounds like a different issue where the game can't properly draw objects BEHIND an alpha transparency when there's any intersection. Happens in polymost too. What the bug here is sprite objects being forcefully drawn in front of other sprite objects. Transparency itself doesn't get mucked up.

[Hendricks266]

Mblackwell, on 06 September 2016 - 08:57 AM, said:

Just noting this here so I don't forget:
I found a rendering bug in the Classic Renderer (in vanilla duke) where certain sprites (explosions, smallsmoke, fire, etc) render in front of every other sprite. This is caused by changes in revision 5723. (I bisected it last night)

Fixed in r5857.

Trooper Dan, on 06 September 2016 - 10:58 AM, said:

Are you sure it's just classic? Some of us have been complaining about a similar (maybe identical) issue in all renderers for quite a while now. I've actually gone back and removed smoke effects from several of my mods because of it -- the smoke and other effects will completely block view of sprites behind it even when transparent.

In r5400, we added cstat 1024 so that the Duke 64 explosion wouldn't look like shit. TX decided to automatically enable this bit for LASERLINE, EXPLOSION2, EXPLOSION2BOT, FREEZEBLAST, ATOMICHEALTH, FIRELASER, SHRINKSPARK, GROWSPARK, CHAINGUN, SHRINKEREXPLOSION, RPG, FLOORFLAME, FIRE, FIRE2, BURNING, BURNING2, SMALLSMOKE, and COOLEXPLOSION1. This may be what you are experiencing.

[Danukem]

Hendricks266, on 08 September 2016 - 07:22 PM, said:

In r5400, we added cstat 1024 so that the Duke 64 explosion wouldn't look like shit. TX decided to automatically enable this bit for LASERLINE, EXPLOSION2, EXPLOSION2BOT, FREEZEBLAST, ATOMICHEALTH, FIRELASER, SHRINKSPARK, GROWSPARK, CHAINGUN, SHRINKEREXPLOSION, RPG, FLOORFLAME, FIRE, FIRE2, BURNING, BURNING2, SMALLSMOKE, and COOLEXPLOSION1. This may be what you are experiencing.

I don't think so, since all the examples I can think of involve my own custom actors and not any of the ones you listed.

[FistMarine]

I found another minor bug a few days ago and I got reminded of it recently. When you die with kick selected, sometimes you drop the kick. I'm pretty sure this bug got introduced recently since I never remember happening before, definitely not in the original DOS version.

To reproduce, I recommend to get gibbed while holding kick (so that the Duke's body doesn't overlap with the dropped kick) and then turn on View Mode. You will see the kick sprite very small floating in air.

EDIT: Screenshot of the dropped kick bug in a map I designed in few minutes, with an automatic shooter that shoots RPG at you

[Paul B]

I have just noticed that if Duke is on a Sprite floor above a water sector that has a lowtag of 1 even though Duke is not in the water because he's on the sprites above it still makes the water sound effect as if he was walking through water. Noticed especially when ducking on sprites above a water sector. (R4249) I can confirm this also occurs using the latest build (20160917-5875) The water sound seems to occur only when entering the sector with the lowtag of 1. Once in the sector it doesn't appear to make further water sounds until you leave the sector and head back in again.

[Captain Massive]

Cant sort sounds F2 with capslock on.

This bugged me for ages and could not figure out why I could not sort sounds, I was rebooting and trying all kinds of things, untill 1 day it dawned on me to try capslock.

Sound's 386 & 388 missing from sound list as well.

r5875

[FistMarine]

I found another minor bug sometime ago but I got reminded of it recently. Basically if you shrink a mini battlelord and wait him to return to normal size, he will lose the collision, meaning he becomes difficult to hit. I don't remember this bug happening in the original game but I know that the mini battlelord acts weird after returning to normal size, until enters his pain state and resumes attacking you.

[Darkus]

FistMarine, on 08 October 2016 - 07:17 AM, said:

Basically if you shrink a mini battlelord and wait him to return to normal size, he will lose the collision, meaning he becomes difficult to hit. I don't remember this bug happening in the original game but I know that the mini battlelord acts weird after returning to normal size, until enters his pain state and resumes attacking you.

It was in the original game and this happens to the Octabrain too.

You should check this: https://forums.duke4...?showtopic=8946

[FistMarine]

Darkus, on 10 October 2016 - 12:40 PM, said:

It was in the original game and this happens to the Octabrain too.

You should check this: https://forums.duke4...?showtopic=8946

I knew about Mini Battlelord and Octabrain acting weird after returning to normal size but I thought that the non-existent collision of Mini Battlelord only happens in EDuke32.

[Hendricks266]

I haven't forgotten about the chaingun bug.

Paul B, on 08 June 2016 - 05:33 PM, said:

R4249 never had this problem it also doesn't have the redish fog of war as well. Just to put things in perspective I tried to capture how bad the new version is when compared to R4249. Unfortunately, it was extremely difficult to capture the Redish hue of the screen in a picture. But its at least 10 times worse then the picture shows.

Do the latest builds still have the red fog of war?

[FistMarine]

Hendricks266, on 24 October 2016 - 06:55 PM, said:

I haven't forgotten about the chaingun bug.

Good to know that you are going to fix the chaingun bug and hopefully the others I reported too.