Simple animals

[Tels]

I just uploaded Ratz_Anim_Base.fbx to the simple animals/ratz directory on SVN.

 

The 'groove' bone' is for up and down (and tilt) movement of the body.

 

Let me know if it works out.

 

Speaking of the rats, why are these files under "simple_animals", and not under "animals/simple"? Can we please move them before we accumulate even more files in the wrong folder?

[Springheel]

Is there a surface-type that would cause the flesh-hit effect but either break the arrow or make it "go through" ?

 

Are you saying more than one arrow sticks into the rat without killing it? Or just that the death arrow sticks in and causes AF problems with the ragdoll? They're two slightly different things.

[rebb]

Just that the death-arrow *sometimes* causes AF problems. Afaik only the "killing arrow" ever sticks to a model.

[Springheel]

Hmm, don't know. I think the death arrow will remain any time the material supports arrows sticking in (which is cloth, flesh, and wood, at least).

[Baddcog]

Well, that's the path names that we decided apon before I released them so....

 

I wouldn't be the one to answer that Q Tels.

[Crispy]

Hmm, don't know. I think the death arrow will remain any time the material supports arrows sticking in (which is cloth, flesh, and wood, at least).

Yes, that's how the code is set up now.

 

There are two options, as I see it:

 

1. Make variations on the material types that behave the same but don't have arrows sticking in. This could require some data duplication; e.g. every time you set something for the "flesh" material you'd also need to set it for the "flesh_nostick" material.

 

2. Add a spawnarg which turns off arrow-sticking on a per-entity basis. So you could add "no_stuck_arrows" "1" to the rat's entityDef, and then arrows would never stick in rats regardless of the material.

 

I favour option #2, and will probably implement it in a few hours if nobody has any objections.

[sparhawk]

Speaking of the rats, why are these files under "simple_animals", and not under "animals/simple"? Can we please move them before we accumulate even more files in the wrong folder?

 

Why don't you move them yourself?

[Crispy]

Done and on SVN. It's all scripting, so no PK4 update needed.

 

You can now set the following spawnargs to force-enable or disable arrow sticking on a per-entity basis:

 

arrowsticking_forceenabled

arrowsticking_disabled

 

Full docs on wiki here.

 

So you should now be able to just set "arrowsticking_disabled" "1" on the rat, and arrows should no longer stick in it. Let me know if this doesn't work for you.

[Tels]

Why don't you move them yourself?

 

Because you can bet that somebody would move them back and tell me "you should not move things"?

 

(See the last time I tried to move the chamberpot out of the kitchen - that silly decision left me forever burned. Tels does no longer move things or clean them up.

[rebb]

Done and on SVN. It's all scripting, so no PK4 update needed.

 

You can now set the following spawnargs to force-enable or disable arrow sticking on a per-entity basis:

 

arrowsticking_forceenabled

arrowsticking_disabled

 

Full docs on wiki here.

 

So you should now be able to just set "arrowsticking_disabled" "1" on the rat, and arrows should no longer stick in it. Let me know if this doesn't work for you.

 

Thats cool Crispy, thanks.

 

I tested this a bit but it seems that the disabled arrowstick just makes the arrow vanish - so i went ahead and made a "force_dud" entity-key which when active, will cause the arrow to dud on the respective entity.

 

Not sure if this is a good way to do this, maybe you want to look over it again in the arrow-result script.

 

I've put the changes on SVN so the rats should now die more believably.

Better not tell PETA

[Springheel]

The arrows should only break if they're hitting something that absorbs damage, like chainmail or plate. Otherwise, they DO vanish.

[Crispy]

Your code looks OK, though you should just be able to call dud() rather than doing callfunction("dud").

 

Design-wise, I agree with SH that it makes more sense for the arrow to just disappear rather than breaking. The breaking is a cue to say "there's armour here, so your arrow didn't do full damage"; rats typically don't wear chainmail.

[Springheel]

In fact, though I think we originally had arrows break on chainmail, I believe we changed it so arrows only break when NO damage is done, to help make it clearer to the player when they're actually hurting an AI and when they're not. So having an AI die from a broken arrow shot would not really fit our current system.

[New Horizon]

(See the last time I tried to move the chamberpot out of the kitchen - that silly decision left me forever burned. Tels does no longer move things or clean them up.

 

This really upsets me! What about all the other things people agreed with? Isn't that worth anything? We've loved tons of your work! This was one minor disagreement that the team had with you. Pretty much everything else, we've been more than happy with...and encouraged. If you're going to get bent out of shape because of one team decision, that's just silly. My God, we've ALL had times when we've had to swallow our pride and go with the team decision over the last 4 years. Just because the team doesn't agree with you on one issue, doesn't mean you have to stop doing everything else. It just means....hey, we disagree on one thing. If this keeps coming up for the next year whenever someone asks you if you would mind doing something, I'll delete the damned piss pot and be done with it once and for all!

[rebb]

@Crispy :

I had it call dud(); first, but for some reason that did not work so i tried callFunction() and it worked as expected .

 

Before changing the material to "flesh" that was actually how the rats died, there was a "plock" sound and a broken arrow, and the rat was dead .

 

It just looked a bit odd that this huge arrow ( relative to the rat ) would just vanish after killing it, since the killing arrow usually "sticks around". So i tried this forced dud version.

 

But if its against continuity i can just undo the force_dud stuff.

 

Having the arrow show up but not bind to the rat doesn't work well either, as the arrow tends to "jump around" on it's own because of some physics glitch ( i wish id had spent more time on the physics in this game :/ ).

[greebo]

On a related note: Is it just me or does anybody else find that the arrow projectiles are huge? I thought arrows are supposed to be thin, but ours look like as thick as my fingers, I don't think an ordinary bow can accelerate these to a reasonable velocity.

 

@rebb: Yes, the rigid body physics is not exactly stellar, unfortunately. I already spent hours if not days in that code and it's often just a pain to work with. It took me hours to get the player weight into the game, and it's still buggy.

[Springheel]

On a related note: Is it just me or does anybody else find that the arrow projectiles are huge?

 

I believe they're a bit larger than reality to help the player see them...we tried a smaller version and they were very difficult to see, so it was often very difficult to tell where your arrow went. Of course, we could always add arrow trails.

[greebo]

I believe they're a bit larger than reality to help the player see them...we tried a smaller version and they were very difficult to see, so it was often very difficult to tell where your arrow went. Of course, we could always add arrow trails.

God forbid, no arrow trails... our broadheads just appeared to me as a strikingly large piece of weaponry, especially when they stick into dead AI. It looks so awkward, but I'll get used to it I guess.

[Springheel]

I'm almost certain Dram tried a smaller version but we decided to revert back.

 

edit: Ah, here's the thread: http://forums.thedarkmod.com/index.php?showt...;hl=arrow++size

 

I notice that broadheads don't really sink into AI very much (usually just the tip of the arrow) so that might make them look a bit larger when they're sticking out.

[Crispy]

I notice that broadheads don't really sink into AI very much (usually just the tip of the arrow) so that might make them look a bit larger when they're sticking out.

If anyone wants to change this, there are push_in_* spawnargs for various surface types in def/weapon_broadhead.def. For example:

 

"push_in_flesh" "10"

 

Increasing push_in_flesh should make the embedded arrow sink further into the flesh surface type when it hits.

 

"push_in" sets the default push-in value, in case push_in_SURFACETYPE doesn't exist for any given SURFACETYPE.

[Springheel]

Does it measure from the origin, Crispy? I noticed that the tip of our broadheads is some distance *below* the origin (in other words, no part of the mesh is over the origin point). Not sure why that is, and it probably plays havoc with physics.

 

I didn't want to change it as I assumed it was important.

[Tels]

This really upsets me! What about all the other things people agreed with? Isn't that worth anything? We've loved tons of your work! This was one minor disagreement that the team had with you. Pretty much everything else, we've been more than happy with...and encouraged. If you're going to get bent out of shape because of one team decision, that's just silly. My God, we've ALL had times when we've had to swallow our pride and go with the team decision over the last 4 years. Just because the team doesn't agree with you on one issue, doesn't mean you have to stop doing everything else. It just means....hey, we disagree on one thing. If this keeps coming up for the next year whenever someone asks you if you would mind doing something, I'll delete the damned piss pot and be done with it once and for all!

 

I didn't say I don't go with team decisions, sorry if this sounded like it. Just as with my boss at work, I might not like the decisions or the rationale behind them, but I go with them. Grudingly (esp. if I think the decisions are insane, illogical or bizzar, or even all three things at once , but I still go with them.

 

I just don't make the effort to try to correct them (when I think they are wrong) anymore. I state my option, and that's it, there is no sense in picking fights you can't win.

 

There is too much work to do so I try increasingly often just to do something instead of debating on the forum. (Granted, my work might be quite invisble because f.i. greebo puts in so much work that whatever little things I can do pale absolutely in comparisation But thats another story

[Tels]

I believe they're a bit larger than reality to help the player see them...we tried a smaller version and they were very difficult to see, so it was often very difficult to tell where your arrow went. Of course, we could always add arrow trails.

 

No trails, but we chould have a small dust particle rise where they hit.

[greebo]

Granted, my work might be quite invisble because f.i. greebo puts in so much work that whatever little things I can do pale absolutely in comparisation But thats another story

That's absolutely the wrong way to look at it - just because I happen to do more than the average Team Member I'd hate to see any other people's work belittled.

 

Honestly, does my work discourage anybody else? This would really be grotesque.

[Springheel]

Hitting something isn't the problem. As it is now, if you hit something the arrow either sticks in or spawns blood or broken bits at the site of impact.

 

The aiming problem is primarily for when you *miss* your target entirely. If you're aiming at an AI, shoot, and miss, you need to be able to see where your arrow went so you know whether you were too high, too far to the right, etc, so you can correct your next shot. If there is nothing directly behind the AI, you're not likely to see what or where it hits, so you need to be able to make out the arrow in flight.