[Borion]

Couple other small things added lately


And two variants of improved foodobject10. Not sure which is right, so it is not uploaded yet:

[NightFright]

Fixed Expander ammo with new rotation is on Github. Please test and check if it's OK now.

[LeoD]

Borion, on 19 February 2020 - 05:30 AM, said:

And two variants of improved foodobject10. Not sure which is right, so it is not uploaded yet

My vote for the lower one, as ReaperMan implied.

[NightFright]

Github update:
- Replaced #1007 neon3 with thick version
- Reverted Expander ammo commit (was rotated by 180° instead of just 90°, better luck next time)
- Deleted some needless maphacks
- Added empty lines in def files where needed

[Borion]

LeoD, on 19 February 2020 - 06:42 AM, said:

My vote for the lower one, as ReaperMan implied.

Noted! Based on his upvote, I assume Fox is also preferring lower one.
Maybe two more votes and we got a winner

[Mark]

lower

[NightFright]

I would also go for the double-sided one.

[Fox]

No idea.

[Jimmy]

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.

Charlie Wiederhold's maps from 1996 had sprite orientations set front-facing. It's almost like he made his maps future proof.

Borion, on 19 February 2020 - 05:30 AM, said:

And two variants of improved foodobject10. Not sure which is right, so it is not uploaded yet:

I'd say include both with the lower one as the default. Modders/mappers could find the first one more useful somehow. I'm an options guy. "Why not both?"

[Radar]

Dual sided one is really fitting since the original art is a view aligned sprite where you can see the napkins at every angle. You can't do that to every voxel so it's cool that this one works out.

[NightFright]

Tile #4539 updated on Github. I checked in the single-sided version first, then the double-sided one. This way both are stored in the repo.

[Striker]

Just want to say this is perfect. This is exactly what I meant about the front of the voxel being aligned with the angle of the object.



Thank you. Because of this, it "just worked" with my existing maps.

(No sarcasm in this, btw.)

BTW, is there a chance someone can fix the colors on FOODOBJECT17 (4546), FOODOBJECT18 (4547), FOODOBJECT19 (4548), and JOLLYMEAL (4569)? They were royally palette crushed because they were converted from voxels made for the Shadow Warrior palette.

[Danukem]

Even with maphacks for the episodes, we are still going to have lots of errors like this in user maps:

https://imgur.com/rL8DBQv

Unfortunately some voxels will still display even if they are one-sided and on the other side where they are supposed to not be rendered.

[Phredreeke]

Can't you disable voxel rendering for individual sprites?

[Striker]

Trooper Dan, on 21 February 2020 - 11:11 AM, said:

Even with maphacks for the episodes, we are still going to have lots of errors like this in user maps:

https://imgur.com/rL8DBQv

Unfortunately some voxels will still display even if they are one-sided and on the other side where they are supposed to not be rendered.

I really think your mod may have something to do with this (or recent EDuke32 builds). I notice that a lot of things that are meant to be one-sided are being rendered. There's supposed to be code that prevents voxels from being rendered if you're behind a one-sided sprite.

[Danukem]

Striker, on 21 February 2020 - 11:28 AM, said:

I really think your mod may have something to do with this (or recent EDuke32 builds). I notice that a lot of things that are meant to be one-sided are being rendered. There's supposed to be code that prevents voxels from being rendered if you're behind a one-sided sprite.

It's not my mod. I just tested using a vanilla install with nothing added but the voxels and it still happens with the latest Eduke32. I invite you to do the same, just to make sure I'm not crazy or doing something wrong.

EDIT: A quick test case is in E1L1, the switch that opens the armor secret above the concession stand. The one-sided switch is visible if maphacks are not installed.

https://imgur.com/M0q6p1W

You can see I've got voxels installed from the voxels displaying on the counter, and that the one-sided switch is visible.

[Striker]

Trooper Dan, on 21 February 2020 - 11:48 AM, said:

It's not my mod. I just tested using a vanilla install with nothing added but the voxels and it still happens with the latest Eduke32. I invite you to do the same, just to make sure I'm not crazy or doing something wrong.

EDIT: A quick test case is in E1L1, the switch that opens the armor secret above the concession stand. The one-sided switch is visible if maphacks are not installed.

https://imgur.com/M0q6p1W

You can see I've got voxels installed from the voxels displaying on the counter, and that the one-sided switch is visible.

Then something is up with the latest EDuke32. One-sided sprites with voxels shouldn't render from behind, maphack or not. Something in the voxel code must have changed over the years, because in old builds this doesn't happen.

[LeoD]

Trooper Dan, on 21 February 2020 - 11:11 AM, said:

Even with maphacks for the episodes, we are still going to have lots of errors like this in user maps:

https://imgur.com/rL8DBQv

Unfortunately some voxels will still display even if they are one-sided and on the other side where they are supposed to not be rendered.

My upcoming Voxels4Maphacks Pack tries to improve on that by moving all voxel switches forward by one unit.

Phredreeke, on 21 February 2020 - 11:27 AM, said:

Can't you disable voxel rendering for individual sprites?

In terms of sprite numbers -yes, by notmd maphacks (you probably knew that). In terms of tile numbers: no, AFAIK.

[Phredreeke]

Yeah I meant the former. That's how I thought such issues were handled.

(if you wanted to disable by tile number wouldn't you remove the voxel definition itself?)

[Danukem]

Striker, on 21 February 2020 - 11:55 AM, said:

Then something is up with the latest EDuke32.

Yes. And after some experimentation, it seems connected to the t-sprite array. Setting the t-sprites of the switches to invisible via CON code does not make them invisible. I'm guessing that the t-sprites are set to invisible internally but that is not working any more. However, changing their cstat directly does make them invisible.

Yes, but I don't know what the cause is. I was trying to set tsprcstat to 32768 in ANIMATESPRITES to make them invisible, but actually it needs to be -1. At least now I have a hack that works.

EDIT: No I don't. Because most of the time, setting tsprcstat to -1 makes the game instantly quit without even a log error.

[Borion]

@Striker Foodobject 17, 18, 19 & jolly meal added to to-do list.

[Borion]

WIP

[NightFright]

Github updated with final nuke barrel.

[NightFright]

Update for slimer egg (558, 675) now also on Github. Hadn't seen those yesterday in my PM.

[Borion]

NightFright, on 27 February 2020 - 02:41 AM, said:

Update for slimer egg (558, 675) now also on Github. Hadn't seen those yesterday in my PM.

No worries, looks like 558 needs small correction anyway. Will send it during weekend.

Cheers!

[Forge]

dear voxel people,
Your generic pole tile # 977 is broke when flipped and seated to the ceiling.
Sincerely,
Anonymous user that does not want to get backlash for trying to help

DC L4 & E1L4

[LeoD]

Forge, on 01 March 2020 - 07:48 AM, said:

Anonymous user that does not want to get backlash for trying to help

I can't remember backlash for reporting issues without swearwords.
It's not the voxels, it's the renderer. Software is OK, Polymost is not.

[Edit:]HRP/MD3 is OK in both Polys, btw.

[NightFright]

Yeah, we had reports about this already. In general, always check with classic renderer. What looks OK there is not a voxel bug if it's wrong in other renderers.

[Borion]

tree1 (908)


I will upload it when tree2 will be done. Makes no sense to replace just one, they are often next to each other.

[NightFright]

This seems to be a complex one. Let's hope it doesn't cause any noticable slowdowns when they are used en masse.