[Jimmy]

The secret to the Sentry Drone, Turret, and the Riot Tank (to a lesser extent) is the rather uniform lighting/shading and extremely limited animations. They're not quite static objects but are maybe up to 30% as animated as other enemies.

[Forge]

Dear Voxel maintainers

I don't know if this issue was already addressed, or when it became a problem:

Started clean-up on the AA episodes for the upcoming release. Noticed that tile # 132 switch was visible on soda machines and stuff in the Caribbean addon, even though they were one sided and orientated away from the player.


Not sure if this is just an AA thing, or a universal thing with that voxel.

someone might want to double check and do any maphack adjustments necessary.

using r8603

(sorry, wrong pics attached)


Good chance that there's no issue but just a courtesy post.
The switches were fine in the last release of AA, but since then the voxel was updated and included with AA & during that time the one-sided switch became visible on both sides.

[NightFright]

I have the suspicion something broke with maphacks support in general, but I don't have any proof. Recently I had some issues with adding new definitions which wouldn't work, but it could also just be a mistake on my part.

[Danukem]

NightFright, on 04 February 2020 - 11:04 PM, said:

I have the suspicion something broke with maphacks support in general, but I don't have any proof. Recently I had some issues with adding new definitions which wouldn't work, but it could also just be a mistake on my part.

Are maphacks supposed to apply when a map is loaded in mapster, or only in game? I've only started paying attention to them recently and I'm not sure. I can tell you they are not being applied in mapster (at least in our project), even though mapster is loading the same duke3d.def and they are working in game.

[Forge]

That makes it difficult to hunt down issues.

eduke32 = maphacks loaded
but
mapster = no maphacks loaded
launching test from mapster also = no maphacks loaded - so a false positive on problems



a cursory glance at the vacation maphacks in the hrp svn show no uses of corrections to tile # 132 for vaca1.map (any version), which had issues on our end (several maps in the episode had issues)
not sure if this is the maphack that is used with voxel paks, or if the current svn is up to date

[Phredreeke]

Wouldn’t the voxels in the AA maps need to be corrected in the map itself as the sprite numbers would be different from the original? (Hence breaking maphacks)

[NightFright]

If sprite numbers shift when editing a map (as it is the case e.g. for the World Tour versions of ep. 1-4), maphacks meant for the unchanged version naturally would cease to function.

[Forge]

Phredreeke, on 05 February 2020 - 05:28 AM, said:

Wouldn’t the voxels in the AA maps need to be corrected in the map itself as the sprite numbers would be different from the original? (Hence breaking maphacks)

Not in the original 4 episodes. Those are provided by the player with their grp file.

But for DC and Caribbean, yes.
We did manually go through and edit the sprites to render them invisible.
We never used the maphacks for DC and Caribbean because they were so heavily edited.

I simply dropped a courtesy note when it was noticed that the switch, which was not visible in the last AA release, was now visible with the last voxel update.
The switch was not specified in the maphack file for vaca1.map in the hrp svn. It's an assumption that it probably isn't addressed in most maphack files for the vaca maps. (& possibly DC as well, though I didn't find any issues with those on our end)

This was just a heads up, maybe check it out to see if it's okay in the voxel pak + 'vanilla' version of Caribbean
If there are no issues, then super. Disregard.

[LeoD]

Trooper Dan, on 02 February 2020 - 05:13 PM, said:

Wouldn't it make more sense to convert all of the voxels into models offline and just use those instead? Startup time would be improved, they would look exactly the same, but then we would be able to change pitch and roll on the models which is useful for mods.

And maphacks, man, maphacks!

Borion, on 03 February 2020 - 01:38 AM, said:

I'm not as long here as most of you people, so I may don't get full picture, but would't it be better if we fork HRP maphacks for voxel pack? I mean can't we just adjust maphacks only in context of voxels and forget 3D replacements branch? Original HRP seem to be finished & closed project anyway, so why those projects are mixed? Do I miss something?

Yes. The amount of work you can save by using existing maphacks. More than a thousand maps have been processed, leading to 1700+ *.mhk files when including known *.map variants/updates. See changelog.

Radar 100 Watts, on 03 February 2020 - 08:28 AM, said:

I don't think anyone has an issue with basing the maphacks for the voxels off the HRP ones, since they save a lot of time and effort. What we mean is, the voxels should not be adjusted for botched pivots in the maphacks. Rather, the voxels should be designed properly and the maphacks corrected.

So you choose going through all of those maps again over just rotating a few voxmodels by 90 or 180 degrees and be done for the most part? While I actually did format the *.mhk files with script-based patching in mind, all the affected [vox]models which have not been rotated would need adaption now, too. Because their orientation was considered OK a the time (and therefore they don't show up in *.mhk). And think about how many maps exist vs. how manyfew might be created over the coming years with voxels in mind but no 3D-testing during mapping... While I usually appreciate academic-style correctness, it just ain't worth it here.

Borion, on 03 February 2020 - 01:38 AM, said:

Crazy amount of work. But with some help from community members, you think its doable in near future?

See ya in 2025...at best.

The Watchtower, on 04 February 2020 - 04:49 AM, said:

How many sprites are left to "voxelize" or in other words will there ever be a more or less final version?

Probably not, because the opinions about what is worth voxelising or not may differ (see discussion about those flat signs), and late additions of rarely used or user-map-only sprites are always possible.

The Watchtower, on 04 February 2020 - 04:49 AM, said:

If so, that - along with Polymer's dynamic lights and normal mapping - can be the definitive edition of the game.

The Polymer renderer does not support voxels and, for all we know, never will.

The Watchtower, on 04 February 2020 - 04:49 AM, said:

Is this pack compatible with WT or just EDuke32?

WT maps, yes, but not the WT executable.

The Watchtower, on 04 February 2020 - 04:49 AM, said:

As for maphacks, just a side question: will the maphacks fix the other issues of the stock levels (we listed some of those tagging errors and unused R sprites back then)?

Current maphacks can only change the visual representation of a rendered sprite on the screen, not its actual properties.

Forge, on 05 February 2020 - 05:07 AM, said:

That makes it difficult to hunt down issues.
eduke32 = maphacks loaded
but
mapster = no maphacks loaded
launching test from mapster also = no maphacks loaded - so a false positive on problems

Having maphacks loaded while mapping could be even worse I suppose... Applying maphack values to the actual sprite properties in the *.map file would be a nice feature, though

The Watchtower, on 04 February 2020 - 04:49 AM, said:

a cursory glance at the vacation maphacks in the hrp svn show no uses of corrections to tile # 132 for vaca1.map (any version), which had issues on our end (several maps in the episode had issues)
not sure if this is the maphack that is used with voxel paks, or if the current svn is up to date

That's probably due to the nature of the switch MD3 models. Their back side is basically empty. So all you can see from a flipped/hidden wall-aligned switch model is the very thin outline "at best". Different story with voxmodels. Since the voxelpack wasn't much of a thing during most of the maphacking activities, and I wasn't aware about these implications, and no one complained anyway, the notmds will have to be added for these cases. All vaca*.mhk except for vaca1* are merely templates, btw.. I might continue on this episode if there is current need for these maphacks.

@Borion/@NightFright
The tile 0558 egg (user maps only) is almost identical to tile0675. (If you look veeery closely, 675 is 558 starting to crack.) I propose voxel "voxels/monsters/0675_slimeregg1.kvx" { tile 558 } as an inexpensive addition.
Like Striker proposed it, using the same model(-rotation) for both chair1/2 (no arms btw ) is the way to go IMO. Same goes for chair3 (680-684). Many thousand chairs have been taken care of under this assumption so far.


In order to get the most (well, everything) out of existing *.mhk we should urge the devs to make pitch, roll, and md[x|y|z]off work for voxels, too. NBlood has provided some new maphack commands recently, which allow for moving voxmodels. Those were probably easier to implement, but they're less powerful and less intuitive (from my maphacker's point of view) than EDuke32's as well. And they aren't compatible to existing *.mhk contents.

[Radar]

LeoD, on 06 February 2020 - 01:02 PM, said:

So you choose going through all of those maps again over just rotating a few voxmodels by 90 or 180 degrees and be done for the most part? While I actually did format the *.mhk files with script-based patching in mind, all the affected [vox]models which have not been rotated would need adaption now, too. Because their orientation was considered OK a the time (and therefore they don't show up in *.mhk). And think about how many maps exist vs. how manyfew might be created over the coming years with voxels in mind but no 3D-testing during mapping... While I usually appreciate academic-style correctness, it just ain't worth it here.

Sure it is. Ideally, the maphacks should have been designed correctly from the very beginning. That way, artists could have a trustworthy set of maphacks that will work with any properly designed model or voxel. But obviously with the HRP that wasn't the case because the HRP was filled with crap that would never be fixed. This is an opportunity to do it right. I even mentioned a few pages ago that I can help with the effort, but nobody acknowledged it. Which sprites need to be adjusted for having different orientation/pivots than their HRP counterpart?

[Jimmy]

"Well we made a mistake, so lets keep making the same mistake!"

Shit like this is exactly why I hate the HRP.

[LeoD]

Radar 100 Watts, on 06 February 2020 - 01:51 PM, said:

Sure it is.

No. Really. It is not. Over the course of four years I've made 90-95% of the existing maphacks, and revised the older ones several times. I dare say that I know what I'm talking about, effort wise.

Radar 100 Watts, on 06 February 2020 - 01:51 PM, said:

Ideally, the maphacks should have been designed correctly from the very beginning.

Yeah, but Duke University didn't offer any degree programme for HRP or Maphack studies, so I had to start without. I was rather late to the HRP party, and after the big model rotation in 2012 I did not expect much further issues. When checking out maps ingame, you usually don't know where North is. So it took quite some time to dawn upon me that there are any more problems at all.

Radar 100 Watts, on 06 February 2020 - 01:51 PM, said:

That way, artists could have a trustworthy set of maphacks that will work with any properly designed model or voxel. But obviously with the HRP that wasn't the case because the HRP was filled with crap that would never be fixed.

Placing pickup items or phones onto desks is not exactly art, is it? The non-ideal angle of some otherwise fine models is the very least problem the HRP has. Even taking into account the current/upcoming maphack issues. Many sprites show up in 45° angle as ART, so it's debatable anyway which orientation in the 90° voxel/model domain is the 'correct' one. I don't know when maphacks were introduced, but the rarely (or even only once) used original game sprites were probably designed to look best without maphacks (like the Luke model IIRC). Therefore not 'wrong' in the first instance.

Radar 100 Watts, on 06 February 2020 - 01:51 PM, said:

This is an opportunity to do it right. I even mentioned a few pages ago that I can help with the effort, but nobody acknowledged it.

It is an opportunity to waste a lot of time and effort. Instead you could bring the voxel part of EDuke32's maphack implementation on par with md3. And have some time left to fix up Polymer.

Radar 100 Watts, on 06 February 2020 - 01:51 PM, said:

Which sprites need to be adjusted for having different orientation/pivots than their HRP counterpart?

4495 wetfloor, 0056 airtank, 4454 deskphone for sure. Maybe 0040 ammo, I don't remember atm.

Additional reading - slightly edited excerpt from hrp_todo.txt:

Spoiler

================================================================================
Important: Concerning misaligned models
================================================================================

Several long-standing HRP models have an origin offset or a wrong rotation,
which has been taken care of in maphacks or HRP-aware user maps. If you redo
them, please consider reproducing those attributes or contact LeoD before
uploading a 'correct' version. (List not complete yet)

Offset:
0142 nukebutton (see end of adg03.map, should it be actually round at all?)
0574, 0670, 0671 (faucet)
0603 naked1 (hangbabe) ?
0768 sushiplate1 (floating)
0563 waterfountain
0860 powerswitch1
0991 (shower head)
1050 (fusebox), scale
1053 (toilet roll holder), scale
1164 bottle17
1255 ceilingsteam, size/diameter ?
4363 (combat knife)
4496 broom ?

180 degrees (angoff 1024):
0603 naked1 (hangbabe)
0678 scale
1227-1230 nukebarrel [label]
1228 exploding barrel [label]
1358 fetus
4369 (emergency light)
4496 broom
4520 chestofgold
4539 foodobject10
4548 foodobject19
4560 robotdog2

90 degrees (angoff +-512):
4454 deskphone
0610 (lightswitch pole), also too short
0669 vacuum
0679 (battlelord holo)
0694 pot1
0716 waittobeseated
0753 statue (geisha)
0869 statueflash (geisha)
0925 neon1 (cinema)
0927 (traffic signal), also has height offset
0990 tire
1079 oozfilter [label]
1294 podfem1
1323 fem5 (polebabe)
1334 fem6 (padbabe)
4377 policelightpole
4400 teddybear
4441 (J. McClain)
4442 (H. Callahan)
4444 tripodcamera
4473 (J. Dredd)
4537 foodobject8
4538 foodobject9
4547 foodobject18
4495 wetfloor
4887 pleasewait

135 degrees:
0516 satelite (dish)

Too short
0607 antenna
1221 cranepole

Too long
0909 (treetrunk)

Not high enough
0907 woodenhorse

Not wide enough
1049 fusebox2

Is it possible to run Mapster32 in batch mode on a bunch of *.maps, and write out all used sprites/tilenums to corresponding files?
That might be a first step on a feasible path towards patching angles in the existing *.mhks with reasonable effort and number of errors.

[Radar]

Mate, forget about the HRP. You literally have the most skilled voxel artist in the world as the primary contributor to this project. It is well worth the effort. Maphacks are nothing more than simple but tedious scripting.

[Jimmy]

LeoD, on 06 February 2020 - 05:48 PM, said:

It is an opportunity to waste a lot of time and effort. Instead you could bring the voxel part of EDuke32's maphack implementation on par with md3. And have some time left to fix up Polymer.

>implying whoever is making maphacks is working on the renderer

Why don't you fix Polymer instead of arguing on the internet then?

[Kyanos]

LeoD, on 06 February 2020 - 05:48 PM, said:

Is it possible to run Mapster32 in batch mode on a bunch of *.maps, and write out all used sprites/tilenums to corresponding files?

Yes, I've done this (except my m32 script was different, dumptiles is the function in a.m32 iirc...)

1) custom mapster32.exe that forces save/quit on "esc"
2) m32autoexec to call the script
3) edit the script to do it's thing then call "esc"
4) batch file to autorename between mapster runs

You may be able to do it with a vanilla m32 if you don't need to save the maps. It's just a matter of getting the .m32 script to close mapster. I'm not sure, when I did it I was processing maps, I knew .m32 script wasn't going to let me save & quit.

Spoiler

I was generating doom maps with oblige, then wad2map, then .m32 script. It was going to be a Ludum Dare build game, fully procedurally generated maps. It's almost ready, I've been working on procedurally generating music for it. Sounds like a great game eh?

[Radar]

LeoD, on 06 February 2020 - 05:48 PM, said:

Is it possible to run Mapster32 in batch mode on a bunch of *.maps, and write out all used sprites/tilenums to corresponding files?
That might be a first step on a feasible path towards patching angles in the existing *.mhks with reasonable effort and number of errors.

gamevar variable 0 0

defstate list_sprites
	for variable allsprites
	{
		addlogvar variable
		addlogvar sprite[variable].picnum
	}
ends

onevent EVENT_KEYS2D
	ifeitherctrl
    {
		ifhitkey KEY_W
		{
			state list_sprites
		}
	}
endevent

I'm thinking of re-doing E1L1 just to see how feasible it is.

[Borion]

LeoD, on 06 February 2020 - 01:02 PM, said:

@Borion/@NightFright
The tile 0558 egg (user maps only) is almost identical to tile0675. (If you look veeery closely, 675 is 558 starting to crack.) I propose voxel "voxels/monsters/0675_slimeregg1.kvx" { tile 558 } as an inexpensive addition.
Like Striker proposed it, using the same model(-rotation) for both chair1/2 (no arms btw ) is the way to go IMO. Same goes for chair3 (680-684). Many thousand chairs have been taken care of under this assumption so far.
In order to get the most (well, everything) out of existing *.mhk we should urge the devs to make pitch, roll, and md[x|y|z]off work for voxels, too. NBlood has provided some new maphack commands recently, which allow for moving voxmodels. Those were probably easier to implement, but they're less powerful and less intuitive (from my maphacker's point of view) than EDuke32's as well. And they aren't compatible to existing *.mhk contents.

Slimer Egg - I will look into that, thanks for pointing that out. Will post sth soon.

Please don't change pivots/rotations of KVX files to adjust them to HRP, guys. It will make those files HRP compatible only. They will be broken for other engines or mods. I think assets should be always kept "neutral". Voxel Pack contents got to be easy to use in other projects, am I wrong?
Can we at least consider alternatives? Thanks in adv

@pitch, roll, and md[x|y|z]off work for voxels - yes, would be so damn nice to have these working.

EDIT:
Almost all missing glass objects are done.

[Phredreeke]

Yeah but what exists right now are the HRP maphacks.

If they don't match the HRP then we'll end up needing a separate set of maphacks, when right now the voxel pack gets it for free from the HRP.

However I think one compromise solution would be if voxel definitions would allow adjusting pivot and rotation the same way maphacks does. Then Borion could ship voxels in a neutral state, they get adjusted to match HRP in the def file, and then the existing maphacks could be used.

[OpenMaw]

I think everything related to the HRP should be completely discarded, imo.

[Kyanos]

Commando Nukem, on 08 February 2020 - 08:47 AM, said:

I think everything related to the HRP should be completely discarded, imo.

[LeoD]

I've made my point. I won't regurgitate the arguments.
Rather than pleasing some hard core forum nerds, it has usually been my goal to act in favour of the actual (and casual) players of Duke Nukem 3D, and to keep things in a usable state. Starting from Polymost HRP reanimation (while Polymer seemed the real deal), over DukePlus NixFix to autoload-friendly episodes, etc..
A Voxels for Maphacks Pack is inevitable for the time being. Don't bother, anyone, I'll do it myself.

[Jimmy]

"I have to keep making the same mistake!"

[Radar]

LeoD, on 08 February 2020 - 06:56 PM, said:

A Voxels for Maphacks Pack is inevitable for the time being. Don't bother, anyone, I'll do it myself.

I checked in SLAB6 and many voxels are currently facing the wrong orientation to accommodate for the HRP maphacks. I would highly recommend you ensure the voxels are fixed before editing the maphacks.

Again dude, let me know if you need any help.

[Phredreeke]

So the voxels being changed. Are they used in any maps that were built with voxels in mind? (DNF2013, Alien Armageddon comes to mind)

[Borion]

I keep on working on frequently appearing small models. Seven new objects are finished.
One of them:
bottle11 (1158)

After uploading the gif I noticed some strange grey horizontal line over one of handles. That will be fixed before model upload.

[Fox]

Hmm not sure if the artist intended it to be round or oval, the perspective is kinda surreal

In terms of real life, looks like both types are common:

Spoiler

[Borion]

Fox, on 09 February 2020 - 08:57 AM, said:

Hmm not sure if the artist intended it to be round or oval, the perspective is kinda surreal

In terms of real life, looks like both types are common

Exactly, Fox. Was thinking which one is right for a long time. I chose more practical variant.

[Borion]

pot1 & pot2

[Striker]

Seeing the position of the handle from the front of the ice bucket, I think it's meant to be round.

[Borion]

Striker, on 09 February 2020 - 11:27 AM, said:

Seeing the position of the handle from the front of the ice bucket, I think it's meant to be round.

Maybe yes, maybe not. This sprite is like Mona Lisa, you can't be sure what hides behind those pixels... ;D