EDuke32 1.4.0 beta 2 released

[NightFright]

OK, I have modified all HUD models in firstperson.def in order to be correctly aligned ingame. Note that the shotgun looks much better now, for you see more of the grip part. Chaingun is fixed as well.
I recommend thorough playtesting in order to verify my modifications (for insiders: I have only modified the "zadd" parameters).

I recommend you backup your existing highres\sprites\firstperson.def before using this one. Keep in mind that if you use this new def file, you won´t be able to use any other engine than eDuke32 v1.4.x - current jfDuke3D or earlier eDuke32 releases will give you messed up HUD models!

Because I couldn´t fully check everything, you should especially check if
- Slimecrunch (the slimers jumping into your face)
- crack knuckles (if you do nothing)
- key card hand
are aligned correctly with these new zadd values.

Two things about v1.4.0:
- The weapons look kinda distorted/"squeezed" when you are using the full-size HUD - minimized version looks better.
- No Duke Talk when you select difficulty setting - even when setting "Duke Talk" to "All".

[Sang]

Can someone mirror this snapshot? It looks like it'll be downloading until early next week.

There's still a little bug in Mapster though - If you look at a floor or ceiling from some distance and for example want to change the shade of it - It'll change the shade of the nearest wall instead. Sucks!

[Iggy]

Originally Posted by Sang

Can someone mirror this snapshot? It looks like it'll be downloading until early next week.

There's still a little bug in Mapster though - If you look at a floor or ceiling from some distance and for example want to change the shade of it - It'll change the shade of the nearest wall instead. Sucks!

Isn't that the eon old selectionbug at work?

[Sang]

I wouldn't know. So if it's eon old, why is it still not fixed?

[Geoffrey]

Originally Posted by NightFright

OK, I have modified all HUD models in firstperson.def in order to be correctly aligned ingame. Note that the shotgun looks much better now, for you see more of the grip part. Chaingun is fixed as well.
I recommend thorough playtesting in order to verify my modifications (for insiders: I have only modified the "zadd" parameters).

I recommend you backup your existing highres\sprites\firstperson.def before using this one. Keep in mind that if you use this new def file, you won´t be able to use any other engine than eDuke32 v1.4.x - current jfDuke3D or earlier eDuke32 releases will give you messed up HUD models!

Because I couldn´t fully check everything, you should especially check if
- Slimecrunch (the slimers jumping into your face)
- crack knuckles (if you do nothing)
- key card hand
are aligned correctly with these new zadd values.

Two things about v1.4.0:
- The weapons look kinda distorted/"squeezed" when you are using the full-size HUD - minimized version looks better.
- No Duke Talk when you select difficulty setting - even when setting "Duke Talk" to "All".

The devastator and the freezer don't show up here and ya, the weapons do look squeezed

[Parkar]

Originally Posted by Sang

I wouldn't know. So if it's eon old, why is it still not fixed?

The reason it happens is that the polymost rendered image does not match the classic view perfectly. It's aperantly not an easy thing to fix.

[Piterplus]

@Nightfright.
Yes, this way is much better.
I advise to make chaingun and shrinker not too advanced forward, bacause edjes of models became visible in movement.
For chaingun try :
hud { tile0 2537 tile1 2540 xadd -0.26 yadd 0.51 zadd -0.4 angadd -24 }
for expander:
hud { tile 2554 xadd -0.1 yadd 0.64 zadd +0.9 angadd -20 }
hud { tile 2555 xadd -0.1 yadd 0.64 zadd +0.85 angadd -20 }
shrinker:
hud { tile 2556 xadd -0.1 yadd 0.64 zadd +0.9 angadd -20 }
hud { tile 2557 xadd -0.1 yadd 0.64 zadd +0.85 angadd -20 }
for shrinker crystall:
hud { tile0 2558 tile1 2561 xadd -0.04 yadd 0.38 zadd 1.15 angadd -20 }
hud { tile0 2559 tile1 2561 xadd -0.04 yadd 0.38 zadd 1.1 angadd -20 }

Also in attachment little magic file which helps to remove old sprite shaingun

[DeeperThought]

This file incorporates Piterplus' revisions into Nightfright's edit of firstperson.def

I have not tested any of this, I just copied and pasted from the post.

firstperson.zip

[KillerBudgie]

Originally Posted by Piterplus

@Nightfright.
Yes, this way is much better.
I advise to make chaingun and shrinker not too advanced forward, bacause edjes of models became visible in movement.
For chaingun try :
hud { tile0 2537 tile1 2540 xadd -0.26 yadd 0.51 zadd -0.4 angadd -24 }
for expander:
hud { tile 2554 xadd -0.1 yadd 0.64 zadd +0.9 angadd -20 }
hud { tile 2555 xadd -0.1 yadd 0.64 zadd +0.85 angadd -20 }
shrinker:
hud { tile 2556 xadd -0.1 yadd 0.64 zadd +0.9 angadd -20 }
hud { tile 2557 xadd -0.1 yadd 0.64 zadd +0.85 angadd -20 }
for shrinker crystall:
hud { tile0 2558 tile1 2561 xadd -0.04 yadd 0.38 zadd 1.15 angadd -20 }
hud { tile0 2559 tile1 2561 xadd -0.04 yadd 0.38 zadd 1.1 angadd -20 }

Also in attachment little magic file which helps to remove old sprite shaingun

What and where in the blue hell am I supposed to put the attached file?

[DeeperThought]

It goes in Duke3d_hrp.zip

The file has a folder path to let you know where to put it within the zip.

[KillerBudgie]

Do you know exactly where to put it? I haven't the faintest idea, as it just puts under the highres directory

[NightFright]

It´s quite easy. Your HRP zipfile structure is

highres\sprites

There, you´ll find the file firstperson.def. My file is already placed into that folder, so you extract it and put that highres folder *AS IS* into your HRP file. Done.

@ Piterplus:
THX for the corrections. I know that with my def modification, the shotgun had a little glitch when reloading - you could eventually see the rear "end" of the model which shouldn´t occur (part of the trigger, the complete trigger wasn´t modelled).
But how the heck is your "fix" for the chaingun supposed to work? AFAIK, you can only load either the model OR the high-res sprite. Using your image with the model is absolutely DEADLY, for the skin is missing, then.

[Piterplus]

You got me wrong - it is texture. I defined this fake in usial way (definetexture 2536 0 0 0 -1 -1 highres/textures/2536.png) and it works - because as Parkar said (and screenshot was posted in this thread ) both model and sprite shows ingame, hence after replacing the sprite with 1 pixel transparent dummy it became invisible. To be more exact we replace only base part, because hud chaingun consist from three sprites - base and animated barrels. Now we see only model , and beneath model we may see floor where previously was old sprite.
As for deadlines of this - I can see no problem, lot of switches we have as models and as textures simultaneously without any glitches.

[NightFright]

OK, I got your fix image working now, and it´s quite necessary, as I might add - in the full HUD version, you would still see the sprite chaingun without it.
There is a line with "hud { tile 2536 hide }", but obviously, it won´t help a bit (that´s why I have commented that one out now).

The file added below includes all fixes posted here until now with some additional (yet minor) improvements.
I have fiddled around with chaingun and shotgun defs a little bit more. I hope this is more like the real thing. Perhaps someone could create the shotgun model portions that are "behind" the parts we currently see (at least completing the trigger part) in order to avoid glitches. The shotgun model is really good... if you get to see more of it!

[DeeperThought]

Before I apply Piterplus's chaingun fix, I want to know whether the low-res mode will still display correctly with it (i.e. will the top of the low-res chaingun be cut off?)

[NightFright]

I don´t think so. More likely... you won´t see any chaingun at all. LOL

I do not know what you mean with "low res mode"... you mean normal eDuke/jfDuke without any models/textures? That should work. But if you wanted to use high-res textures without models... hmmm...

[DeeperThought]

Originally Posted by NightFright

you mean normal eDuke/jfDuke without any models/textures?

Yes. Low-res as in no hi-res pack.

[Piterplus]

In classic mode there will be no difference, since it will affect only hrp.

[DeeperThought]

Originally Posted by NightFright

The file added below includes all fixes posted here until now with some additional (yet minor) improvements.

I had incorporated these files into my hi-res pack without effect. Then I realized it was because hrp_update109 has its own firstperson.def and it was overriding the fixed one I had put into the main pack. Moral: if you use the hrp update, put the fixes in the update.

[Ding Bat]

Originally Posted by DavoX

I think it's a well known fact that everytime TerminX gives a link to a snapshot you gotta try a few times to get it right .

Works fine for me the first time and DSL fast, even with Verizon DSL.

[The Commander]

HA HA HA, If you live in New Zealand and you have a DSL youl think any where else in the world for internet conection is Heaven. Im sure even antartica is faster than us in the NZ!

[TerminX]

http://www.eduke32.com/stuff/eduke32...t_20060514.zip

Changes some weapon stuff, fixes a couple of minor bugs, and draws the HUD models distorted as they are in the previous version and in JFDuke3D until a better solution is ready.

[DeeperThought]

Does this snapshot fix the bug related to projectile manipulation?

[TerminX]

The bug was in the shoot() function in the source. It should be fixed.

[NightFright]

LOL I guess that makes all the changes we recently made quite worthless! Good I kept a backup of the old defs.

Oh, and something else I noticed: With latest Mapster32 (the one that came with your first beta 1), I cannot load HRP any more with the editor. I haven´t changed anything in duke3d.def, and it worked with any previous Mapster32 versions. Did you change anything with about the HRP content is loaded? I only get normal Polymost stuff now, it´s not even 3D accelerated.

[TerminX]

Seems to work just fine for me.

[NightFright]

Well, I have decided not to go fully back to old HUD weapon defs. I have tried to make all models visible a little bit more. Shotgun and Freezer probably are the most improved ones (at least in minimized HUD mode).

Use this file with TerminX´s very latest eDuke32 v1.4.0 beta release and tell me what you think...

[kaotic_oz]

In mapster is there a button command to delete all of one specific sprite?

[TerminX]

kaotic_oz: ' D in 2D mode

[kaotic_oz]

Thanks now I can fix this problem I found in one of my maps!

[NightFright]

Regarding my Mapster32 problem: I had replaced "build.cfg" as well and forgot to change "bpp = 8" to "bpp = 32". An almost classic mistake.

[TerminX]

Originally Posted by NightFright

Regarding my Mapster32 problem: I had replaced "build.cfg" as well and forgot to change "bpp = 8" to "bpp = 32". An almost classic mistake.

A classic mistake resulting in classic rendering. Oh, the irony.

[kaotic_oz]

haha lol!

[Tea Monster]

Hey TeminX. I saw the changelog for the new version of Eduke. Looks awsome, especially the multiplayer stuff. Thanks!

[DissidentRage]

Just imagine when someone announces they have a multiplayer mod going.

/me coughs

What?

[DeeperThought]

I'm trying to track down the source of this warning caused by my CON mod:

GAME.CON: At top level:
GAME.CON:10404: warning: expected a action, found a actor.

Whatever it is, it doesn't seem to cause any problems in the game. If there is actually an error of this type, I don't understand why game.con would compile at all.

When it says, "At top level", what does this mean exactly? Also, is 10404 the code for this type of problem, or is it the line number on which it occurs, or what?

[TerminX]

The line number. It would have been an error, but there were a lot of DOS Duke mods with horrible errors like that in their CON files, so I had to write code to correct the error during compile rather than merely bitch about it.

[DeeperThought]

I see. Well, the downside of the fact that it's been compiling all this time, is that I don't know how long the error has existed, so I don't know where to look for it. The line number it gives doesn't seem to correspond to anything in the source files. Is there any way to get the compiler to put more information in the log file, like printing the actual line of text from game.con where the error occurs?

[TerminX]

Run EDuke32 with the "-z3" command line parameter and look through the resulting eduke32.log.

[DeeperThought]

Yes, that helped. Turned out that it didn't like this line:

ai BARRIERFACE BARRIERON faceplayer

...because it was missing the move parameter.