FTE: Trouble with gettaginfo and gettagindex

Discuss CSQC related programming.
Post Reply
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

FTE: Trouble with gettaginfo and gettagindex

Post by 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
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: FTE: Trouble with gettaginfo and gettagindex

Post by 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? :o

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
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: FTE: Trouble with gettaginfo and gettagindex

Post by drm_wayne »

Works... kinda... My SHells spawns at the bone, but are freezing in mid air and not dropping to the floor... any idea??

Code: Select all

float() shellcasing_predraw =
{
	if(time > self.shell_timeout)
	{
		remove(self);
		return PREDRAW_NEXT;
	}	
	return PREDRAW_AUTOADD;
}

/*
====================
View_shellcasing_spawn
====================
*/
entity() View_shellcasing_spawn =
{	
	vector bonepos = gettaginfo(vmodel, gettagindex(vmodel,"WJ_EjectShell"));
	makevectors((vector)getviewprop(VF_ANGLES));
	vector viewspacepos = (vector)getviewprop(VF_ORIGIN) + v_forward * bonepos_x - v_right * bonepos_y + v_up * bonepos_z;			
	
	entity shell = spawn();
	setmodel(shell, "models/weapons/45acp_shell.iqm");
	setorigin(shell, viewspacepos);
	shell.solid = SOLID_NOT;
	shell.movetype = MOVETYPE_TOSS; //for some reason fte gives a fuck about that... the fucking shell just gets freezed in the air...
	shell.velocity = v_forward * 35 + v_up * (70 + random() * 60) + v_right * (70 + random() * 60);
	shell.avelocity = randomvec() * 180;
	shell.predraw = shellcasing_predraw;
	shell.drawmask = MASK_ENGINE;
	shell.scale = 12.65;	
	shell.shell_timeout = time + 10;
	
	return shell;	
}
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: FTE: Trouble with gettaginfo and gettagindex

Post by 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.
Meadow Fun!! - my first commercial game, made with FTEQW game engine
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: FTE: Trouble with gettaginfo and gettagindex

Post by drm_wayne »

The QC for the shells is similar to the one for shells in shpulds "turboq", and they work in turboq... :confused:
Julius
Posts: 98
Joined: Sun Aug 29, 2010 4:32 pm
Contact:

Re: FTE: Trouble with gettaginfo and gettagindex

Post by 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
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: FTE: Trouble with gettaginfo and gettagindex

Post by 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
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: FTE: Trouble with gettaginfo and gettagindex

Post by drm_wayne »

Ahh thanks, that was indeed the issue:

Code: Select all

__used var float physics_mode = 2;	/* 0: original csqc - physics are not run
Im using shpulds CleanQC4FTE, and it wasnt enabled.. Learned something new again ;D

EDIT: Test it with ODE Physics:

http://imgur.com/a/jzw9w
Julius
Posts: 98
Joined: Sun Aug 29, 2010 4:32 pm
Contact:

Re: FTE: Trouble with gettaginfo and gettagindex

Post by 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
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: FTE: Trouble with gettaginfo and gettagindex

Post by toneddu2000 »

Sorry drm_wayne, I didn't understand you were using ODE. Awesome effect btw!
Meadow Fun!! - my first commercial game, made with FTEQW game engine
drm_wayne
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: FTE: Trouble with gettaginfo and gettagindex

Post by drm_wayne »

Julius wrote: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?
its nothing special, just me playing around with fte with some old assets from an canceled ww2 project.
Julius
Posts: 98
Joined: Sun Aug 29, 2010 4:32 pm
Contact:

Re: FTE: Trouble with gettaginfo and gettagindex

Post by 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
Posts: 232
Joined: Sat Feb 11, 2012 5:47 pm

Re: FTE: Trouble with gettaginfo and gettagindex

Post by drm_wayne »

Julius wrote: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).
I can give you ther part where i made the iron sights, im basicially moving the entire model so the iron sight is at the crosshair.
The code re-uses CalcBob from FreeCS atm, becausde the Quake default viewbobing is annoying as hell.

Code: Select all

/*
==================
Weapon ADS Declarations
==================
*/

// erstes ist vor und zurück
// zweites ist links / rechts
// letztes ist oben / unten

vector(float wep, float adstype) WeaponADSOffset =
{
	switch (wep)
	{
		case W_MP44:
			if (adstype == 1) return '-3.8 +3.19 +0.65';
			else return '+2.1 -2 -2';
		case W_THOMPSON:
			if (adstype == 1) return '-2.2 +3.19 +1.89';
			else return '-2.8 -2 -2';			
		case W_K43:
			if (adstype == 1) return '-4.1 +2.76 +1.20';
			else return '-3.6 -0.5 -1.1';
		case W_GARAND:
			if (adstype == 1) return '+0.12 0.0 -4.502';
			else return '+2.1 -2.5 -7';			
	}
	return 0;
}

/*
==================
View_UpdateWeaponModel
==================
*/
void() View_UpdateWeaponModel =
{
	local vector offset, adsoffset;
	local vector dir;
	local float ads;
	static float fBob;	
		
	offset_x = 0.09 * sin(time * 1.2);
	offset_y = 0.08 * cos(time * 1.5);
	offset_z = 0.09 * sin(1.1*time + 0.5);
	
	adsoffset_x = 0.002 * sin(time * 1.2);
	adsoffset_y = 0.003 * cos(time * 1.5);
	adsoffset_z = 0.002 * sin(1.1*time + 0.5);

	fBob = View_CalcBob();

	vmodel.frame1time += frametime;	
	
	dir = vmodel_targetpos - vmodel_currentpos;
	if(vlen(dir) < (0.15 * 128 * frametime))
		vmodel_currentpos = vmodel_targetpos;
	else
		vmodel_currentpos += (dir * 0.15 * 128) * frametime;
	
	if(vlen(vmodel.angles) < (0.1 * 128 * frametime))
		vmodel.angles = '0 0 0';
	else
		vmodel.angles += (-vmodel.angles * 0.2 * 128) * frametime;
		
	vmodel_currentpos += (vmodel_velocity * 128) * frametime;
	vmodel_velocity *= 1 - frametime * 30;
	
	vmodel.angles += (vmodel_avelocity * 128) * frametime;
	vmodel_avelocity *= 1 - frametime * 30;
		
	ads = getstatf(52); //get the zoomtoggle value from ssqc
	if(ads == 1)
	{	
		vmodel_currentpos += (WeaponADSOffset(weapon, ads) * 0.15 * 128) * frametime;
		vmodel.origin = vmodel_currentpos + adsoffset;
		setviewprop(VF_AFOV, 80);		
		//setviewprop(VF_DRAWCROSSHAIR, 0);	//commented out because i need the crosshair for debugging my shitmodels xD	
	}
	else
	{
		vmodel_currentpos += (WeaponADSOffset(weapon, ads) * 0.15 * 128) * frametime;
		vmodel.origin = vmodel_currentpos + offset;
		vmodel.angles_z = -fBob;
	}
}

Julius
Posts: 98
Joined: Sun Aug 29, 2010 4:32 pm
Contact:

Re: FTE: Trouble with gettaginfo and gettagindex

Post by Julius »

Super, danke ;)

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