setattachment and collisions

Discuss programming in the QuakeC language.
Post Reply
Nahuel
Posts: 495
Joined: Wed Jan 12, 2011 8:42 pm
Location: mar del plata

setattachment and collisions

Post by Nahuel »

Hello forum, in first place i am using darkplaces engine. Well, when qc spawns a new entity attached to another entity (with setattachment function) this attached new entity is SOLID_NOT. So we can not shoot it -with a traceline-. I guess there is a way to get collisions for the tracelines with attached entities -or SOLID NOT ENTITIES-, but i do not think how. The other way would be to use gettaginfo to get the origin for the new entity, but this metod does not work fine. Can you help? Thanks in advance
hi, I am nahuel, I love quake and qc.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: setattachment and collisions

Post by Spike »

setattachment asks the client to attach the entity, not the server thus cannot affect physics (the server sees the entity as somewhere around '0 0 0'). you can try movetype_follow, but that has an ordering dependancy (one that isn't an issue when following players) but does have issues when players are processed out of order (read: prediction).
if you're attaching the entity to a player, you can update the entity's position from inside PlayerPostThink (with gettaginfo). doing this should ensure the entities stay together coherantly, but can also result in awkward interpolation if other players are predicted (ie: quakeworld engines, but not dp).

ultimately though, why does it matter whether the attached entities are solid or not?
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: setattachment and collisions

Post by Cobalt »

I believe SOLID_TRIGGER will still detect collision, while still giving you what SOLID_NOT does.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: setattachment and collisions

Post by Cobalt »

So this is basicly a client side ent you are saying. So whats available from a ssqc perspective to manage an ent like that? Im guessing it must show up in the server ent list....so can you read its specific fields just like any other ent, and not write / change them, sort of like a hybrid static ent of sorts?
Spike wrote:setattachment asks the client to attach the entity, not the server thus cannot affect physics (the server sees the entity as somewhere around '0 0 0').
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: setattachment and collisions

Post by Seven »

Hello,

I also have a small issue with the setattachment extension:
I do not know how to NOT use the .angles of father-entity for attached entity.
My goal is to keep their origin identical at all times, but when the father-entity turns, the son shall not (do not use fathers angles) .

The dpextension.qc says clearly:
note: use "" to attach to entity origin/angles instead of a tag

So, if I understood correctly, I must set a tag-name, otherwise it will use the fathers angles.
But when I declare a tag-name like this, it will also use fathers angles:
setattachment (foo, self, "test");


As far as I understand, if I replace "test" with "", foo will use the angles of self.
But also when I use "test" it will use its angles.
Even when I use in foo´s _think function:
self.angles = '0 0 0'; (as it is always relative to the father)

So, I do not understand what a "tag name" is and how it is used.
I only want to be able to have an attached entity (a simple mdl model) which .angles I can control inside its _think function (independent to fathers angles (also a simple mdl model)). :|

As a workaround I can only use the unprecise way of adding entities (without setattachment, but with a think function every frame glueing it to the father origin, which is of course stuttering and not fully satisfying...)


Maybe someone can help ?
Thank you in advance.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: setattachment and collisions

Post by Spike »

attachments attach the child to a point on the parent entity. as the parent rotates so too will the child. its for visible weapons on other players, where you want the child to appear as if it was part of the parent in the first place.
separate angles defeats the point of it (the child's angles field will rotate the child around the point of attachment).
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: setattachment and collisions

Post by Seven »

Thank you for your post Spike.

It is sad that almost all great extensions are made with the player in mind.
Most probably because Quake is a multiplayer shooter for most people. I understand this.

I am working on a more complex monster at the moment which has a feature that maybe can be best compared to the Predator´s laser weapon for example (sitting on his shoulder).
The laser weapon´s origin is fixed to the monster´s origin (in my case it is the center (no offset)), but it can turn itself towards the player for example even though the monster is not turned towards player.
It also has a rotation animation using .avelocity, which must be independent to parents angles when parent turns.

That seems to be impossible with “setattachment” as far as I understood your post (even though I do not know why LH mentioned this specific “origin/angles” topic in relation to tags in the dpextensions then)
For the 1st person view (yeah the player again :) ) something like this is possible with “viewmodelforclient”.

I will try if I can add an entity to a monster with “viewmodelforclient”. I doubt it will work as it is most probably a “player-only thing” again, hehe :)

If everything fails, I still have my fallback option. A workaround which is not 100% smooth when the parent is moving but it does what it should (mentioned in above post).

Thank you again for your time and tireless help supporting the ones in need.
Best wishes.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: setattachment and collisions

Post by Spike »

makevectors('0 0 0');
setorigin(foo, v_right * 16 + v_up * 30); //set the origin/pivot of the turret relative to the parent entity (actually, the position is a constant, but using v_forward/v_right makes the position a little more readable).
setattachment(foo, themonster, ""); //glue it to the monster entity.
foo.avelocity_y = 10; //make it slowly turn, to show what angle changes actually do.

if the monster turns, the turret will swivel with it.
if you want to set the turret's angle to a specific value, you'll have to subtract the parent's angle in order to determine the relative angle to use.

its probably easier to just move the turret with the parent and update the origin after every single ai call, instead of having to do eular angle calculations.
Seven
Posts: 301
Joined: Sat Oct 06, 2007 8:49 pm
Location: Germany

Re: setattachment and collisions

Post by Seven »

Hallo Spike,

that is how I tried it, but the 'swiveling' in combination with a different angle calculation after each ai_ call (or very short time frequence) is approx. as stuttering as the other way (fallback mode) to do it :|
So, either way i will have to live with a little stuttering i am afraid.
The latter stutters while turning, the former stutters while moving.

A way to completely separate origin and angle relationship would be winner, but as you said (or as I understood it), 'setattachment' is not supporting it.
Maybe that would be a possible new interesting engine extension ? :)
But unfortunately I am using DP (because I started using it at the beginning of the mod. Today my choice would maybe be different).
It is mainly the amount of effectnum´s (that has been designed) which keeps me from switching engines. Even though you started implementing a syntax translater (results are stil improvable for some yet).

Thanks again for your help !
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: setattachment and collisions

Post by Spike »

if you change the turret's .frame field at the same time you change the monster's .frame (not necessarily to the same value, just alternating between two different values or so) and also make it movetype_step (with fl_onground or fl_fly or something) then it should all interpolate with the same timings, in theory.
Post Reply