[FistMarine]

Hi, I have found a couple of bugs in the latest EDuke32 versions:

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).

[Hendricks266]

#2 happens after loading a save and also prevents typing in the console. I just haven't tracked down the specific cause yet.

[FistMarine]

Yes, you are right. I completely forgot that I also loaded save to check again the level stats and indeed it caused the glitch. Hopefully the issues will get fixed.

[FistMarine]

Bump! Recently I have seen some issues being fixed and I figured out I would bump my old topic about some bugs I reported in past that still weren't fixed.

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.

[deuxsonic]

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.

[LeoD]

deuxsonic, on 05 June 2016 - 10:31 AM, said:

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.

There are not enough people who report their issues instead getting accustomed to them.
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.

[Hendricks266]

deuxsonic, on 05 June 2016 - 10:31 AM, said:

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.

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?

[deuxsonic]

Yes. I just ran through e1l1 and it didn't happen. I'll have to keep watch and try to remember what sequence of events causes it.

[FistMarine]

I could try some more testing to reproduce the chaingun bug but I'm busy these weeks, so it will have to wait.

[Mark]

Another problem that I think happened at or around the same time as the normal,spec and glow map bug, about 5400, was that animated sprite tiles 777 and 3421 will animate in Mapster but not in the game. There may be more affected but those are the only 2 I am using in my map right now. The latest version of Eduke has the problem too. I just double checked and it happens in Polymer but not Polymost.

[Hendricks266]

I've been looking at that and haven't found the cause yet. Bisecting will probably be the easiest way.

[Mark]

The animation problem started in 5491. While testing all the versions to track it down I also noticed slight changes in the color and intensity of the light cast by flames. But I'm not worried about that now because the latest version has them right.

[Hendricks266]

Found the problem. The fix will be in my next push.

[Mark]

cool beans

[Paul B]

Well it is disappointing, but i thought i'd try the latest synthesis. Not usable for me so I'm sticking with the tried and true r4249. But here is my latest crash dump which practically happened immediately upon drawing a sector in the 2d mode using r5771 Mapster (full screen mode). I always run in full screen mode never had problems like this before. However, I am running Windows 10 now and before I was running Windows 7. I did try using compatibility Mode Windows 7 and run as administrator as well as disabling Aero in Windows 10 still no such luck.

*** 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 thumbnail(s)

• 
• 
• 
• 

Attached File(s)

•  mapster32.crash.log (4.7K)
  Number of downloads: 314
•  mapster32.log (739bytes)
  Number of downloads: 316

[Mark]

For my first few years of mapping I and lots of others had crashes when trying to use Mapster in full screen. But maybe 6 months or more ago I gave it a try once again. Its been fine for me. But I'm running a system way different than yours. I'm in Vista with Nvidia

[Hank]

Using 5771 under Win 7, mapster32 runs like smooth. It may be specific to Windows 10?

[Paul B]

Hank, on 08 June 2016 - 06:30 PM, said:

Using 5771 under Win 7, mapster32 runs like smooth. It may be specific to Windows 10?

Well I don't think it is specific to Windows 10 as the previous version of Mapster R4249 runs just fine with Windows 10.

[Hendricks266]

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

I can reproduce this crash by drawing a sector and then dragging one of the sector a verticies to a new location.

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?

[Paul B]

Hendricks266, on 08 June 2016 - 10:17 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?

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

[Hendricks266]

What is the filesize and md5sum of your duke3d.grp?

[FistMarine]

Alright, I've got some free time and I can reproduce the chaingun bug again. Here's how to do it step by step:
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.

[icecoldduke]

FistMarine, on 10 June 2016 - 07:04 AM, said:

Alright, I've got some free time and I can reproduce the chaingun bug again. Here's how to do it step by step:
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.

duke0000.png

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 .

[FistMarine]

Thanks! Hope it will get fixed soon. In the meantime I will try to find more bugs.

[Paul B]

Hendricks266, on 09 June 2016 - 11:10 PM, said:

What is the filesize and md5sum of your duke3d.grp?

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. =)

[Hendricks266]

Well there goes that theory (modified PALETTE.DAT with invalid translucency table). Your GRP matches v1.5.

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.

[Hendricks266]

I figured out how to reproduce the issue: position the cursor on the inside of the sector when you click to drag a vertex.

[Paul B]

Hendricks266, on 13 June 2016 - 04:59 PM, said:

I figured out how to reproduce the issue: position the cursor on the inside of the sector when you click to drag a vertex.

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.

*** One thing I neglected to mention *** I am not sure if this is part of the problem or not. But my computer has two keyboards and mice hooked up to it. While I dont use both at the same time =P One set is down by my computer, the other set runs upstairs to a USB hub so depending on where I am sitting I can use my computer either at my desk or in my TV room. I'll try disconnecting the other inputs to see if this has any impact. This makes no difference.

[Hendricks266]

Found the problem.

[Paul B]

Hendricks266, on 13 June 2016 - 09:08 PM, said:

Found the problem.

You never cease to amaze me! Thanks!