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

[Plagman]

The system would just be there available for use by scripts, it wouldn't do anything hardcoded. Hardcoded lights shouldn't really exist either for that matter, but at this point different scripts don't play well enough together to offload that in an EDuke32 built-in CON while still maintaining compatibility with stuff like Duke Plus. Hopefully we can do that at some point in the future..

[Fox]

I am a little confused, but why fogpal overwrite my lookup palettes?

Essentially I am trying to make this:



Looks like this:



However the second picture is a mock-up, I can't actually make the fog work in conjunction with a pallette.

[Plagman]

Isn't fog implemented using a lookup in SW mode?

[Fox]

Yes, but I don't understand why I can't use a custom lookup with a fog.

[LeoD]

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.

I oppose. The 1680 trooper alt-pal skins can be removed safely because the Polymost HRP part uses its own (old) model and skins. But the others need to stay in place for the time being, and you should only remove them from the Polymer DEF files. I have put an extraction script into the repository's install directory which can create pure Polymer(currently 595MiB), pure Polymost(376MiB), or full(652MiB) HRP packages by parsing the DEF files of the repo. So no one will have to download more than needed in the future. Once all alt-pals are disabled for Polymer I might move them when I'm on another janitorial spree.

[Hendricks266]

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.

The image files for all alt-skins must stay in place, except the Polymer trooper like LeoD mentioned. Removing the defs is a different story, but that would best be left to LeoD.