Applying Af Attachments

[New Horizon]

Somebody, just put the damn thing in. Is it really that big a deal? Seems like a good idea to me.

 

Dom, I don't know if you're intention was to sound hostile but you're really coming off that way. I realize you have a beef with Spar, but I couldn't really see anything to get worked up over in his previous posts. Yes, he was questioning the feature, but I don't feel it required creating a standoff. Perhaps you're overtired recently, or just need a vacation from the mod...I don't know, but Spar isn't the Devil and neither are you for that matter. It would be good if the two of you could be a bit more supportive of each other. Just my two cents.

[Darkness_Falls]

or typing af_print and seeing this;

CODEaf_print

position: 52 33 46

orientation: 3 4 5

Which would you preffer?

I'm no programmer, and I have no idea what you're talking about , but af_print sure seems a lot easier to read to me!

 

PS: They pushed each other's buttons. LOL

[Domarius]

I couldn't really see anything to get worked up over in his previous posts.

If you were a programmer, you might've.

 

We both know that something like af_print would require only a few lines of code. And as a feature, it's a triviality. Even if it was left out, it wouldn't matter too much.

 

So since he's dragging it out so much, I can only assume he's digging for things to argue about. He could be contributing his own ideas for a solution to the problem, but he'd rather nitpick.

 

That pisses me off.

 

Let's move on please.

[sparhawk]

I already contributed my own idea before.

[Dram]

OMG...not this again. If I got worked up every time someone did'nt like my idea I would've been kicked from the mod ages ago. I don't know exatcly what's going on, but I'm presuming you want a console command which lists the "bad" attachments Dom? And then Spar said it was pointless or something along those lines? And you got pissed off.

 

Well whatever...I dunno what else to say, just seriously, a mod dies when it's team argues, a professional studio does not, simply because there's one person paying them all and says "stop it the fuck" type thing. Here obviously we're all at an equal level, so we're bound to argue, so I'm just saying try to avoid it, it makes working with each other easier.

[Domarius]

No, you don't know what's going on. I wasn't getting worked up because he didn't like my idea - it was because he was nitpicking. I tried to explain it to him, and after my visual example I gave up. The argument stopped there for me. Why are we still talking about it six posts later?

 

Next time, could people give it at least one page of posts before being the proverbial school teacher?

[Dram]

Fair enough, I just wanted to stop another "debate" is all

[Ishtvan]

Yeah, I think with all the energy it took to "debate" one of you guys could've implemented the system already.

[sparhawk]

I would have done it already, if I knew exactly what Spring needs. Does it just need some coordinates in relation from one idEntity to another? Or is this something different with the AF attachments? Since I never did anything with this, I don't really know about it.

[Ishtvan]

I don't know, you'd have to look at how testModel works. I was planning to add a function to dynamically re-attach things (without destroying them) for the purposes of animations though, so I should probably write that function first before we try to do anything... maybe by this weekend. After that it's just a simple matter of calling that function with console commands to set the origin and angles.

[Domarius]

Yeah, I think with all the energy it took to "debate" one of you guys could've implemented the system already.

Yes, one of my points I was trying to make, and why I gave up explaining.

 

@Spar, if you don't understand what Spring needs, it should be enough to read my description of my idea. What about it don't you understand?

[Darkness_Falls]

We all just need to know when to let it go. We can't win every argument. Well, we could, but we'd look like jerks while trying to do so. For team's sake, let go of some stubborness. (Note: I'm intending this for us all; I'm not picking on any one person. Dram. Hehehe, just kidding, Dram.) Basically, we could all use a little self humility (or whatever I'm trying to say).)

[Dram]

We all just need to know when to let it go. We can't win every argument. Well, we could, but we'd look like jerks while trying to do so. For team's sake, let go of some stubborness. (Note: I'm intending this for us all; I'm not picking on any one person. Dram. Hehehe, just kidding, Dram.) Basically, we could all use a little self humility (or whatever I'm trying to say).)

 

lol, that was confusing

[Domarius]

*sigh* the argument ended on the previous page. It was too late to say "be nice" and "don't argue" by the time this page started. So saying it repeatedly in different ways isn't going to change anything. Some of us are trying to get the thread back on track.

 

Let's move on please.

 

@Spar -it's essentially the coordinates and orienation of one object, in relation to the AF joint of another object.

 

Eg. We need to set the purse to the hip joint. But the hip joint is in the middle of the guard's waist. So we offset it's position relateive to the hip joint so that it's off to the side, visibly on his hip. But then it's pointing straight down, so we then need to angle it relative to the joint so that it seems to be resting on his clothing sticking out... etc.

[Springheel]

It could work like testModel how it simply spawns one entity at a time - in fact it could piggy back off the testModel feature.

Type

testModel charactername

as usual, and then type

af_attachMesh mesh joint

where mesh is the name of some mesh, like purse, or key, and joint is the name of a join on the model that was loaded with testModel, like rightHand, hip, etc.

 

Then... maybe override the keys to move the object and rotate it, or simply just add more commands like af_setOffset x y z

af_setRotation x y z

and of course

af_print

to get the current position and rotation values.

 

Something like that would be great. I wouldn't even need keys to rotate the object. It would be fine to just type in the origin and rotation values as long as I could instantly see the result.

 

Just to be consistant, however, it should probably use the following terms (the ones in the def files), (though the af_ prefix is fine):

 

def_attach [entity name] [joint] selects model to attach and joint to attach to (don't know how you would specify which AI model to attach to--perhaps def_attach [ai entity] [prop entity] [joint]?

af_setOrigin x y z (position in space relative to the joint)

af_setAngles x y z (how the object is rotated)

 

And the print function sounds like a reasonable time-saving device, especially if you need to interrupt the process and come back later.

[Ishtvan]

I haven't had time to put in a dynamic attach function yet, but did find this which might be helpful:

 

If you don't want attachments to go away when the AI dies or is KO'd, set the following key/value combo in the attached item def:

 

"remove" "0"

 

This should make the coinpurses stay on when the AI are KO'd or die.

[Springheel]

So that would pretty much be default for all our prop items, correct? Hmm, not for ones held in hand, I suppose, but for just about anything else I can think of.

 

I'm going to hold off creating any more prop defs until we get some kind of system like the one Dom described--it was worth it to get a proof of concept, but far too much hassle to do individual objects.

 

And we basically need only three things to implement using attachments for the AI's weapons:

 

1. A modeler/animator to remove the weapons from the original models (a possible, but less desirable alternative is to use skins that swap a nodraw texture on the weapons).

 

2. Someone to modify the origin of the existing weapon models (they are currently based on their relationship to the AI model, and are sometimes several feet away from the weapon itself, which would no doubt cause some really strange rotation behaviour).

 

3. Someone to create item defs for the attached weapons. I'm willing to do that, but I'd need #2 taken care of first (and a WYSIWYG system for the orientation, as I said above).

 

Once this attachment system is in place, we'll have a lot more flexibility for AI--it would be a snap to swap a sword for a hammer, or even create a new weapon like a mace or a dagger, etc.