setattachment and collisions

[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

[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]

I believe SOLID_TRIGGER will still detect collision, while still giving you what SOLID_NOT does.

[Cobalt]

[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]

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]

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]

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]

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]

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.