[Tea Monster]

You could use something other than Milkshape and position your model in the viewport and then take a render, rather than a screenshot. You could get some nice lighting effects on the firing animation that way.

Yes, it does take a lot of work.

[Sobek]

Tea Monster, on 28 February 2012 - 11:24 PM, said:

You could use something other than Milkshape and position your model in the viewport and then take a render, rather than a screenshot. You could get some nice lighting effects on the firing animation that way.

Yes, it does take a lot of work.

You mean for taking the initial snapshot of the model to use as a texture? I used Sketchup & Milkshape in my example above but originally gave Blender a whirl (did a highres render with the ambient occlusion baked in and lots of AA applied for the best quality). As you say, it's a lot of work, but the results can be pretty spectacular!

[Tea Monster]

Yeah, otherwise I'm thinking you would just use Polymer lighting on your model. I suppose you could do an AO bake and add some basic lighting to your render on the flat model. Then let Polymer add ambient lights from the game world. It might work.

Here's the pistol HUD model. It's just slapped together, but gives you the idea of what could be achieved with some care taken on lighting.

[MusicallyInspired]

There it is! That's the original gun right there!

[Jblade]

Running the latest snapshot, I get this error:

AMCENEMY.CON:526: warning: number greater than INT32_MAX converted to a negative one.
AMCENEMY.CON:536: warning: number greater than INT32_MAX converted to a negative one.

I checked, and it's related to the number at the end of the hitscan:

hitscan x y z mysector mycos mysin zdist hitsector hitwall hitsprite hitx hity hitz 4294901808

That's the number I got off of the hitscan page on the wiki; what should I use now if this number's not allowed anymore?

[Helixhorned]

It's OK to use now, but serves as a reminder for me. Just ignore it.

edit: other than that, it's just what it says: a warning that the number is actually converted to a negative one by re-interpreting the bits.

[Hendricks266]

LeoD, on 04 February 2012 - 12:47 PM, said:

Proposal:
What about adding an echo or version command/directive to the CON and DEF languages?
If these files could put out a version number it would be easy to identify outdated Mods or HRP versions when someone posts his eduke32.log.

Hendricks266, on 04 February 2012 - 04:15 PM, said:

Echo would be simple enough. Maybe I'll work on it.

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

Quote

---------------------------------------------------------------- --------
r2419 | hendricks266 | 2012-03-05 01:24:04 -0600 (Mon, 05 Mar 2012) | 1 line

Add "echo" CON command which allows the user to print a quote only to the console and log file, for debugging or informational purposes. EVENT_INIT can finally be put to use!
------------------------------------------------------------------------

LeoD, on 29 January 2012 - 06:00 PM, said:

Today I somewhat restored my broken compile environment. But building the debug version fails for the backtrace DLL. Any ideas?

A newer version of binutils included a new libbfd which added more dependencies to libintl than the one backtrace.c already accounted for. I added some semblance of the depended-upon functions in question to backtrace.c. If you added "-lintl" to your Makefile, remove it. (For those interested, they were libintl_*printf that were needed, so I set up functions of those that passed them through to normal *printf.)

Quote

---------------------------------------------------------------- --------
r2422 | hendricks266 | 2012-03-05 01:25:55 -0600 (Mon, 05 Mar 2012) | 1 line

Fix building ebacktrace1.dll with versions of binutils/libbfd after 2.20.51-1. This removes the need to link and depend on libintl (for now).
------------------------------------------------------------------------

[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: 686

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