#2475 posted by R00k on 2018/04/06 02:50:10
in checknoammo shouldint you also add if(self.weapon == IT_JAZZAXE) return; ?
#2476 posted by R00k on 2018/04/06 02:51:10
otherwise it says you have no ammo jump to SG
#2477 posted by R00k on 2018/04/06 02:51:10
otherwise it says you have no ammo jump to SG
TRIPPLE POST FTW
#2478 posted by R00k on 2018/04/06 02:52:51
if ((self.weapon == IT_AXE) || (self.weapon == IT_JAZZAXE))
return TRUE;
.
#2479 posted by ijazz3 on 2018/04/06 13:56:12
@rook
Yes,I added that.It sill switches to SG after showing JAZZAXE for a split second.
#2480 posted by anonymous user on 2018/04/07 04:24:20
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
Suggestion
#2481 posted by Preach on 2018/04/07 09:13:59
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.
......
#2482 posted by ijazz3 on 2018/04/08 18:32:42
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.
Just Checking
#2483 posted by Preach on 2018/04/09 21:11:20
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 )
Thank You Sir
#2484 posted by ijazz3 on 2018/04/11 19:28:51
You have saved me a complete rewrite.
Now,the world shall remember you as the savior of QuakeC.
Go Preach!
Lol, Preach Is Always The Qc Master
#2485 posted by Qmaster on 2018/04/12 16:24:06
You Guys Might See 4 Teens Around 14-15 Age.
#2486 posted by ijazz3 on 2018/04/14 09:58:09
They also will ask questions like these.Why?
Those idiots are my classmates!
PDF For Beginners
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
Seconded That
#2488 posted by Preach on 2018/04/14 19:25:18
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.
PUBLIC SERVICE ANNOUNCEMENT
#2489 posted by Kinn on 2018/04/19 21:50:27
(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 .owner field is set to your rocket
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
Aaand
#2490 posted by Qmaster on 2018/04/19 22:07:28
c0burn gets the Preach award for April.
FURTHER RUMBLINGS
#2491 posted by Kinn on 2018/04/19 22:30:00
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 .owner for this is a pretty dumb hack and as we can see, just invites bugs.
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.
Some Extra Detail
#2492 posted by Preach on 2018/04/20 00:21:43
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.
#2493 posted by PRITCHARD on 2018/04/20 06:13:34
Quick and dirty memory management? in MY C code? It's more likely than you think!
Concatenate Strings?
#2494 posted by lokus on 2018/04/29 23:14:03
I'd like to make an entity's targetname consist of two strings that both contain targeting information, but there doesn't seem to be an obvious way to concatenate strings. strcpy() and strcat() are unavailabe, and I haven't found a single example in the id code where concatenation is used.
Is there any other way to create a targetname from two strings I'm unaware of, or do I have to use a seperate field for the second string?
Separate Fields
#2495 posted by Preach on 2018/04/29 23:30:10
Standard QC doesn't contain a way to concatenate strings, all strings are immutable things that you have to just take as they come. There are some complicated ways to output combinations of strings or characters to the console or the screen, but they can't be employed for logical string comparison in a sensible way.
Abandon All Hope Ye Who Concatenates Strings
#2496 posted by Spike on 2018/04/30 00:13:52
the vanilla engine has only two ways to concatenate strings.
The first is that some of the builtins that accept a 'single' string argument will perform an implicit strcat. this is useful primarily for centerprint, but also works with bprint+sprint+error+objerror too.
The second is that console prints don't have any implicit new-lines, so you can just call sprint 50 different times to construct a single line. There are numerous mods out there that do things like this in order to try to print various numbers etc.
Other than that, you're screwed. Have a nice day.
If you're okay with requiring engine extensions, fte+qss+dp all have strcat builtins, and are all mostly compatible.
However, note that each of these engines have different temp-string behaviour. Strings in QC are essentially just pointers, so the memory that the pointer/string refers to can actually change and contain some other string entirely (usually as a result of calling other builtins that return temp-strings).
vanilla: ftos and vtos both return the exact same bit of memory, with every single call.
qs/qss: multiple temp strings - after 16 different temp-string-returning builtins have been called (from anywhere) it'll start reusing
the oldest temp-string. Use strzone if you want it to last longer.
dp: unlimited temp strings - call strcat or whatever as much as you want, but they'll ALL be forgotten once the QC returns to the engine, so ANY field or global that contains a tempstring will cause warnings when saving the game, etc. Use strzone still to avoid that.
fteqw: persistent temp strings - call strcat or whatever as much as you want. Store them in fields too, if you want.
Actually, there is a way to do strcat even in vanilla, but its so evil, obtuse, and just generally annoying that I'm not going to describe it. It also breaks compatibility with almost every other engine too, and can even be broken by just the C compiler that the engine was compiled with!
So if you're explicitly targetting vanilla and your targetname thing, just use two fields.
Whereas if you're doing more complex stuff, then you'll need to get people to stop using vanilla or quakespasm, and start using a decent engine instead that actually supports strcat (probably qss, because its basically just a super-set of quakespasm making it an easier engine to 'sell').
get people to stop using vanilla or quakespasm, and start using a decent engine instead
Eat shit, you gigantic self-fellating cuntflap of a non-person.
#2498 posted by Spike on 2018/04/30 01:19:53
OTP, if your definition of 'decent' is one that leaves things crippled and requires obtuse workarounds, then that's your problem, not mine.
#2499 posted by muk on 2018/04/30 04:41:56
Your engine can have every thing ever requested by mappers and players alike and itd be nullified by the lack of documentation.
Want us to make the switch? Create some documentation. Make the source easier to access. I have reasons to use your engines but the lack of documentation is a huge turn off
|