 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
W_BestWeapon
Add if at the bottom if (self.items & IT_JAZZAXE) return IT_JAZZAXE; else return IT_AXE; And just below that in W_CheckNoAmmo: inside the if (self.weapon == IT_AXE add "|| self.weapon == IT_JAZZAXE") float() W_CheckNoAmmo =
{ if (self.currentammo > 0) return TRUE; if (self.weapon == IT_AXE) return TRUE; self.weapon = W_BestWeapon (); W_SetCurrentAmmo (); // drop the weapon down return FALSE; }; hmm what about ‘rankforweapon’ function?
im just thinking off the top of my head been awhile since i did the ol double tap impuls to switch weapons; i had once made the lg double as a flame thrower you might need to add your axe there too Have you looked at client.qc?
There's a line if(time > self.attack_finished && self.currentammo == 0 && self.weapon != IT_AXE) { self.weapon = W_BestWeapon (); W_SetCurrentAmmo (); } I suspect you need to change that last test to also consider IT_JAZZAXE. I am sorry.It does not work.Still switching after a second.
I am going to try and hunt down the warpspasm decompiled code I gave someone when I played Quake 2 years ago before going to Half-(my)-Life. But please,try helping me.I might feature you in my mod. What did you change it to? Was it this:
if(time > self.attack_finished && self.currentammo == 0 && self.weapon != IT_AXE && self.weapon != IT_JAZZAXE ) You have saved me a complete rewrite.
Now,the world shall remember you as the savior of QuakeC. Go Preach! They also will ask questions like these.Why?
Those idiots are my classmates! I created this PDF from a forum post on QuakeOne. This may be useful information for users new to QuakeC.
http://www.quaketastic.com/files/QuakeC_Tutuorial_by_MadGypsy.pdf The way I found the problem line for the jazz axe was searching the entire sourcecode for every example of the keyword IT_AXE, which lead me to the one you hadn't changed yet.
(from discord chat, I've chopped it down to just give the salient points)
Kinn - Today at 10:19 AM I've had the "grenades occasionally clip straight through shamblers" bug plenty of times in vanilla quake. I'd totally forgotten it was a thing. Is it still a thing in QS etc? c0burn - Today at 8:18 PM entities are re-used when an entity is removed, not all fields are cleared the shambler code sets self.owner = lightningbolt [editors note: player then fires a rocket/grenade, spawning a new entity just after the lightning ent has been removed] c0burn - Today at 8:21 PM the shamblers so it passes straight through c0burn - Today at 8:21 PM you can just set self.owner = world to fix it when the bolt is removed or not set self.owner really it should be bolt.owner = shambler Kinn - Today at 8:27 PM holky fuck The Shambler needs to store a "link" to the lighting flash, just so that it can refer to it over the next few frames in order to animate it. There is no special reason why the Shambler has to use the ".owner" field to create this link. It could have used another entity field. Using
IMO however, the cleanest fix would be to not actually require the Shambler and flash to be linked like this - I would personally simply spawn the flash, and make it animate by thinking for itself (like the rocket explosion does.) BONUS POINTS: notice also that whilst this is all kicking off, the Shambler sets self.effects = self.effects | EF_MUZZLEFLASH; This has the (probably unwanted) side effect of disabling animation interpolation on the Shambler during its lighting attack. If you made the lightning flash animate itself, as suggested earlier, you could also throw the muzzleflash effect on the flash ent instead of the shambler, controlling it through the flash anim functions. This will re-enable anim interpolation on the Shambler, and disable it on the flash - which is kind of what you want. when an entity is removed, not all fields are cleared
To expand on this part a bit: behind the scenes entity variables store a number. That number represents how far down that entity is in the list of entities - it's also the number you'd use with the edict command to print it, so the number isn't entirely hidden. Suppose the lightning entity is number 666 on the list*. When the shambler spawns the lightning, it stores the number 666 in its owner variable. When the lightning gets removed, all of the data in slot 666 is cleared**, but the shambler entity isn't modified in any way. So the number 666 stays in place. The only thing that will ever clear the value 666 is if the shambler spawns another lightning bolt, which will replace 666 with a new entity number. Until that happens, any entity which spawns in position 666 will be the shambler's owner (and so noclip through it). An entity slot won't be reused until 0.5 seconds has passed since the previous occupant was removed, so firing a rocket half a second after the lightning disappears is the easiest way to reproduce the bug. The only reason this is really a problem is because the engine does special things with the owner field. In a normal entity field, the value 666 hanging around would be completely benign, as the shambler never does anything with the field except during the window where the lightning is spawned. So just changing the entity field the value is stored in will be enough to handle the bug. *pedants corner: assume we're using an engine with raised limits so that entity 666 is valid. **in fact in the original implementation, only a small amount of the data is cleared at the point when the entity is deleted - just enough to prevent it affecting the game further. The real deep clean of the data only takes place when the slot is reused. Until then you can access most data from the "ghost" of the previous entity - but don't ever depend on that behaviour as engines are liable to change it. Just something to be aware of when trying to debug issues.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |