[NightFright]

Try deactivating texture caching (if you have activated it).

[Hawkeye]

Here's a wierd bug: The new fire effects aren't loading; it's only loading the old sprites.

I've triple-checked; everything is the latest file. Could DukePlus potentially be the culprit?

[Danukem]

Hawkeye, on Jul 1 2009, 02:12 PM, said:

Here's a wierd bug: The new fire effects aren't loading; it's only loading the old sprites.

I've triple-checked; everything is the latest file. Could DukePlus potentially be the culprit?

I updated DP yesterday for that very reason. If you aren't using the very latest full version of DP it will still replace the fire with the old version.

[Hawkeye]

DeeperThought, on Jul 1 2009, 05:57 PM, said:

I updated DP yesterday for that very reason. If you aren't using the very latest full version of DP it will still replace the fire with the old version.

Aha. That makes sense. Though I checked on your page, and the news file said latest update was from 6-13.

being the trusting sort, I took the news page at its word..

Thanks, Deep

[Gambini]

NightFright, on Jul 1 2009, 04:28 AM, said:

Well, screenshots are always helpful.

These are screens i took of some maps of mine, look how the fence overlooks the wall, when the sprite point is right in the center of it. This wasn´t happening in old versions of the HRP

In other news, i strongly hint to change the detail material of all the maskwalls to something black, because many of these are used in usermaps as walls, and these walls have a weird white background when you look them with some distance, when with the original art this background is black.

ah, and i dont know why but pigcops look very small now, a sort of kid pigcops

Attached thumbnail(s)

• 
• 
• 

[Roma Loom]

I don't know why the origin of the fence model in the latest hrp is fuxxored, but it's really fuxxored. The earlier HRP versions were ok.

Changed the fence background to blackish to prevent white artifacts on mipmaps. Thanks for report.

#0913 Fence Download

[Gambini]

Nice to hear, you´ve fixed it.

Other tiles that also should be changed are the fansprite (and its animations) and the grate1 (well, basically all the maskwalls).

[Roma Loom]

And that's where I'm beginning to regret I cannot make submissions to HRP svn

What are the tilenumbers for the textures that need to be fixed (if this is all about white artifacts)?

[Gambini]

Yeah, all about white artifacts:

range 408 to 411 -595 - 596 - 609 - 915 - 1059 - 1113 - 1114

I looked them through the 8bits art , so maybe one or two have not its HRP counterpart.

[Parkar]

Roma Loom, on Jul 3 2009, 11:31 AM, said:

And that's where I'm beginning to regret I cannot make submissions to HRP svn

What are the tilenumbers for the textures that need to be fixed (if this is all about white artifacts)?

I am going to do some work to get the new svn repo ready for both the old HRP and the new polymer HRP sometime during my vacation. Mostly I need to do some clean up, mainly make sure that polymer specifc diffuse textures are called _d so we can have both diffuse and a regular texture in the same folder.

Currently Nightfright is still using my private svn repo for the HRP updates and the one hosted by plagman is only used for polymer HRP.

Once I get it cleaned up we will use the same repository and branch to do both the Polymer and regular HRP. The regular one will simply be achieved by shaving off all the polymer extra stuff. All the regulars that wants to will then be given write access so they can upload new and updated content directly.

[NightFright]

I am sorry, but I cannot reproduce your problem. Please state with which EDuke32 version you are testing. I am using latest official snapshot (March 13), and it is working just fine. And I mean *EVERYTHING*. So no changes will be implemented for now unless I see a real problem.

You are using custom maps, and if the sprite is misaligned there, it is not necessarily a real problem. What really matters is what the official episodes look like, and these appear to be just fine.

[Gambini]

I´m using the same snapshot than you and the model is misaligned from the sprite´s original position. Even if the official maps look okay, they look a little bit different.

I can´t understand why you dont see as a real problem the user map´s incompatibility that these changes introduce. Duke Nukem´s community and fascination have been built around the custom content; read: user maps, mods and enhacements such as Dukeplus and the HRP.
Hoping in a global compatibility could be kind of childish, but being so strict about ¨What really matters is what the official episodes look like¨ isn´t either a wise point.

The fences, as they were before looked okay as much for official or custom maps, so i think that changing them back doesnt hurt anybody.

[NightFright]

The "problem", if you want to call it like that, is just that the fences look really wrong ingame with the new model. It starts right away on the E1L1 roof. I understand and support the need to make it look right everywhere, of course, but we shouldn't add stuff that corrects something at some places and breaks them somewhere else instead. This should be checked thoroughly, but currently I think it would not bring real advantages. Maybe another edit of the model could help.

[Roma Loom]

The only place where new fence looks wrong is the E1L1 rooftop. This should be corrected through the hack imo. Displacing the origin of the model just for one map is wrong.

[NightFright]

Roma Loom, on Jul 7 2009, 11:10 AM, said:

The only place where new fence looks wrong is the E1L1 rooftop. This should be corrected through the hack imo. Displacing the origin of the model just for one map is wrong.

Maybe one of you could attach screenies with fences from official maps so I can check some when I am at home? Thanks.

[Roma Loom]

ArtTile 0913 was found in:

E1L1.MAP as a sprite @ -26446,14635 - Standing on the edge, Misaligned
E4L2.MAP as a sprite @ 23872,-4864 Shop-N-Bag Part, Standing on the asphalt, Ok
E4L3.MAP as a sprite @ -14656,30976 Shop-N-Bag, Standing on the asphalt, Ok
E4L11.MAP as a sprite @ -42368,16512 Area 51, Standing on the ground, Ok

[NightFright]

Misaligned with NEW model, you mean?

[Roma Loom]

yes

[NightFright]

And these are all places where the fence actually appears ingame, I take it? --> If so, I will probably have to write hacks for E1L1 fence. But it should be no problem.

Regarding definitions:
I see your included defs are basically identical to the existing ones, except for the detail texture has been removed. This was done purposely, yes?

[Roma Loom]

ah shit... I've just repacked old zip file and haven't noticed what was in def file. Ignore the def file in zip completely.

[NightFright]

Have you changed anything on the #913 texture or is that one identical to the existing one, too?

[Roma Loom]

Changed the background color (which is beyond transparency borders) to dark.

[NightFright]

Check new beta versions:

> HRP Update v4.2 beta (July 7), 15 MB
> Maphacks v4.2 beta (July 7), 135 KB

Changes:
> new #913 model/texture (corrected alignment/transparency)
> new hacks for e1l1.mhk

I think the new fence texture causes transparency issues at the joint points of the model version. Otherwise, the new hacks should keep E1L1 rooftop fence properly aligned.

You can also check the new E1L1 maphack in the HRP wiki (see "OVERRIDE" section).

[Piterplus]

Texture 2492_version.png says "Version 4.2 (september 1, 2009)".
Probably you have something special in mind when you wrote it?

P.S. Fence looks in place now with new maphacks.

[NightFright]

Piterplus, on Jul 8 2009, 10:42 AM, said:

Texture 2492_version.png says "Version 4.2 (september 1, 2009)".
Probably you have something special in mind than you wrote it?

P.S. Fence looks in place now with new maphacks.

This was done on purpose. I will always pre-date betas to the estimated release for the final version. v4.2 tells you nothing about the current additions to the update, it is just to mark the new version for now.

[Danukem]

Lately I'm getting these def errors:

Loading 'dukeplus.def'
Invalid frame name on line highres/sprites/props.def:1587
Invalid frame name on line highres/sprites/props.def:1965
Invalid frame name on line dukeplus.def:172
Invalid starting frame name on line dukeplus.def:173
Invalid frame name on line dukeplus.def:174
Invalid starting frame name on line dukeplus.def:175
Invalid frame name on line dukeplus.def:176

The first two are HRP errors, the rest pertain to Duke Plus. But the Duke Plus errors are from the HRP model definition for the pistols. Has this changed recently? Specifically, have any of the frame names for the pistol changed? Here is what I have in the relevant part of dukeplus.def:

model "highres/sprites/firstperson/2524_pistol.md3" {
scale 1.9
skin { pal 0 file "highres/sprites/firstperson/2524_pistol.png" }
glow { file "highres/sprites/firstperson/2524_pistol_g.png" }
frame { name "idle" tile 2524 }
anim { frame0 "fire1" frame1 "fire2" fps 60 flags 0 smoothduration 0.0 }
frame { name "fire1" tile0 2525 tile1 2526 smoothduration 0.0 }
anim { frame0 "reload1" frame1 "reload3" fps 16 }
frame { name "reload1" tile0 2528 tile1 2529 }
hud { tile0 2524 tile1 2526 xadd -0.15 yadd 1.32 zadd -0.56 angadd -37 }
hud { tile0 2528 tile1 2529 xadd -0.15 yadd 1.36 zadd -0.68 angadd -37 }
hud { tile0 2524 tile1 2524 xadd 0.1 yadd 0.55 zadd -0.56 angadd -37 flipped }
hud { tile0 2525 tile1 2526 xadd 0.12 yadd 0.4 zadd -0.56 angadd -37 flipped }
hud { tile 2528 xadd 0.15 yadd 0.2 zadd -0.68 angadd -37 flipped }
hud { tile 2529 xadd 0.15 yadd 0.0 zadd -0.68 angadd -37 flipped }
}

It complains about the firing and reloading frames, but the strange thing is the pistols work fine in game...

[supergoofy]

in the latest hrpupdate pistol definition is changed, look here:

http://forums.duke4.net/index.php?showtopi...amp;#entry23467

the first error:
Invalid frame name on line dukeplus.def:172

can be fixed by changing the line 173 to:
frame { name "Frame0" tile 2524 }

[Danukem]

supergoofy, on Jul 11 2009, 11:12 AM, said:

in the latest hrpupdate pistol definition is changed, look here:

http://forums.duke4.net/index.php?showtopi...amp;#entry23467

the first error:
Invalid frame name on line dukeplus.def:172

can be fixed by changing the line to:
glow { file "highres/sprites/firstperson/2524_pistol_g.png" }

No, line about the glow has not changed, and at any rate the errors are about frame names, not file names. But thanks for the corrected definition with the new frame names, that should clear it up. I still don't understand why the bad definition seems to work, though.

Anybody know what the deal is on these?

Invalid frame name on line highres/sprites/props.def:1587
Invalid frame name on line highres/sprites/props.def:1965

[supergoofy]

I don't have the props.def errors

only dukeplus.def has errors in lines 172,173, 174, 175, 176

I'm using duke3d_hrp.zip v4.0 and hrpupdate.zip v4.2 beta

using dukeplus 2.03

[Danukem]

supergoofy, on Jul 11 2009, 12:02 PM, said:

I don't have the props.def errors

only dukeplus.def has errors in lines 172,173, 174, 175, 176

I'm using duke3d_hrp.zip v4.0 and hrpupdate.zip v4.2 beta

using dukeplus 2.03

I have fixed all the dukeplus.def errors, but I still get the props errors in the HRP even with the v4.2 beta update. Maybe my copy of the HRP main pack is the problem.