[Dzierzan]

I think the best approch would be eduke32 team supporting that flag. Because as you wrote, Dukeburger will have the same issue. Imagine doing voxels for each facings, madness.

[NightFright]

I concur it's stupid to use the same voxel multiple times just to change its rotation. Cheello did it with the Emperor hologram, but like this you needlessly increase the amount of voxels and therefore loading/startup times.

At least I got the mine working without glitches by defining the same voxel for all five frames. It's not rotating, either, but right now that's as good as it'll get.

[0815Jack]

If you mean with dukeburger sprite 4570, then its aleady done by Cheello and it works flawlessy with this line of ocde

voxel "voxels/props/4570_DUKEBURGER.kvx" { tile 4570 rotate }

[Dzierzan]

Then it should work with any voxel. I tried to do the same for RPG pickup, it didn't work. I tested it with the build eduke32_win64_20251111-10652-39967d866.


But then again... I do remember it used to work fine since I've been always testing that in eduke32 port.

[0815Jack]

Dzierzan, on 30 December 2025 - 11:47 AM, said:

Then it should work with any voxel. I tried to do the same for RPG pickup, it didn't work. I tested it with the build eduke32_win64_20251111-10652-39967d866.


But then again... I do remember it used to work fine since I've been always testing that in eduke32 port.

Ok did some investigation and replaced the dukeburger with the mine in E4L2 ... and guess what ...it spins



So I checked the map for clues and found a sprite called "rotation pivot" nearby. I guess the voxel needs it for rotation , but someone with deeper knowledge has to confirm. The mines in E1L4 doesn't have the sprite.

[Dzierzan]

So it's a map thing. It doesn't solve anything .

[NightFright]

IIRC that Dukeburger statue is placed on top of a tiny rotating sector. Technically it's not an animation, just a static sprite with different viewing angles defined.

Either way, the mine works differently because it is an animation sequence. At least in EDuke32 you need voxels for each frame of the animation to make it work. In other ports like BuildGDX it's enough to have the first voxel and then use the rotate flag, provided the prop itself remains unchanged throughout the entire sequence.

Cheello didn't bother to create rotations for his version of the mine. For some reason he copied the first voxel four times instead, which is not the best way to do it.

[0815Jack]

NightFright, on 30 December 2025 - 01:50 PM, said:

Cheello didn't bother to create rotations for his version of the mine. For some reason he copied the first voxel four times instead, which is not the best way to do it.

I can asked Cheello to do it like he did with the emperor holo.... but like you said earlier it has an impact on loading times... Luckily Hendricks increased MAXVOXELS to 2048 a couple a months ago... otherwise my testmap won't load anymore

[NightFright]

Some areas of your test map are not tall enough, btw. The Emperor voxel doesn't show up because it clips too much through the walls, it seems. You might need to resize that particular area. In general it's a very useful thing to have for quick testing, though.

[DNS]

Dzierzan, on 29 December 2025 - 05:27 AM, said:

I see you added Cheello's voxels, cool. But I have one concern, why did you replace my cannon? No doubt, I have some bad shading in some spots which I can easily improve.

Or maybe let's vote which one the community wants to have:



Left - Cheello, Right - Dzierzan


Left - Dzierzan, Right - Cheello

Similar story with the mine:
Cheello's


Dzierzan's:

And just as I predicted, this is already turning into a pissing contest of hair splitting. None of the marginal differences in these two sets of voxels would be noticeable during actual gameplay. Instead we have side by side still image comparisons that will significantly delay progress with bureaucracy for what's ultimately pedantic ego stroking.

Since nightfright is the one putting this project together I say he just make an executive decision to get it done. The pedantry can continue to be argued about after the fact.

And for what it's worth my vote actually goes to cheellos voxels in both cases of this comparison. Not that it ultimately makes any difference but under a microscope they are slightly more detailed, at least the mine is.

[NightFright]

Dzierzan updated his cannon voxel in the meantime with improved shading, for what it's worth. In general however, I will avoid removing existing content from our own pack unless Cheello's versions are clearly superior. With the mine and cannon that was obviously not the case, so the removal was not necessary.

Regaring how to proceed:
For now we have Cheello's monsters, player and NCPs in there and it already makes a big difference. Whether smaller props should be added needs to be seen. I'd like to avoid turning this into a "Cheello Lite" variant with just some deviations in it, otherwise it loses its reason to exist.

[Ñuño Martínez]

Not sure if this is the place to ask for this: I am not able to use the voxels pack on eDuke (on Debian Linux). I followed the instructions but it seems as I'm not able to locate the "autoload" directory. Reading the eDuke documentation didn't help.

[DNS]

Ñuño Martínez, on 31 December 2025 - 02:13 AM, said:

Not sure if this is the place to ask for this: I am not able to use the voxels pack on eDuke (on Debian Linux). I followed the instructions but it seems as I'm not able to locate the "autoload" directory. Reading the eDuke documentation didn't help.

Have you tried unpacking the archive and running with command line parameters instead?

All of them as well as explanations are listed here for reference.

[Ñuño Martínez]

DNS, on 03 January 2026 - 10:23 AM, said:

Have you tried unpacking the archive and running with command line parameters instead?

All of them as well as explanations are listed here for reference.

Thanks. Tried but still not work. The game doesn't use voxels and no option to activate them appears at the configuration menu (I've looked everywhere and found nothing).

The console output:

$ eduke32 duke3d-voxel-pack_p1.zip 
 runtime  src| 
 0,0730s INFO| Using directory /home/guillermo/Descargas/Duke/
 0,0730s INFO| Using directory /home/guillermo/.config/eduke32/
 0,0731s INFO| Started at 2026-01-04 11:39:30.402
 0,0731s INFO| EDuke32 r10652-39967d866
 0,0731s INFO| Built Nov 24 2025 21:14:35, GCC 14.2.0, 64-bit
 0,0732s INFO| Using directory /home/guillermo/.steam/steam/steamapps/common/Duke Nukem 3D/gameroot/
 0,0732s INFO| Using directory /home/guillermo/.steam/steam/steamapps/common/Duke Nukem 3D/gameroot/addons/dc/
 0,0732s INFO| Using directory /home/guillermo/.steam/steam/steamapps/common/Duke Nukem 3D/gameroot/addons/nw/
 0,0732s INFO| Using directory /home/guillermo/.steam/steam/steamapps/common/Duke Nukem 3D/gameroot/addons/vacation/
 0,0732s INFO| Using directory /home/guillermo/.config/eduke32/
 0,0733s INFO| Using directory /usr/share/games/eduke32/
 0,0733s INFO| Application parameters: duke3d-voxel-pack_p1.zip
 0,0741s INFO| CPU: Intel(R) Core(TM) i5-14500T
 0,0741s INFO| Initializing SDL 2.32.4 (SDL-release-2.32.4-0-g2359383fc (Debian 2.32.4+dfsg-1))
ATTENTION: default value of option mesa_glthread overridden by environment.
 0,2553s INFO| Using 'x11' video driver.
 0,2554s  GFX| Detecting video modes for display 0 (DELL SE2425HM 24")...
 0,3246s INFO| Searching for game data...
 4,3368s INFO| Using duke3d.grp as main data file.
 4,3383s INFO| Loaded duke3d-voxel-pack_p1.zip
 4,3422s  CON| Compiling: EDUKE.CON (171 bytes)
 4,3447s  CON| Including: game.con (151190 bytes)
 4,3447s  CON| Including: DEFS.CON (35992 bytes)
 4,3451s  CON| Including: USER.CON (45482 bytes)
 4,3454s WARN| USER.CON:844: overwriting existing definition for sound #261 (hydro43.voc)
 4,3454s WARN| USER.CON:873: overwriting existing definition for sound #323 (aisle402.voc)
 4,3460s  CON| game.con: In actor 'ORGANTIC':
 4,3460s WARN| game.con:3967: found 'else' with no 'if'
 4,3464s  CON| game.con: In state 'pigshootenemystate':
 4,3464s WARN| game.con:5890: found 'else' with no 'if'
 4,3468s WARN| Found 4 warning(s), 0 error(s).
 4,3481s  CON| Compiled 145216 bytes in 6ms
 4,3779s INFO| Initialized 96,0M cache
 4,4231s INFO| Loaded DUKE.RTS
 4,4231s INFO| Initializing console...
 4,4348s INPT| No game controllers found.
 4,4354s INFO| Executing settings.cfg
 4,4365s  GFX| Setting video mode 720x480 (8-bpp fullscreen).
ATTENTION: default value of option mesa_glthread overridden by environment.
 4,4794s  GFX| OpenGL driver: Mesa Intel(R) UHD Graphics 770 (ADL-S GT1) 4.6 (Compatibility Profile) Mesa 25.0.7-2
 4,4795s  GFX| OpenGL context: version 4.6
 4,4795s  GFX| Refresh rate: 60,00Hz.
 4,8375s  ASS| Initializing Apogee Sound System
 4,8520s  ASS| Using SDL PULSEAUDIO driver on Audio Interno Estéreo analógico
 4,8521s  ASS| Initialized sound at 48,0 KHz stereo with 64 voices
 4,8521s  ASS| Initializing MIDI driver: AdLib OPL3 emulation
45,1308s INFO| Wrote eduke32.cfg
45,1308s INFO| Wrote settings.cfg

There are a few errors in the CON files (a few "else" without "if") but I doubt that's the problem, or is it? BTW, my DUKE.GRP file should be from an original CD (legally purchased) but maybe is it using the Steam's one? (Didn't uninstalled it yet but I should...). Anyway, all my GRP files are legal so they shouldn't fail (except the few known bugs).

[0815Jack]

Hi,

just a question. your ZIP file "duke3d-voxel-pack_p1.zip" Did you download it from github via Code > Download Button? If yes then you might have a folder structure that eduke32 ( or linux) can't handle. It contains a subfolder called "duke3d_voxelpack-master" and inside is the actual content. Can you check? Because the ZIP seems to be found and loaded, but does nothing with its content.. like in my log

2.7959s INFO| Duke3D Maphacks r729
2.8025s INFO| Definitions file 'duke3d.def' loaded in 340 ms.
3.4235s INFO| Generating 3D meshes from voxel model data. This may take a while...
4.3548s INFO| Generated 3D meshes for 770 voxels in 931.02 ms.


What I do is to extract the the github zip und repack it so that the zip doesn't have a subfolder





@NightFright: Can you add following lines to the maphacks to that the rubbercans are not inside the wall in E1L1
sprite 383 mdposxoff 128 //tile1062 rubber can
sprite 384 mdposyoff 140 //tile1062 rubber can

[Ñuño Martínez]

Content of the zip was a bit different, missing a few files. I don't remember if I used Code > Download but I downloaded it again from GitHub's releases and it works now. I'm dumb.

Thanks for the tips.

0815Jack, on 04 January 2026 - 07:43 AM, said:

Hi,

just a question. your ZIP file "duke3d-voxel-pack_p1.zip" Did you download it from github via Code > Download Button? If yes then you might have a folder structure that eduke32 ( or linux) can't handle. It contains a subfolder called "duke3d_voxelpack-master" and inside is the actual content. Can you check? Because the ZIP seems to be found and loaded, but does nothing with its content.. like in my log

2.7959s INFO| Duke3D Maphacks r729
2.8025s INFO| Definitions file 'duke3d.def' loaded in 340 ms.
3.4235s INFO| Generating 3D meshes from voxel model data. This may take a while...
4.3548s INFO| Generated 3D meshes for 770 voxels in 931.02 ms.


What I do is to extract the the github zip und repack it so that the zip doesn't have a subfolder

zip.PNG



@NightFright: Can you add following lines to the maphacks to that the rubbercans are not inside the wall in E1L1
sprite 383 mdposxoff 128 //tile1062 rubber can
sprite 384 mdposyoff 140 //tile1062 rubber can

[NightFright]

0815Jack, on 04 January 2026 - 07:43 AM, said:

[...]
@NightFright: Can you add following lines to the maphacks to that the rubbercans are not inside the wall in E1L1
sprite 383 mdposxoff 128 //tile1062 rubber can
sprite 384 mdposyoff 140 //tile1062 rubber can

Done.

[0815Jack]

NightFright, on 30 December 2025 - 01:50 PM, said:

IIRC that Dukeburger statue is placed on top of a tiny rotating sector. Technically it's not an animation, just a static sprite with different viewing angles defined.

Either way, the mine works differently because it is an animation sequence. At least in EDuke32 you need voxels for each frame of the animation to make it work. In other ports like BuildGDX it's enough to have the first voxel and then use the rotate flag, provided the prop itself remains unchanged throughout the entire sequence.

Cheello didn't bother to create rotations for his version of the mine. For some reason he copied the first voxel four times instead, which is not the best way to do it.

With Raze the mines also spins with both packs used. So Cheello needs create different rotation voxels to make the rotation work in Eduke32?

[NightFright]

I don't think so. I'm sure he tried. AFAIK there is currently no way to achieve this effect in EDuke32. It doesn't support the "rotate" flag. You would have to make properly rotated voxels for each frame, which would be a waste in this particular case, increasing startup times even further.

[0815Jack]

NightFright, on 07 January 2026 - 02:06 PM, said:

I don't think so. I'm sure he tried. AFAIK there is currently no way to achieve this effect in EDuke32. It doesn't support the "rotate" flag. You would have to make properly rotated voxels for each frame, which would be a waste in this particular case, increasing startup times even further.

Ok, are he delevopers are aware of this issue?

[DNS]

0815Jack, on 08 January 2026 - 08:55 AM, said:

Ok, are he delevopers are aware of this issue?

Have you requested the feature?

[NightFright]

Easy there. Lives won't depend on this. And pushing a thread like this is not considered polite.

[NNC]

I downloaded the voxel pack, and have to report two issues: First, the turrets don't seem to work well. They shoot horizontally, even if they are over you. It feels wrong.

Also, if enemy types like lizztroopducking are not facing the player initally, they will gently rotate into the player which feels awkward a bit.

Other than that, the voxels themselves are very well made.

[Dzierzan]

Those are not issues because you replace sprites with voxels. The logic remains exactly the same, so say enemies or turret will not aim down or up using their bodies. The same happens with lizard's rotation you mentioned, that's how sprites behave, but you do not see that with only 8 sprite facings.

So all in all, that's expected behavior and kinda the reason why voxel enemies are really subjective.

[NNC]

I see your point, it just doesn't feel that great, since turrets are mechanical, and when they aim at you, they should move their "bodies" as well. In the case of turning enemy, I think maphacks are needed to avoid this issue, but it's a lesser one compared to the turret.

[Dzierzan]

You can't fix that with maphacks. You have to deal with them as they are. Or you just comment the turret out. It is up to you.