[Mike Norvak]

I had a crash while playing Metropolitan Mayhem at the end of Meatball Sub makin', I don't think is a bug related with that map, so I posted here.

The crash log:

Spoiler

Failed to init bfd from (C:\Windows\system32\msvcrt.dll): 1 1 0
0x76a98dbd : C:\Windows\system32\msvcrt.dll : strcat
0x42a303 : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : Z:\var\www\synthesis\eduke32\eduke32/source/game.c (11329) : in function (G_BonusScreen)
0x42526a : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : Z:\var\www\synthesis\eduke32\eduke32/source/game.c (9656) : in function (G_EndOfLevel)
0x427157 : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : Z:\var\www\synthesis\eduke32\eduke32/source/game.c (10592) : in function (app_main)
0x56c7e6 : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : Z:\var\www\synthesis\eduke32\eduke32\build/src/winlayer. c (500) : in function (WinMain@16)
0x5f0af6 : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : main.c
0x4010db : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : crt1.c
0x401158 : D:\DUKE NUKEM\EDUKE 32 - VANILLA\eduke32.debug.exe : crt1.c
Failed to init bfd from (C:\Windows\system32\kernel32.dll): 1 1 0
0x76861194 : C:\Windows\system32\kernel32.dll : BaseThreadInitThunk
Failed to init bfd from (C:\Windows\SYSTEM32\ntdll.dll): 1 1 0
0x7744b495 : C:\Windows\SYSTEM32\ntdll.dll : RtlInitializeExceptionChain
Failed to init bfd from (C:\Windows\SYSTEM32\ntdll.dll): 1 1 0
0x7744b468 : C:\Windows\SYSTEM32\ntdll.dll : RtlInitializeExceptionChain
Tue Mar 06 20:56:56 2012

EDIT: And every time I reload the saved game, it crashes again....

[LeoD]

Norvak, on 06 March 2012 - 07:03 PM, said:

I had a crash while playing Metropolitan Mayhem at the end of Meatball Sub makin', I don't think is a bug related with that map, so I posted here.
EDIT: And every time I reload the saved game, it crashes again....

Did you change the CON file? I got some pretty similar crashes and crashlogs when fiddling with the CON to make it DukePlus/HRP compatible. (I moved the episode from 5 to 2.)

Hendricks266, on 04 March 2012 - 11:35 PM, said:

A "version" command for mods is completely unnecessary, but I added "echo".

I'm mostly interested to have this in DEF files. The Polymer HRP ZIPs for example come without version info in the filename. The only way to tell the actual version is to ask the logfile's uploader.

[Helixhorned]

There's progress concerning the sound issues that have plagued people lately.

In IRC, Hendricks mentioned that current EDuke32 versions don't play all explosion sounds from the destructible building sequence in E1L2. This inspired me to bisect the synthesis builds, and indeed, reverting the following change of r1601 will make it sound like before again:

     if (g_sounds[num].num > 0 && PN != MUSICANDSFX)
-    {
-        if (g_sounds[num].SoundOwner[0].i == i) S_StopSound(num);
-        else if (g_sounds[num].num > 1) S_StopSound(num);
-        else if (A_CheckEnemySprite(&sprite[i]) && sprite[i].extra <= 0) S_StopSound(num);
-    }
+        S_StopEnvSound(num, i);

However, this does not fix the abrupt sound cutoffs that can be reproduced by e.g. kicking against a wall in WGR2. By chance (and thanks to Micky's WGR2 map), I found an easy way of producing a very strange sonic inconsistency, a test map for which is attached with this post. Just fire an RPG into the distance, and then kick continuously againt the wall in front of you. Observe.

Now, the interesting thing is that it's been like this since version 1.3D! (But, as far as I can see, it wasn't present in v0.99).
I believe that it's this bug that is at the root of all the other sound cutoffs.

For the time being, I will not change the sound code because I'm not knowledgeable enough about it: I don't fully understand the intent of the first change and I haven't got a solution for the second one, though it'll probably be sensible to start at S_Update() and see about how sounds are associated with sprite IDs.

EDIT: ...And it's all clear. Woe to sounds that outlive their owning sprites . This is a big issue.

Attached File(s)

•  SNDTEST.zip (396bytes)
  Number of downloads: 685

[Hendricks266]

Good work, Helix!

LeoD, on 07 March 2012 - 06:00 AM, said:

I'm mostly interested to have this in DEF files. The Polymer HRP ZIPs for example come without version info in the filename. The only way to tell the actual version is to ask the logfile's uploader.

Quote

---------------------------------------------------------------- --------
r2435 | hendricks266 | 2012-03-10 03:44:17 -0600 (Sat, 10 Mar 2012) | 2 lines

Add "echo" def parameter which prints a string to the console and log file.
Syntax: echo "Your text here."
------------------------------------------------------------------------

[LeoD]

Hendricks266, on 10 March 2012 - 02:15 PM, said:

r2435

Yeah, cool! Now the log file can look like this:

Loading 'dukeplus.def'
Duke Plus 2.30 [Z-pack]
High Resolution Pack 5.1.311+ Polymost override
SC-55 Music Pack 3.0 HQ
Z-Pack 5.1.WIP Polymost
Definitions file 'dukeplus.def' loaded.

EDIT: Now the last thing on my wishlist would be suppressing the dispensable warning messages about issues of the original GAME.CONs in the GRPs.

GAME.CON: In actor `ORGANTIC':
GAME.CON:3967: warning: found `else' with no `if'.
GAME.CON: In state `pigshootenemystate':
GAME.CON:5890: warning: found `else' with no `if'.

Chances are nil that this would mask out any problems in a user-created CON.

[Plagman]

I just fixed a pretty serious flaw with the Polymer model animation code, which would cause any animation that included frame 0 to look choppier than it should be. This fixes a number of problems with a lot of models in the HRP, but I'm not sure whether it fixes every problem that people have been copmlaining about lately. Please let me know if there are outstanding issues with this.

[Spiker]

Gonna check it in a moment.

That also reminds me that sometime in the future I need to:

- unify all hands on the HUD guns- especially pistol,
- undust my old shotgun and add new skins and proper fov,
- do the same for the pipebomb and trip mine (possible new models)
- model and animate muzzleflash planes for the chaingun

After this is done I was thinking about some optional pack. I could duplicate and scale up slightly the verticles from the hand and this would be new gloves that would be very easy to manage because they would be on a separate surface:)

Also what are your opinions about some idle gun animations? Probably most would not like like them but it could be interesting and shouldn't spoil the original feel if these were only slight movements. Just asking for opinions and I'm not saying I'm gonna do it.

[Tea Monster]

Spiker, If you need any help, PM me.

[Danukem]

Spiker, on 10 March 2012 - 11:40 PM, said:

Also what are your opinions about some idle gun animations? Probably most would not like like them but it could be interesting and shouldn't spoil the original feel if these were only slight movements. Just asking for opinions and I'm not saying I'm gonna do it.

That would require CON code to decide when to use them, and the new animations would need new tile numbers. Normally I would be happy to put something like that in DukePlus, but I'm not sure how that will work since players have the option of not using the HRP. I suppose it could be an option in the menu...the whole menu needs an overhaul anyway with a proper interface.

[Spiker]

Tea Monster, on 11 March 2012 - 06:48 AM, said:

Spiker, If you need any help, PM me.

Sure. For now I need nothing more than some time. Oh, wait where's the new Cycloid? You promissed me it for me birthday

Trooper Dan, on 11 March 2012 - 07:04 AM, said:

That would require CON code to decide when to use them, and the new animations would need new tile numbers. Normally I would be happy to put something like that in DukePlus, but I'm not sure how that will work since players have the option of not using the HRP. I suppose it could be an option in the menu...the whole menu needs an overhaul anyway with a proper interface.

I could be done without any modifications but this would mean it would play in a loop and every time you stop shooting it would start from the beginning. That's why it would have to be very subtle not to draw too much attention to the fact that it's repeated all over again.

[Danukem]

Spiker, on 11 March 2012 - 12:18 PM, said:

I could be done without any modifications but this would mean it would play in a loop and every time you stop shooting it would start from the beginning. That's why it would have to be very subtle not to draw too much attention to the fact that it's repeated all over again.

Even if it is subtle, it would get annoying to have it looping constantly. Besides, it would be more fun if he twirled his pistol and stuff like that.

[Helixhorned]

For some reason, the recent synthesis ChangeLog is empty. Here's the important change:

r2470 commit log said:

When deleting sprites, insert them at the tail (instead of head) of the freelist.

The major outside-visible change is that this fixes the sound cutoff bugs that
happened because newly-spawned sprites took the place of those whose sounds
had not yet finished playing.

Besides, there are these changes:
- remove deletesprite{sect,stat}
- we have a new engine variable 'tailspritefree' that keeps track of the
sprite freelist tail
- we need to store it in savegames and mapstates, so bump the savegame
minor version

[Danukem]

Will this change affect the IDs that are assigned to sprites when they spawn?

[Jblade]

Oh wow, the sound bug is fixed now? excellent work!

[Diaz]

Any chance this is getting fixed soon? Looks like an important bug, as it will make any map with wall aligned sprites look bad with Polymer

[Plagman]

Yeah, it's next on my list of small things to fix up when I have a minute.

[fgsfds]

Will you bring undo\redo back any time soon?

[Hendricks266]

I gave the Build tools a much-needed polishing.

Quote

r2457 | hendricks266 | 2012-03-11 23:47:49 -0500 (Sun, 11 Mar 2012) | 3 lines

Fix compiling the Build tools by:
- Adding $(EXESUFFIX) where it belongs in the Makefile.
- Eliminating a call to initprintf() from compat.c. This may not be ideal.
------------------------------------------------------------------------
r2458 | hendricks266 | 2012-03-11 23:48:42 -0500 (Sun, 11 Mar 2012) | 7 lines

More Build tools improvements:
- JFBuild ports: arttool, givedepth, and mkpalette
- All viable tools are now built when 'make utils' is invoked, not just some
- Revert "initprintf" hack of previous commit and replace it with "compat_tools.c"
- Move Bstrtolower from baselayer.c to compat.c
- Makefiles: Add start and finish messages for the tools
- Makefiles: To prevent "-Wimplicit" from being passed to the C++ compiler, create $(*CONLYFLAGS)
------------------------------------------------------------------------
r2472 | hendricks266 | 2012-03-14 01:24:03 -0500 (Wed, 14 Mar 2012) | 1 line

Fix all warnings in the Build tools for both GCC and Clang.
------------------------------------------------------------------------
r2473 | hendricks266 | 2012-03-14 01:25:26 -0500 (Wed, 14 Mar 2012) | 1 line

Build tools: Whitespace cleanup and tab stop replacement.
------------------------------------------------------------------------
r2474 | hendricks266 | 2012-03-14 01:26:29 -0500 (Wed, 14 Mar 2012) | 1 line

Buildtools: More Makefile changes, including bringing Makefile.msvc up to date.
------------------------------------------------------------------------
r2475 | hendricks266 | 2012-03-14 01:27:06 -0500 (Wed, 14 Mar 2012) | 1 line

Buildtools: Fix warnings in enumdisplay.c only revealed with the previous Makefile edits.
------------------------------------------------------------------------
r2476 | hendricks266 | 2012-03-14 01:27:45 -0500 (Wed, 14 Mar 2012) | 4 lines

osxbuild.sh: new "tools" parameter builds the Build tools in addition to the full binaries
Makefiles: new features to facilitate above:
- buildtools: "make printutils" is a phony which simply lists all the tools
- $(EXESUFFIX_OVERRIDE)

Here are brand new builds of all the build tools:

http://hendricks266....dtools_r2476.7z

• The debug builds are probably unnecessary but since it was a simple to compile them I went ahead with it. If somehow you get a crash, these are only useful if you can use GDB.
  
• enumdisplay is not built by default with the rest of the tools because it is Windows-only and you have to specify the DirectX headers like the main build. To build it, in "build/" type "make enumdisplay.exe".
  
• arttool is a rather nifty little thing that went unnoticed in the JFBuild source for some time. Check it out.

[Helixhorned]

Trooper Dan, on 13 March 2012 - 01:52 PM, said:

Will this change affect the IDs that are assigned to sprites when they spawn?

Yes, with this change, the most recently deleted sprite number will be reused after all others, instead of being the number for the next inserted one. There should be no regressions with well-behaved code.

nogames, on 13 March 2012 - 08:12 PM, said:

Will you bring undo\redo back any time soon?

I honestly don't know. Besides finding the corruption bug, there's TROR support that needs to be added. But is it such a big deal? What's an example of an operation which is not easily reversible (either by editing or by reloading)?

edit: I looked into the source and TROR support is there. Sheesh.

[Danukem]

Helixhorned, on 14 March 2012 - 07:49 AM, said:

Yes, with this change, the most recently deleted sprite number will be reused after all others, instead of being the number for the next inserted one. There should be no regressions with well-behaved code.

Does that mean it will go through all the numbers up to 16383 before starting to reuse numbers? That's fine, but I'll have to change some of my code. In the past, I have assumed that very high sprite numbers are an indicator of a very large number of sprites actually being used, and that's a trigger for certain optimization routines.

It would be nice if there were a predefined, constantly updated var for numsprites, which would equal the total number of sprites in the map (similar to numwalls and numsectors). One problem with that is the same problem with it I face in CON: the number can change by a large amount in the same game tic, so to be useful the number of sprites has to be counted right before it is checked for anything.

[Helixhorned]

Trooper Dan, on 14 March 2012 - 08:06 AM, said:

Does that mean it will go through all the numbers up to 16383 before starting to reuse numbers?

Yep, exactly that.

Quote

It would be nice if there were a predefined, constantly updated var for numsprites, which would equal the total number of sprites in the map (similar to numwalls and numsectors). One problem with that is the same problem with it I face in CON: the number can change by a large amount in the same game tic, so to be useful the number of sprites has to be counted right before it is checked for anything.

That's a trivial tweak and should have been there right from the start. I'll throw it into one of the upcoming revisions.

[TerminX]

Helixhorned, on 14 March 2012 - 07:49 AM, said:

Besides finding the corruption bug, there's TROR support that needs to be added. But is it such a big deal? What's an example of an operation which is not easily reversible (either by editing or by reloading)?

Yes, having undo/redo is a big deal... people have asked about it several times. I'm not going to lie, it actually really pissed me off when you opted to just remove the functionality rather than repair it after bugs crept in. I declined to say anything about it before because I feel your high volume of quality work far outweighs having a few changes made that I don't necessarily agree with, but to say having undo/redo functionality isn't important when we're talking about an editing utility full of destructive operations is preposterous.

The bugs preventing undo/redo from working also probably affect the map state caching feature in EDuke32 and I think they're what's causing the roadblock I've run into in regards to multiplayer in my local branch (since they were all based on the same code at one point or another IIRC). I think it's a case of sprite list corruption (since in multiplayer I get lockups that look to be caused by nextspritestat iterating forever) but I haven't been able to put my finger on it. What really gets me is that the code in question originally started out as the code for saving and loading games, so it doesn't make much sense for things to be corrupting in that manner.

[Danukem]

Helixhorned, on 14 March 2012 - 07:49 AM, said:

What's an example of an operation which is not easily reversible (either by editing or by reloading)?

In my (admittedly limited) experience, the problem isn't so much that an operation is difficult to reverse by editing, it's that you don't know what the operation was. There have been cases where I just randomly pressed some key causing a change, and I can't reverse it because I don't know what I did. Or maybe I do know that I accidentally inserted a sprite, but I can't find it or isolate it. As for reloading, the obvious problem with that is that you lose the work you did since the last save.

[Helixhorned]

OK, undo/redo is enabled again in r2486. I did a couple of tests by taking a map, deleting a bunch of sectors and sprites, and then cycling back to revision 1 and forward again a couple of times without any problems. Nevertheless, that doesn't dispense one from the responsibility of keeping backups. (Should I need to have to say that?)

Did we really have disappearing sprites back then? This seems surreal now, because yesterday I fixed one of my mistakes* that had exactly the same effect, which of course couldn't have been the cause to the disappearences in the past times. What I think was happening that sprites that are really illegal to have (sectnum or statnum out of bounds) got saved in a revision, and when their reconstruction was attempted, the BUILD sprite lists got corrupted. I think that this shouldn't be happening now, though I didn't explicitly inject errors to verify this. Still, when encountering a level >=4 corruption, the correct course of action is to stop and try to get rid of it, instead of ignoring**.

* committed yesterday, too

** to be on the safe side, the map should then be saved under a different name and Mapster32 should be restarted, since the internal state might be corrupted.

[Spiker]

Just a reminder about the broken hipal thing. As it can be seen in this case it works only on the dead trooper and the color switch while it's dying is just too obvious.

[Spiker]

I found out that removing alt-skins fixes this problem. Considering this and the fact that there is a separate Polymost pack and soon most weapons will look bad in Polymost because of FOV change I'm thinking of removing alt-skins entirely! This would also reduce HRP size. Probably the same could be done for other models as well. If noone opposes that will some reasonable justification I'm going to do it tomorrow.

[Danukem]

Some of the alt-skins must have the wrong colors or wrong defs. With highpal, those should have been removed a long time ago.

[Tea Monster]

This isn't just a feature request, but I'm wondering how feasible it would be to give EDuke a rudimentary particle system. Just something that can spew billboards for use with fire, sparks and smoke.

[Plagman]

Trooper Tom, on 17 March 2012 - 12:38 PM, said:

I found out that removing alt-skins fixes this problem. Considering this and the fact that there is a separate Polymost pack and soon most weapons will look bad in Polymost because of FOV change I'm thinking of removing alt-skins entirely! This would also reduce HRP size. Probably the same could be done for other models as well. If noone opposes that will some reasonable justification I'm going to do it tomorrow.

Yeah, as I said on IRC alt-pals override highpal (as they should), so if there are any defined pals for the green live liztroop but none for the painskin, you'll see highpal kick in then. Highpal output should be visually validated before removing any alt-pal skin, cause glitches might happen. They should be moved to the polymost directories rather than simply removed, I think LeoD can help you with that since he came up with that design.

Tea Monster, on 17 March 2012 - 01:27 PM, said:

This isn't just a feature request, but I'm wondering how feasible it would be to give EDuke a rudimentary particle system. Just something that can spew billboards for use with fire, sparks and smoke.

It's feasible and planned, but in the end it should be integrated with the sprites system rather than just something bolted on the side. Eg. you should have a completely alternate class of sprites that's purely for display purposes, that bypasses most of the stuff that make sprites so slow, the sprite limit should be lifted, etc. But right now you can achieve the exact same thing with point sprites.

[Danukem]

Plagman, on 17 March 2012 - 01:41 PM, said:

It's feasible and planned, but in the end it should be integrated with the sprites system rather than just something bolted on the side. Eg. you should have a completely alternate class of sprites that's purely for display purposes, that bypasses most of the stuff that make sprites so slow, the sprite limit should be lifted, etc. But right now you can achieve the exact same thing with point sprites.

That sounds great, and of course it would be useful for making modifications. As you know, some mods (e.g. DukePlus) already have "particles" that are full-blown sprites. Are you saying that the planned system is going to be spawning hardcoded display-only particles in addition to whatever mods are coded to do? If so, that concerns me. A hardcoded system would need to make assumptions that would be true for the standard tileset using the HRP, but would be false in many other contexts. For example, if it's going to spawn metallic sparks when metal surfaces are impacted, then that depends on specific tile numbers being identified as metal.