Weird glitch hud models

I just finished E2L4, and in E2L5 the hud models are gone. You can still fire, and the pipe bomb suddenly falls, the devastator missiles fire, but there's just nothing there. A new game brings them back. Quit, restart and then load in E2L5 and they are still gone. Dnscotty from E2L5 to any level and they're back again, so I'm guessing they'll be back when I finish E2L5 and I arrive in E2L6, but am not sure of this. Will deliver report once I finish it, which will take a little while...

...I'm finishing up chapter 7 of my Duke FF over in the Duke Nukem forum which I will post later tonigh, and just decided to play a little piece as diner is almost ready. Anyway, anyone understand this? What it is? How it happened? And how to make sure it doesn't happen again - imagine this happening when all the weapons are models.

[Parkar]

You have just found another sprite 0 maphack. Since all hud sprites use sprite number 0 fixing the first sprie on the map ****s the weapons as well.

yeap, nv googles are sprite 0 as well. just reomve that line from the maphack to fix it.

Now a blue access mechanism is half in the wall and sticking out though, of course, I don't know if was doing that before I removed the hack.

[Parkar]

It most probably was since the hack that was the problem was a pair of nv goggles.

In that case, it needs another map hack, heh.

[Chip]

And so, I stumble upon this thread to say there is another map hack in order "E3l...whatever" (Tier drops)

[crazyjoe17]

i have the solution to this whole problem.....just get eduke32 and edit it somehow...

[Parkar]

crazyjoe17 said:
i have the solution to this whole problem.....just get eduke32 and edit it somehow...

Edit what somehow? The map (wich one? (cant reditribute the maps anyway)) edit eduke32?

[Parkar]

Chip said:
And so, I stumble upon this thread to say there is another map hack in order "E3l...whatever" (Tier drops)

Could you perhaps be a bit more specific?

[Chip]

It has allready been explained.

But if you want to re-visit my original comments then click the link below.

http://forums.3drealms.com/ubbthreads/sh...p;page=0#838697

[Parkar]

Ok, then its been noticed already.

OK I've read through this thread and I know what bug it is you're talking about (I get it on E1L2, and probably others but I haven't checked). So how exactly can you fix it? I've tried adding a sprite 0 line to the E1L2 map hack and it doesn't rotate the models at all. And without it, it doesn't work then either. I've also tested it on E1L1 and the models rotate properly, but it still doesn't affect E1L2 (not that I expected it to, but its just as well to check). Any help?

[Parkar]

You are suposed to remove any sprite 0 hacks not add them.

[Dr. Kill]

Parkar said:
You are suposed to remove any sprite 0 hacks not add them.

how did those come about anyway, since they only mess things up.

[Parkar]

Probably cos they were made before there were any 3dmodels in the hud so no one noticed it. The pack was never realy tested that much after adding them so it was never noticed. Its this kind of stupid errors I woud like to avoid in the next version by having at least one week (preferably more) of just testing it before releaseing it.

Ah I found it! There was one hidden away in the map hack between two other defs (for the same model).

[Awesoken]

FYI: the "sprite 0 maphack" bug is fixed in the latest JonoF release (20050531). HUD models now use a separate animation state index from the world sprites, meaning you can safely re-enable the map hacks for sprite index 0.

There will still be issues when you have 2 or more HUD models on screen though. <font color="black">Advanced users only : ) To correct for this, I put a system in place so you can assign a unique id to each HUD function call (rotatesprite). Unfortunately, the hacks must be applied to the source code itself. First, you find the rotatesprite call that is drawing the HUD piece that you're interested in. Then, put this right before the call: "guniqhudid = 1;" ... or choose any unique number from 0 to MAXUNIQHUDID-1, but preferrably not 0 since that is the default. After the rotatesprite call, you should set guniqhudid back to 0.</font><font color="#666666">: )</font>

[Killd a ton]

yay

[TerminX]

Awesoken said:
Advanced users only : ) To correct for this, I put a system in place so you can assign a unique id to each HUD function call (rotatesprite). Unfortunately, the hacks must be applied to the source code itself. First, you find the rotatesprite call that is drawing the HUD piece that you're interested in. Then, put this right before the call: "guniqhudid = 1;" ... or choose any unique number from 0 to MAXUNIQHUDID-1, but preferrably not 0 since that is the default. After the rotatesprite call, you should set guniqhudid back to 0.

Neat trick. I've now implemented it via CONs in EDuke32 -- I figured I might as well, considering I give direct access to rotatesprite anyway.