FTE: Trouble with gettaginfo and gettagindex

[drm_wayne]

Im trying to attach a muzzleflash to my viewmodels, but for some reason i cant get it to work,
it always spawns at world origin for no reason.

Does anybody have a working tutorial how i can spawn pointparticles on my bone?
I already looked at fteskels code, but no luck yet...

[Spike]

I'm not entirely sure on your exact situation, but here goes nuffin...

'the' viewmodel isn't normally known to the csqc except via stats. you normally have to just assume that its at pmove_org, if that is also actually known to your client... otherwise you'll have to check what you set VF_ORIGIN to, and just use that. Of course, this isn't entirely accurate if the user has tweaked some cvars and changed cl_gunangle etc cvars, but hey.

alternatively you're using .viewmodelforclient on your ssqc entities. those should end up with RF_VIEWMODEL|RF_DEPTHHACK set.
DP doesn't support RF_VIEWMODEL properly in that it behaves differently from 'the' viewmodel, and requires that the entity is moved along with the player (yeah, pmove_org or VF_ORIGIN is needed for that), whereas FTE just directly displays the entity relative to the view (which yes, means that you need pmove_org or VF_ORIGIN again for any effects spawned from it but at least you don't need it EVERY frame). For this reason you may wish to use just RF_DEPTHHACK and not RF_VIEWMODEL, and just manually position it, then you know exactly where it is. This is especially true if you want to kill that really annoying weapon bob (or if you want to make your own cooler version or whatever).

if its an entity that you spawned in csqc yourself, then how do you not know its origin?

if you're trying to use FTE's 'viewspace' particle property, then those particles should still be spawned in the normal place; they're not viewspace per-se, but rather they just move with the view. On the plus side, this means that the viewspace field is actually a scaler, and you can use smaller values to have them move slower than the view such that they don't go offscreen instantly but also do still lag behind dragged away by the wind, but yes they still need to be spawned at worldspace positions. Imho this looks better than them inheriting some proportion of the player's velocity, even if its not correct (be sure to spawn them in the position from the previously rendered frame, so that they can follow the camera change, and yes they won't work too well with splitscreen).

but yes, if all else fails, you might have some luck with the following:
bonepos = gettaginfo(theentitywithRF_VIEWMODEL, thetagindex);
makevectors((vector)getviewprop(VF_ANGLES));
vector viewspacepos = (vector)getviewprop(VF_ORIGIN) + v_forward * bonepos_x - v_right * bonepos_y + v_up * bonepos_z;
pointparticles(particleeffectnum("te_explosion"), viewspacepos, v_forward, 1);
or some such. I don't remember which way around those vectors are.
(you can transform the tag's orientation too if you need that, same way just ignore the vf_origin part)

but yes, VF_VIEWORIGIN means that the entity is meant to follow the camera. the issue is that the camera is not actually defined by anything other than the short sequence between clearscene/setviewprop(VF_ORIGIN) and renderscene. This means that gettaginfo etc will ignore it.

[drm_wayne]

[toneddu2000]

if I were you I'd create custom physics for shells in CSQC_InputFrame
you could do something like this
pseudocode
cycle trough entities and select only shells classnames
check shell world position: if < RANGE MIN -> return
shell. origin_z --;
shell.angles_x += random(10);

I never used ssqc movetypes in csqc because, usually, they don't work!

PS:fteskel don't use viewmodels but real fps hands models so, setting muzzleflash is easy, but, unfortunately, when player moves the fps model shakes in an ugly way, so in projecUnknown I only "guessed" where player aim point is, depending on weapon type, which sucks. Definately Spike's method is better.

[drm_wayne]

The QC for the shells is similar to the one for shells in shpulds "turboq", and they work in turboq...

[Julius]

Not sure if that helps in your specific case, but transfusion (http://www.transfusion-game.com/ ) has shells that seem to be ejected from view models and the SSQC code works fine in FTEQW. I never looked into the details, so they might spawn from the origin or something like that...

[Spike]

the original version of csqc didn't support movetypes at all (note that the behaviour of thinks depends on movetypes, so thinks didn't work either).
DP's implementation does support thinks but without regard to movetypes, so don't use MOVETYPE_PUSH because you don't really know if it'll use time or self.ltime.
FTE's implementation has multiple modes, that can also apply to ssqc (but with different defaults if the global isn't defined).

mode 0: no physics at all. no thinks either. (ssqc can use StartFrame and do entirely its own physics. yay tracebox.)
mode 1: the engine will call thinks for you, always using time not self.ltime.
mode 2: full ssqc-like thinks.

to change the mode, write to the physics_mode global (CSQC_Init, worldspawn, or really anywhere). note that fteextensions.qc tries to define it as 2, so bear that in mind if you try running the mod in DP. This applies only to the module that owns the global (ie: its not networked, setting it in ssqc applies only to ssqc and NOT csqc. set it in both places separately).
it is possible for a qc compiler to notice that its unreferenced and strip it, so if you want to be certain, just read or (preferably) write it.

it is also possible that its seeing the player's bbox as solid (just because it isn't solid doesn't mean that other things arn't too), getting stuck, and flagging its FL_ONGROUND preventing it from moving even when the player is outside of it.
also, due to hulls, you should probably ensure that you have a setsize line after the setmodel to force it down to point-sized so it doesn't get its traces biased.

[drm_wayne]

[Julius]

That looks pretty awesome. Can you share some more details on the project you are working on? Does it have a public source repo on Github or so?

[toneddu2000]

Sorry drm_wayne, I didn't understand you were using ODE. Awesome effect btw!

[drm_wayne]

[Julius]

Ok, I see. would be still cool if you could share the working code (including the iron sights) if you can find the time. Thanks!

Could be useful for example for that FTEQW based CS1.5 FreeCS project (https://github.com/eukara/FreeCS).

[drm_wayne]

[Julius]

Super, danke

But if you can ever share a really working ODE implementation that would be also awesome!