[The Battlelord]

Jamesfff, on 10 October 2020 - 03:46 PM, said:

jkas789: The readme with the voxel pack says "if it is not inside of a zipfile, EDuke32 will not run the voxel pack." How did you get it to run as a content folder?

it also says to check the Enable "autoload" folder option and turn off Polymer option, because it does not support voxels.

[jkas789]

I have always wondered. Is there a reason polymer does not support voxels?

[Jimmy]

It's unfinished, unsupported, and isn't even good. I'm really not sure why EDuke32 keeps shipping with it.

[Micky C]

There are still some released mods that rely pretty heavily on it.

[NightFright]

Normally I don't add content over the weekend since I am not anywhere near a computer, but I am making an exception today. Cannon, cannonballs and trashbin are added to Github.

And regarding the freezer ammo:
It's one of two voxels (besides the HoloDuke) which require custom code. It's possible this will only work in EDuke32 as intended, but I am not sure since I never checked it in any other port.

[jkas789]

Quote

Normally I don't add content over the weekend since I am not anywhere near a computer, but I am making an exception today. Cannon, cannonballs and trashbin are added to Github.

Welp, it seems I am not sleeping again tonight. I have to play through Duke Nukem 3D yet again.

[DotK3D]

Hi all, just to say it's a real pleasure to see your stuff (here and in other parts of the forum, like maps), some are very impressive.
I'm pretty busy since the last few years but I daily check the forum. What software, guys, did you use for voxels except slab 6 ? (just curiosity I still don't have time to even launch Duke and play new maps and addons !)

"Félicitations à tous pour votre boulot !"

[Dzierzan]

@DotK3D

Quote

What software, guys, did you use for voxels except slab 6 ?

I am using MagicaVoxel to create voxels and Slab6 only to export voxels to KVX format.

New voxel:

[jkas789]

And as I promised, it's 3:25 am in the morning and I have not slept a wink since the day before yesterday but fuck it. Its Duke Nukem 3D time gentleman. Anyways. While play testing the new voxels I couldn't help but notice some issues in regards to the canon and other stuff. Nothing game breaking but I think they are worth mentioning:

1.- There seems to be something funky going on with the cannons shadows. I took the following screenshots:



Notice how the shadow seem to bisect the canon itself, which does not happen to the other canon on the fort which. The same thing happens (although inverted) with both canons on the ship.



The cannonball sprite seems to come from the middle of the barrel in midair as well, however I suppose that's something that comes with the territory of voxelizing the canon.

2.- There also seems to be something weird going on with Devastators and rocket ammo, were depending on the viewing angle and the lighting they almost seem to flicker. I have personally never noticed before and AFAIK it was not a known issue so here are some screens:

The Devastator ammo box




The Rocket ammo box



Other than that everything is perfect IMO.


May I suggest the Pirate ship's steering wheel and the treasure chest as candidates for a voxel model?

[NightFright]

Broom and rope added to Github.
Note: Rope is floor-aligned and won't show up ingame (technical limitation, at least right now).

[Danukem]

jkas789, on 11 October 2020 - 02:47 AM, said:

1.- There seems to be something funky going on with the cannons shadows. I took the following screenshots:

Does the cannon with the bisecting shadow have the half-submerged (cstat +128) bit set?

[The Battlelord]

jkas789, on 11 October 2020 - 02:47 AM, said:

And as I promised, it's 3:25 am in the morning and I have not slept a wink since the day before yesterday but fuck it. Its Duke Nukem 3D time gentleman. Anyways. While play testing the new voxels I couldn't help but notice some issues in regards to the canon and other stuff. Nothing game breaking but I think they are worth mentioning:

1.- There seems to be something funky going on with the cannons shadows. I took the following screenshots:


Notice how the shadow seem to bisect the canon itself, which does not happen to the other canon on the fort which. The same thing happens (although inverted) with both canons on the ship.

You did play without enabling anything else right?


I had a similar case with the turret, but I've enabled the include voxels/monsters.def and got this:






If i diesable it, there is only a very small shadow (as usual, even without voxels pack):






Btw, the voxel pack i've used is from July 2020.

[Jamesfff]

jkas789: Thanks - it's working now.

[Dzierzan]

Some kind of small red lamp:

[Jimmy]

Micky C, on 10 October 2020 - 10:44 PM, said:

There are still some released mods that rely pretty heavily on it.

Wouldn't be the first time that EDuke32 is flat out incompatible with old mods. Polymer just confuses newcomers as to why it doesn't work correctly. For better or for worse it is a legacy renderer that no one should continue to develop projects for because it appears no one wants to finish it and the EDuke32 team only intends to replace it. People can just use old builds if they want to play old mods, it'd probably work better than new builds anyway.

[jkas789]

 The Battlelord, on 11 October 2020 - 11:34 AM, said:

You did play without enabling anything else right?


I had a similar case with the turret, but I've enabled the include voxels/monsters.def and got this[i]:

Sorry mate, I was dead asleep and didn't saw the post until now.


I enabled the enemy voxels because I wanted to know if seeing them in action would change my mind about voxelized enemies (surprise surprise it didn't). I checked in the def files and the Canon was not considered as an enemy but rather as a prop, and it is actually included in prop.def of the voxel pack. Also I'm using the latest master from github.

Quote

Thanks - it's working now.

I'm happy for you mate! Enjoy.

[ReaperMan]

 NightFright, on 09 October 2020 - 11:11 PM, said:

It's used only once in the episode, for me it doesn't classify as a regular monster. Besides, we don't voxelize monsters, so you HAVE to define it as a prop. ������

 NightFright, on 10 October 2020 - 12:56 AM, said:

Same thing, turrets, drones and tanks appear throughout ep.4. Anyway, pointless to argue about this. Main thing is we have the voxels. Who really cares about file directories? ������

I do, it helps keep stuff organized. We should make a monster directory.

 jkas789, on 10 October 2020 - 04:57 PM, said:

I suppose that Nightfright and co added that so that end users who don’t know anything about Duke modding don’t potentially eff up sonething.

No, that was me, that's how old builds of Eduke32 worked when I started the mod. But it does help with people not effing up stuff when they don't know what they are doing.

[Rellik]

Enemy might be a better term.

Also, maybe an environment hazards category? That would include exploding things, the canon and such.

[NightFright]

Red lamp now on Github.

[Striker]

Pipe 1 is on the wrong tile number. In the voxel pack, it's on 944, it should be 994.

[NightFright]

Good find! I was actually wondering why the first one was not grouped with the others before. It's corrected now.

[Dzierzan]

Maphacks are required:

[jkas789]

Ew.

Also cool.

But ew.

[Striker]

 NightFright, on 10 October 2020 - 10:51 PM, said:

Normally I don't add content over the weekend since I am not anywhere near a computer, but I am making an exception today. Cannon, cannonballs and trashbin are added to Github.

And regarding the freezer ammo:
It's one of two voxels (besides the HoloDuke) which require custom code. It's possible this will only work in EDuke32 as intended, but I am not sure since I never checked it in any other port.

Why does the freezer ammo require custom code? Seems to work fine without any. Pretty sure EDuke32 fixed the issue where sprites with ART animations wouldn't animate correctly.

[NightFright]

Panel and worms can added. Maphacks for E4L2 have been updated.

As for the Holoduke and Freezer ammo, I checked ingame with scripts and without. It seems it has to do with animations. If you omit the scripts, the lightning arc on top of the freezer ammo voxel doesn't flicker at all, it's a continuous beam without visible animation (it's changing too fast). The differences for the Holoduke are... well, I wouldn't say there are any, actually.

Here is the code to check, maybe one of you can figure out what's happening exactly and if there can be a different solution.

// Freezer ammo animation
action FREEZEAMMO_FRAMES 0 3 1 1 1
actor FREEZEAMMO 0 FREEZEAMMO_FRAMES
   fall
   ifmove RESPAWN_ACTOR_FLAG
      state respawnit
   else
      ifp pshrunk nullop
   else
      ifp palive
         ifcount 6
            ifpdistl RETRIEVEDISTANCE
               ifcanseetarget
               {
                  addammo FREEZE_WEAPON FREEZEAMMOAMOUNT
        	  quote 66
        	  ifspawnedby FREEZEAMMO
         	     state getcode
                  else
                     state quikget
               }
enda

// HoloDuke animation
action HOLODUKE_FRAMES1 0 4 1 1 8
actor HOLODUKE 0 HOLODUKE_FRAMES1
   fall
   ifmove RESPAWN_ACTOR_FLAG
      state respawnit
   else
      ifp pshrunk nullop
   else
      ifp palive
         ifcount 6
            ifpdistl RETRIEVEDISTANCE
               ifpinventory GET_HOLODUKE HOLODUKE_AMOUNT
                  ifcanseetarget
                  {
                     addinventory GET_HOLODUKE HOLODUKE_AMOUNT
                     quote 51
                     ifspawnedby HOLODUKE
                        state getcode
                     else
                        state quikget
                  }
enda

New seem to be the marked parts:
action FREEZEAMMO_FRAMES 0 3 1 1 1
actor FREEZEAMMO 0 FREEZEAMMO_FRAMES

action HOLODUKE_FRAMES1 0 4 1 1 8
actor HOLODUKE 0 HOLODUKE_FRAMES1

Any code after that is copy-paste from game.con.

At first glance, at least the new HoloDuke code is redundant since all it seems to be doing is to replace action HOLODUKE_FRAMES with HOLODUKE_FRAMES1, but the code is absolutely identical besides that. No different definitions anywhere else. It appears to be doing the exact same thing. It would make sense if HOLODUKE_FRAMES1 had different parameters compared to the original action, but it has the same values. Personally I couldn't explain why this was done in the first place, but maybe someone with more coding knowledge can share some insights.

The freezer ammo on the other hand does not have an action defined for it in game.con, so it may be needed for proper animation. For my taste the animation is still too fast, btw. After some tests, I believe this could be improved by changing the last action parameter from 1 to something like 5 or 6 (seems to be delay between frames), i.e.

action FREEZEAMMO_FRAMES 0 3 1 1 6

.

*EDIT*
I have now changed the freezeammo animation speed and deactivated the Holoduke script. Please experiment with it and see how it is. You can check it quickly by loading E1L8, for example.

[Dzierzan]

@NightFright

How does one create maphacks? Is it universal for all Build Engine games? I require this knowledge, mainly for Blood, but it surely will be useful everywhere.

[NightFright]

Well, it's not rocket science.

You need to know the sprite ID for the corresponding map. Usually I acquire it via Mapster32. I think GRPViewer can even tell you how often a sprite is used within a map, but the tool is deprecated and it's hard to tell how reliable it really is.

After you know the sprite ID, you can write the hacks. Most of the time it's about rotations, so you use angoff. Example for sprite #331:

sprite 331 angoff -256

This would rotate sprite 331 by a value of 256 counter-clockwise (equals 45°). 1024 would be a 180° rotation to the other side. Positive values rotate clockwise, negative ones counter-clockwise. So -512 would be a rotation by 90° counter-clockwise.

There are other parameters you can use instead of angoff, e.g. notmd (don't use a voxel), nomdanim (don't use voxel animations), pitch, roll, mdzoff (height), mdxoff (left/right), mdyoff (back/forward). I am not sure what all of these are doing and how these are used exactly, but they have to do with voxel relocations. Often you have to experiment.

As for the defs themselves, you can check the voxel pack how it is done, I guess. I think you won't need the md4 hash from each map if you are not dealing with several iterations of the same map. I have not written maphacks from scratch since ages, so experts like LeoD can surely provide more info about this.

I couldn't tell if it works the same way in BloodGDX or Rednukem, that would depend on whether they borrow this specific feature from EDuke32.

[Jimmy]

Just talking out of my ass here, but if you just need the actors to do an ACTION I'm not really sure you need to redistribute GAME.CON. Theoretically you could just get them to do an ACTION through an EVENT, which could be a few simple lines in VOXELS.CON or something like that. I don't know if this would work, but if it did then it could greatly improve compatibility. Theoretically. When it comes to Duke I don't count any eggs before they hatch, you never know what kind of weird behaviour the simplest things can introduce.

[NightFright]

Game.con is not included, just the part of the code from game.con which concerns the freezeammo and HoloDuke. It's apparently needed to copy the code of the entire actor again even if you just redefine the action used for it.

Anyway, try the new freezeammo animation and the removed HoloDuke script, I think it works.

[Hendricks266]

You shouldn't need CONs for either the freezer ammo or the holoduke with EDuke32. Voxels defined through def files get ART animations applied to them.