[LeoD]

Striker, on 16 February 2020 - 11:17 AM, said:

the needle (actor front) in mapster32?

Not 100% sure what that means, but I think the answer is yes.
These screenshots should help explain. Left to right/bottom to top: ART, current KVX, current MD3, corrected KVX

NightFright, on 16 February 2020 - 01:13 PM, said:

That's a lot less than I thought. Weren't there also faucets, geisha statue, pistol ammo, grow ammo and neon cocktail sign from one of your posts above? Or is everything included in that last attachment?

I posted them yesterday, not included now.

[NightFright]

Ok, then I will gather all your posted files and commit them to the Github repo tomorrow unless there are objections. Maphacks won't be fully functional any more until they are updated as well.

[LeoD]

NightFright, on 16 February 2020 - 01:36 PM, said:

Ok, then I will gather all your posted files and commit them to the Github repo tomorrow unless there are objections. Maphacks won't be fully functional any more until they are updated as well.

No, not really. It's just different now. Examples:
- correct now, both to ART+MHK : ammo, growammo
- no longer OK in MHK : Geisha, Tripodcamera
- correct to ART, not MHK "compliant", but now in a different angle : us flag
- some changes hardly noticable at all

For the records: copy/paste editing made me mess up two descriptions in my last post on the previous page:

LeoD, on 16 February 2020 - 11:05 AM, said:

4546_foodobject17 - 9 voxel forward, 2 voxel right; 4547_foodobject18 - 9 forward, 2 right

-> 4546_foodobject17 - 9 voxel forward; 4547_foodobject18 - 9 backward, 2 right
The uplaoded KVXes are OK, though.

[Striker]

LeoD, on 16 February 2020 - 01:22 PM, said:

Not 100% sure what that means, but I think the answer is yes.
These screenshots should help explain. Left to right/bottom to top: ART, current KVX, current MD3, corrected KVX
camera-eduke32.jpg camera-mapster.jpg

I posted them yesterday, not included now.

The last one (right/top) plain incorrect. The needle is facing east, but the camera is facing south.

[NightFright]

Sounds like not too much work regarding maphacks adjustments.

[LeoD]

Striker, on 16 February 2020 - 01:52 PM, said:

The last one (right/top) plain incorrect. The needle is facing east, but the camera is facing south.

The two in the middle seem more convenient in this very case. But the right one looks the same as the ART (left) when you stand in front of it. Just like where the front of the ART points to in Mapster. We would have to discuss about many, many sprites where their actual 'front' is if doing otherwise. Compare to the pistol/firstgun sprite for example.
People have been shitting on the HRP in this thread, last but not least due to 'inaccuracies' in this type of cases.

[Radar]

Because the HRP is shit.

[Radar]

I honestly don't see the logical flow behind anything you're doing. First you said you were going to rotate the voxels to align them with the HRP maphacks. Now NightFright is saying the maphacks are broken. What's going on?

[Striker]

LeoD, on 16 February 2020 - 02:03 PM, said:

The two in the middle seem more convenient in this very case. But the right one looks the same as the ART (left) when you stand in front of it. Just like where the front of the ART points to in Mapster. We would have to discuss about many, many sprites where their actual 'front' is if doing otherwise. Compare to the pistol/firstgun sprite for example.
People have been shitting on the HRP in this thread, last but not least due to 'inaccuracies' in this type of cases.

Unfortunately that makes matters rather un-intuitive for mappers. When setting up sprites, you normally set the angle to where you want the actor to point towards.

I think the biggest qualm about the HRP is that it's just a jumbled, inconsistent mess visually. As far as models and angles are concerned, only a few HRP models are weird in that their logical "front" isn't correct and have to be offset in DEF or maphacks to compensate. This only seems to exacerbate matters. IMHO, only the models that are wrong should be corrected, and voxels made to match them.

[LeoD]

Striker, on 16 February 2020 - 02:22 PM, said:

Unfortunately that makes matters rather un-intuitive for mappers. When setting up sprites, you normally set the angle to where you want the actor to point towards.
I think the biggest qualm about the HRP is that it's just a jumbled, inconsistent mess visually. As far as models and angles are concerned, only a few HRP models are weird in that their logical "front" isn't correct and have to be offset in DEF or maphacks to compensate. This only seems to exacerbate matters.

Well, let ReaperMan and Nightfright decide then. Their project, their policy. I wouldn't have touched the camera if I hadn't thought this is the way things shall be handled here.

Radar 100 Watts, on 16 February 2020 - 02:09 PM, said:

Because the HRP is shit.

Spoiler

Spoiler

[Radar]

I love how your response includes no justification as to how your edits are productive.

[Striker]

LeoD, on 16 February 2020 - 02:31 PM, said:

Well, let ReaperMan and Nightfright decide then. Their project, their policy. I wouldn't have touched the camera if I hadn't thought this is the way things shall be handled here.

Spoiler

Jehova1HRP.jpg

Spoiler

Jehova2.jpg

It's appreciated that you want to help, but yeah, I think it may need a little more thought.

[LeoD]

Striker, on 16 February 2020 - 03:09 PM, said:

It's appreciated that you want to help, but yeah, I think it may need a little more thought.

That's why my proposals come with screenshots everyone may discuss. No HRP-conspiracy or jump-the-gun here.

[Kyanos]

It looks to me like the camera now aligns properly to the sprite, why are you guys now arguing against this?

[LeoD]

Photonic, on 16 February 2020 - 03:59 PM, said:

It looks to me like the camera now aligns properly to the sprite, why are you guys now arguing against this?

Mapper's convenience in 2D mode.

[Kyanos]

LeoD, on 16 February 2020 - 04:04 PM, said:

Mapper's convenience in 2D mode.

Radar literally gets his way then continues ranting and downvoting. He must be distracted, is rick and morty on?

[NightFright]

All realigned/-oriented voxels uploaded to Github. Before I start editing existing maphacks with just some entries, it's better if someone now goes through all of them and does everything at once.

Affected tiles:
40, 45, 670, 753, 869, 1008, 4438, 4443, 4444, 4546, 4547, 4548, 4569, 4576

PS: Instead of adding con code for faucet2, I went for Darkus' approach to add a line to props.def. Since this was already done for other entries, it's more consistent that way. Should it cause any trouble, it can still be done the other way later.

[Borion]

LeoD, on 15 February 2020 - 06:16 AM, said:

On the faucet models (574, 670, 671):
0670-zadd6.jpg
670 needs to be moved down by 6 units.
As it seems, back in the 90's 3DRealms forgot to animate the open faucet. If you add tile0671 we can use this additional CON script to have the water animated:
faucet2.zip
You can test this in E4L1 with models/voxels disabled, or use 0574 as placeholder for 0671 to check on KVX.
Faucet remark #3: The sprites shown in frontal (other than the chairs for example) have no depth information which gives you a certain freedom when creating the voxmodels. My point is here, that, when you look from the side, the outlet is currently way too short to actually reach the sink (compare to MD3). Here you can improve without sacrificing faith to the ART.

Yeah, faucet needs to be redone. I will try to take care of that soon.

[Striker]

Borion, on 17 February 2020 - 06:53 AM, said:

Yeah, faucet needs to be redone. I will try to take care of that soon.

I have my own edits to the faucet voxels for StrikerDM, if anyone's interested. Fixes the alignment and provides animation for faucet2.

http://shadowmaveric...areX/faucet.zip

NightFright, on 17 February 2020 - 12:02 AM, said:

All realigned/-oriented voxels uploaded to Github. Before I start editing existing maphacks with just some entries, it's better if someone now goes through all of them and does everything at once.

Affected tiles:
40, 45, 670, 753, 869, 1008, 4438, 4443, 4444, 4546, 4547, 4548, 4569, 4576

PS: Instead of adding con code for faucet2, I went for Darkus' approach to add a line to props.def. Since this was already done for other entries, it's more consistent that way. Should it cause any trouble, it can still be done the other way later.

Fuck. Now my maps are going to break. Dunno if you read the discussion earlier about how the front of an actor should equate to the front of a voxel (aka where it's facing), not the side facing you in the OG sprite. Now it's just going to get confusing for mappers. (You'll end up with situations where you try to point an actor east, but the voxel is going to be facing south)

[NightFright]

I thought it would actually be like that. Oh well, I guess we are not done with this yet. At least it's just about 14 voxels, not the entire pack.

[LeoD]

Striker, on 17 February 2020 - 08:21 AM, said:

I have my own edits to the faucet voxels for StrikerDM, if anyone's interested. Fixes the alignment and provides animation for faucet2.

Nice. The outlet still seems too short, though. I'd still use it (671!) and have Borion work on more important stuff.

Striker, on 17 February 2020 - 08:21 AM, said:

Fuck. Now my maps are going to break. Dunno if you read the discussion earlier about how the front of an actor should equate to the front of a voxel (aka where it's facing), not the side facing you in the OG sprite. Now it's just going to get confusing for mappers. (You'll end up with situations where you try to point an actor east, but the voxel is going to be facing south)

Are you sure that other mappers use that same approach? In 2D mode you see what you get per default. I'd guess that determining the front and where it should point to is more a question of habit. If more mapping 'colleagues' chime in on your behalf, I surely would not object reverting 4444 and deal similarly with other models. Alhough I personally think that the current 'academical' approach provides better consistency and maintainability, and therefore should get the nod. Are there other ongoing projects that are designed to make use of this voxel pack (or even the HRP)? Otherwise, mappers simply don't (have to) deal with sprite orientation and are not affected anyway. I'll gladly provide maphacks for your maps if you don't want go through them in 3D mode again.

NightFright, on 17 February 2020 - 12:02 AM, said:

PS: Instead of adding con code for faucet2, I went for Darkus' approach to add a line to props.def. Since this was already done for other entries, it's more consistent that way. Should it cause any trouble, it can still be done the other way later.

Yeah, this should be the better solution here, since we already have our own DEF files anyway.

NightFright, on 17 February 2020 - 09:42 AM, said:

I thought it would actually be like that. Oh well, I guess we are not done with this yet. At least it's just about 14 voxels, not the entire pack.

So far it's only 4444, I think, where practical reasons lead to differing opinions on what a sprite's actual 'front' is. More to come, though.
Btw, as long as there's no 671 in the pack, better comment out the animation line. Those quick switches between voxel and sprite (E4L1) look quite nasty...
Just an opinion: I'd prefer to have the animation lines where their addressed objects are actually defined, rather than at the DEF's beginning.

[Striker]

LeoD, on 17 February 2020 - 11:33 AM, said:

Are you sure that other mappers use that same approach? In 2D mode you see what you get per default. I'd guess that determining the front and where it should point to is more a question of habit. If more mapping 'colleagues' chime in on your behalf, I surely would not object reverting 4444 and deal similarly with other models. Alhough I personally think that the current 'academical' approach provides better consistency and maintainability, and therefore should get the nod. Are there other ongoing projects that are designed to make use of this voxel pack (or even the HRP)? Otherwise, mappers simply don't (have to) deal with sprite orientation and are not affected anyway. I'll gladly provide maphacks for your maps if you don't want go through them in 3D mode again.

Yeah, this should be the better solution here, since we already have our own DEF files anyway.

It's mainly a thing of habit coming from working with models in a number of games, like my Doom mods, Quake, and Source Engine. (Aka. front faces along the X axis. Magenta in this screenshot)


StrikerDM uses the Voxel Pack, btw. Designed entirely with it in mind.

LeoD, on 17 February 2020 - 11:33 AM, said:

So far it's only 4444, I think, where practical reasons lead to differing opinions on what a sprite's actual 'front' is. More to come, though.
Btw, as long as there's no 671 in the pack, better comment out the animation line. Those quick switches between voxel and sprite (E4L1) look quite nasty...
Just an opinion: I'd prefer to have the animation lines where their addressed objects are actually defined, rather than at the DEF's beginning.

If it's only the camera that's "off", then that's good, easy enough to manage. If need be, I can check all these voxels and make corrections as needed.

[NightFright]

10 new voxels by Borion added to Github, animtilerange def code for faucet2 deactivated.

[Borion]

One of latest additions, lifebuoy (1073)

[Borion]

foodobject8 (4537) & foodobject9 (4538)

[Borion]

foodobject10 (4539)

[LeoD]

Your napkin box aka 4539_foodobject10 seems like a wall-mounted type. Their occurrences in E4L2/E4L9 imply a 'standalone' version. I suggest doubling the depth (napkins on both sides maybe?) and have it centred like the MD3, so it doesn't fall over as easily...


4537_foodobject8 4538_foodobject9 fall into our beloved "where is the front?" section:


I did a quick romp through the ART to get a list of some more candidates with high to negligible likelihood of orientation discussion:

Spoiler

There are many bottles, actually round, where one could argue that their label should face front. That's how the HRP modeller's decided. Our voxel models replicate the ART's 45° angle. Probably not worthy talking about ATM. Others:
0487 space shuttle
0489 satellite
0516 radar dish
0603 hangbabe
0678 scales
0685_cameralight
0686_moviecamera
0762_mike
0998/9 parkometer
1222 crane
1247 seenine
1317 poledancer
1336 fem8 (dead)
1337 helicopter
1352 monk
2491 Duke's skyship
3400 duf beer blimp
4361 rubber duck
4402 dog
4404 robopirate
4444_tripodcamera
4496 broom - leaning forwards/backwards
4537_foodobject8 (mustard)
4538_foodobject9 (ketchup)
4576_shoppingcart
4591 dolphin

Btw., those 'ketchup screenshots' show what can not be done with voxels in maphacks, yet.

[Borion]

Yes, we need to correct rotations and all agree on right way to do that. Please guys keep your heads cool, we have an open discussion here

About foodobject10, making it thicker sounds ok. It could fall too easily, agreed

4537_foodobject8 4538_foodobject9 - I think this is one of those cases where object "would" face us, but its flat representation had to be rotated for illustrative reasons. But thats just an idea, feel free to correct me.

EDIT:
Locations of 4537_foodobject8 4538_foodobject9 need correction in VP maphacks. Pivots in those objects are centered on purpose. I think its better to make them "mappers friendly", then adjust them for one appearance in campaign.

[ReaperMan]

I think its one of these holders Borion... Napkins on both sides.

[Borion]

ReaperMan, on 18 February 2020 - 07:15 PM, said:

I think its one of these holders Borion... Napkins on both sides.

This is first time in my life I see double sided napkin dispenser. I don't mean it in as an insult.

I'll make it double sided.

Cheers