![](https://forums.duke4.net/public/style_images/cgs/_custom/switch.png)
Some bugs I found
#1 Posted 06 August 2015 - 01:44 AM
1) Trying to increase brightness using keyboard arrows doesn't work anymore, it can only be done using mouse cursor. Decreasing brightness using left arrow still works, however.
2) When you end a level, the spacebar seems to randomly break and not correspond anymore. To skip the level end stats (and in case of ending an user map, the intro logos as well), you have to press ENTER or other keys that still work fine. Using cheat codes also seems to break stuff and make game act weird, with some keys not working anymore (space bar seems to be most affected).
#2 Posted 06 August 2015 - 05:16 AM
#3 Posted 06 August 2015 - 06:58 AM
#4 Posted 05 June 2016 - 09:17 AM
1) Sliders bug
The arrow keys don't seem to always work on the color correction screen. Sometimes I can adjust the gamma and brightness just fine but other times, I can't change them at all. For example I try to change gamma up to 4.00 using right arrow key, then if I use left arrow key to change back, it only lets me to change to 3.10 and it stops. Using the mouse works fine. This bug (also mentioned in first post) seems to be around since quite some time.
2) Pixelated death screen
An issue that got first introduced in r4935 and still persists in latest build. The issue seems to occur in software render and can be easily seen in 640x480 resolution. What happens is if you die, the screen looks very pixelated but it's not supposed to look like that. Here is an old screenshot I made (when I played TamDuke) that shows this bug:
3) Chaingun switch bug
Another long-standing bug, this seems to happen when using the Chaingun and running out of ammo. Instead of switching to another weapon, you are left with Chaingun still in hand. This can be a big problem when this happens right in middle of a battle.
This is all I have for now.
EDIT: Seems like someone else also had the problem with sliders back in 2014:
https://forums.linux...ic.php?t=166634
So that means the slider bug has been around since 2 years.
This post has been edited by FistMarine: 05 June 2016 - 09:20 AM
#5 Posted 05 June 2016 - 10:31 AM
FistMarine, on 05 June 2016 - 09:17 AM, said:
3) Chaingun switch bug
Another long-standing bug, this seems to happen when using the Chaingun and running out of ammo. Instead of switching to another weapon, you are left with Chaingun still in hand. This can be a big problem when this happens right in middle of a battle.
I noticed the chaingun cannon bug as well where it should be switching when it runs out of ammo, but I didn't know if it was already known about since it is something that potentially comes up a lot.
#6 Posted 05 June 2016 - 10:49 AM
deuxsonic, on 05 June 2016 - 10:31 AM, said:
![:)](https://forums.duke4.net/public/style_emoticons/default/sad.gif)
Once you've found your way from here to here, and follow the instructions, every bug report is [should be] welcome with not much risk of getting flamed.
This post has been edited by LeoD: 05 June 2016 - 10:57 AM
#7 Posted 05 June 2016 - 12:28 PM
deuxsonic, on 05 June 2016 - 10:31 AM, said:
Could you provide some instructions to reproduce this problem? I just tested and running out of ammo autoswitched me away from the chaingun.
You do have autoswitching on empty enabled, right?
#8 Posted 05 June 2016 - 09:58 PM
#9 Posted 06 June 2016 - 12:56 AM
![:)](https://forums.duke4.net/public/style_emoticons/default/confused.gif)
#10 Posted 08 June 2016 - 10:59 AM
This post has been edited by Mark.: 08 June 2016 - 11:05 AM
#11 Posted 08 June 2016 - 12:59 PM
#12 Posted 08 June 2016 - 02:09 PM
#15 Posted 08 June 2016 - 05:33 PM
*** UPDATE *** This crash has nothing to do with Full screen mode though. I can reproduce this crash by drawing a sector and then dragging one of the sectors verticies to a new location. Crash! 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.
****UPDATED **** This crash only appears to occur in the mapster32.debug.exe. It doesn't occur in mapster32.exe. I have no idea why that would make any difference?
Attached File(s)
-
mapster32.crash.log (4.7K)
Number of downloads: 283 -
mapster32.log (739bytes)
Number of downloads: 287
This post has been edited by Paul B: 09 June 2016 - 08:40 AM
#16 Posted 08 June 2016 - 05:51 PM
This post has been edited by Mark.: 08 June 2016 - 05:55 PM
#17 Posted 08 June 2016 - 06:30 PM
#18 Posted 08 June 2016 - 06:33 PM
Hank, on 08 June 2016 - 06:30 PM, said:
Well I don't think it is specific to Windows 10 as the previous version of Mapster R4249 runs just fine with Windows 10.
This post has been edited by Paul B: 08 June 2016 - 06:37 PM
#19 Posted 08 June 2016 - 10:17 PM
Paul B, on 08 June 2016 - 05:33 PM, said:
Does this happen with any sector you create, or only some sectors? If the latter, could you attach a map here that causes it?
Does the problem persist if you move all your cfg files to another folder temporarily?
Found no recognized game data! Using "DUKE3D.GRP" as main game data file.
This line in your log stands out too. Does using an unmodified GRP affect the issue?
#20 Posted 09 June 2016 - 03:42 PM
Hendricks266, on 08 June 2016 - 10:17 PM, said:
Does the problem persist if you move all your cfg files to another folder temporarily?
Found no recognized game data! Using "DUKE3D.GRP" as main game data file.
This line in your log stands out too. Does using an unmodified GRP affect the issue?
Took me a while to finally get home to try this. This happens on any new map where I create a sector then attempt to re-size the sector after I have just created it. It also occurs even when I remove all cfg files from the EDuke folder. However, it doesn't appear to occur with the non debug version of Mapster. The problem is specific to mapster32.debug.exe
This post has been edited by Paul B: 09 June 2016 - 03:43 PM
#22 Posted 10 June 2016 - 07:04 AM
1) Get a chaingun, preferably with a console command or make a small map that contains only a chaingun
2) Fire until you have few bullets left (3 for example, to be as close to 1 as possible)
3) Now fire a single bullet at a time until you will empty the ammo.
4) Chaingun will remain in hand.
The bug doesn't seem to happen when holding down the fire button, it will autoswitch normally. It seems the bug only works when you fire a bullet at a time.
EDIT: I forgot to mention but the map in the screenshot above is something I created in a few seconds for testing bugs.
This post has been edited by FistMarine: 10 June 2016 - 11:00 AM
#23 Posted 10 June 2016 - 07:05 AM
FistMarine, on 10 June 2016 - 07:04 AM, said:
1) Get a chaingun, preferably with a console command or make a small map that contains only a chaingun
2) Fire until you have few bullets left (3 for example, to be as close to 1 as possible)
3) Now fire a single bullet at a time until you will empty the ammo.
4) Chaingun will remain in hand.
![Attachment](https://forums.duke4.net/public/style_images/cgs/attachicon.gif)
The bug doesn't seem to happen when holding down the fire button, it will autoswitch normally. It seems the bug only works when you fire a bullet at a time.
Now that's a bug report
![:)](https://forums.duke4.net/public/style_emoticons/default/smile.gif)
#24 Posted 10 June 2016 - 07:09 AM
![:)](https://forums.duke4.net/public/style_emoticons/default/smile.gif)
#25 Posted 10 June 2016 - 09:24 PM
Hendricks266, on 09 June 2016 - 11:10 PM, said:
I've never really needed to run this tool before, but it's kind of neat. If anyone else is wondering where to find this tool I've downloaded the utility from here: https://support.micr...en-us/kb/841290
E:\dosgames\duke32\duke3d.grp
MD5 Checksum: 22b6938fe767e5cc57d1fe13080cd522
SHA-1: 4fdef8559e2d35b1727fe92f021df9c148cf696c
DUKE3D.GRP File Size: 44,356,548 Bytes
This should be the Atomic 1.5 Version of the Duke GRP. I can't remember which one I bought I'm pretty sure it's Atomic though. It's only been 20 years, crazy how the time just flies when you're having fun. =)
This post has been edited by Paul B: 10 June 2016 - 09:42 PM
#26 Posted 10 June 2016 - 09:48 PM
I'm at a loss for what is happening, and I feel like the only way to figure out what the problem is would be to make the backtrace DLL print more information. I'll get back to you.
#27 Posted 13 June 2016 - 04:59 PM
#28 Posted 13 June 2016 - 08:57 PM
Hendricks266, on 13 June 2016 - 04:59 PM, said:
That's interesting, I did play with it some more in light of this information. However, while at first it appeared to work when I kept the cursor within the sector before I dragged it, then after a few times of moving verticies around it still crashed the same way regardless if i was in or outside the sector. Again this only appears to occur in the debug version. Whatever the problem may be I can reproduce the problem 99.5 percent of the time when dragging a verticy.
This post has been edited by Paul B: 13 June 2016 - 09:13 PM
#30 Posted 13 June 2016 - 09:15 PM
Hendricks266, on 13 June 2016 - 09:08 PM, said:
You never cease to amaze me! Thanks!
This post has been edited by Paul B: 13 June 2016 - 09:16 PM