(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 

c0burn gets the Preach award for April. 

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. 

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. 

Quick and dirty memory management? in MY C code? It's more likely than you think! 

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? 

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. 

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. 

OTP, if your definition of 'decent' is one that leaves things crippled and requires obtuse workarounds, then that's your problem, not mine. 

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 

Use the pr_dumpplatform command and then just read through the resulting qsextensions.qc file if you want a list of the added qc extensions. Read the included comments if you want to figure out how to actually use it.

For particle effects, you can find some specs on fte's svn, or if you're sticking to dp-compatible stuff then you should be able to find info on that stuff on dp's site somewhere. 

Use the pr_dumpplatform command and then just read through the resulting qsextensions.qc file if you want a list of the added qc extensions.

Does this actually work in QSS? I can't find the resulting qc file 

you mentioned once that CSQC for custom HUDs could be coming for QSS - is this still planned? 

Now here is another thing:
Today I was testing and I noticed that no matter what ever T_Damage value I set for W_FireJazzAxeJazzaxe deals the same damage as in FireAxe.

I had set damage 40 for jazzaxe earlier and today I noticed it took me the same amount of hits to kill a shambler with the regular axe and jazzaxe.

Then I changed the regular axe damage to 600 and both axes kill the shambler instantly.

How do I fix this?
I want the jazzaxe to replace the normal axe like with the hammer in quoth and the jazzaxe should deal its own damage.
How do I do that?

(also I seem to have figured out how to add sounds like when you hit an enemy in AD and Drake.) 

I can't be sure without seeing the code but it sounds like W_FireJazzAxe isn't being called.

First step would be checking W_Attack further down in weapons.qc and checking that your (presumed) if (self.weapon == IT_JAZZAXE) clause is pointing to a different player animation function than the normal axe.

If it is, then check that the relevant function in player.qc contains W_FireJazzAxe() instead of W_FireAxe() 

add a call to error("function name here"); into both functions.
then you'll see which one is actually getting called.
it should also give you a stack trace, so you can figure out where its getting called from too.

(or if you're using fteqccgui+fteqw, you can just set a breakpoint and then step through the code.) 

The problem was this

void() player_jazzaxe1 = player_axe,not jazzaxe! 

I don't want to clog this thread with my questions so I gave my email. 

It has a search in folders option to let you find every instance of .items2

.items2 was derived from the rogue mission pack since .items ran out of bits. 

So in which file can I find a way to derive?

Do I just add

.float items2 in defs.qc?

Then how do I add stuff to it? 

Ya just add it to defs.qc or anywhere in the compile order before you use it.

Add in any IT2_JAZZYSTUFFBITS = 1, 2, 4, 8, 16, etc flags. The only really tricky bit is in situations like weapons where you need to know when to check .items and when to check .items2 or you'll be able to switch to weapons you don't have, or accidentally give yourself quad or something. 

if a trigger_teleport has multiple destinations with the matching targetname, it will always pick what I assume is the the one that is loaded first in the map and therefore has the lowest index of some sort that the find function looks for. I'm not really sure how it works since find is only defined as #18 in the code. I'm not very well versed in qc or regular c for that matter. I implement stuff by deriving heavily from existing code, so I'm at a loss here.

I need a more thorough find function that takes an additional index parameter that returns the first entity whose targetname and index match the given arguments. Then I would only need access to the amount of entities with that targetname and could generate a random number between 0 and that amount to use as the index argument.

I assume the reason find isn't defined in qc is that the the finding process can only be done by the engine, which would be a death sentence for my mod. I stand even less of a chance of understanding complex engine code than qc, and even if I did manage it the mod would be dependent on my custom engine branch which would make it an even harder sell to potential players.

I'm pretty much ready to throw in the towel, but I figured I'd try consulting the mighty code wizards first. Is there a way you could see making random teleportation work without engine modifications?