copied and transferred. Author of Posts are denoted bold, all
Quotes in Italics.
Original Title: I Propose.....
Original Author: Big Red
BIG RED POST:
... That we give another go to the spitting dilo. Of course, we know we can't implement it directly in the AI, but I was thinking that we could instead use the ActBite command in the same fashion as the jumping dinos and matrix effects to trigger dilo spitting.
Here's how it would work. You would have an external INI in one of the MAPS ATX sub-folders, just like the dino randomizer, which would designate the levels and dinos the spitting would be applied to, along with all other spitting settings. In the INI, you would specify an object or several objects (cycled) that would be used as projectiles, already present in the level. These should have very low mass.
Now, everytime the dino would initiate ActBite in-game, those projectile instances would be teleported right in front of the dilo's head and given its orientation, and then set to a certain velocity using ActionType 10 implicitly (the direction calculated from the dino head's orientation as well). The process would of course only happen at certain specifiable intervals and probabilities, just like ActJumpNew. If I could figure out the math, it could even be set to fire only when the dino's head is facing at a certain angle from the player's position (but don't count on that). You could also use the "BiteTargetDistance" float script to force the dilo to bite and thus spit from further away from player (and another minimum distance value to keep the dilo from spitting too close to the player).
As for the damage, we could use CCollisionTriggers (as you would have guessed) for every projectile, and assign the Player as second element, and maybe secondary CCollisionTriggers for when the projectile hits anything else (if that works). The projectile would be teleported out of view upon impact, or maybe after some animation. Of course, this wouldn't work if the dilo was attacking other dinos, but I'm sure we could figure out a way around that.
I haven't really followed what you guys have tried so far, so if any of this doesn't add up, let me know. There's an endless list of things I could work on, but I think this is what people would be most interested in, and also whathat would put the most focus on Trescom itself.
REBEL POST:
Yea, I actually pondered the spittter spitting on occasion,
though never too seriously. I already considered using a var-
iation of actbite that could potentially unfurl the frill (that'd be
an animation attached directly to the animal). Technically, if 1
could, meaning you, of course Wink, determine the best time dur-
ing the attack as to when the spitter would actually 'spit, then
it might work. I assume you're considering using the existing
particle system for this? Again, I considered how well sprayin'
with the spray can worked and thought that might easily be
adapted to the spitting action (so, animation again). Since I
work with the animations invariably my methods of achieving
the desired effects would be dumbed down compared to the
more involved and technical aspects of a programming solution.
Of course, even with animations they're not entirely simple ei-
ther. I generally lean on Remdul's artistic talent for that as my
own are rather limited.
I was generally planning on having the spitter make a reap-
pearence in some project though beyond the frill and try-
ing to get it to unfurl just before an attack was what was ori-
ginally on my mind. If we could get it to 'spit', well, that'd be
awesome, of course.
*If you really wanted to get looney with spitter effects, you
could probably hang a face plate in front of anne and have
that action cue in a semi-transparent anim. which could serve
as a blurred vision effect afterwards.
BIG RED POST:
Quote (Rebel):
I assume you're considering using the existing
particle system for this? Again, I considered how well sprayin'
with the spray can worked and thought that might easily be
adapted to the spitting action (so, animation again).
I was planning on using just a standard instance as projectile, a very fast-moving one to be precise (so you wouldn't see the details), and have whatever animation or particle effect trigger only upon impact, to make sure it works at all ranges. I figured if it sprayed at the beginning of every spit, it'd be harder to get it to look acceptable at long range... unless you guys figured out a way around that with the 'spray can'...
... and honestly, *gasp*, I haven't seen the spray can (haven't played much as of recently). Where is it? Does it use CParticles, texture animations, or *.asa animations?
Quote (Rebel):
*If you really wanted to get looney with spitter effects, you
could probably hang a face plate in front of anne and have
that action cue in a semi-transparent anim. which could serve
as a blurred vision effect afterwards.
Definitely! That would be a great addition. My visual 'artistic talent' isn't too developped much (either, though I wouldn't add that myself), so I'd probably need your help on that.
According to my reasoning (which isn't too great right now), the biggest problem will probably be getting CCollisionTriggers to work properly. That and the artistic issue I will most likely be needing your help with.
REBEL POST:
SprayCan is lying on the ground, backside of the pens where
the contest sigs are (on wall). Hit the right spot on the wall
to the right and hit action (works only once) it'll spray 'Anne
Waz Here'. (uses 16bit anims)
Yea, particle system is probably of limited use. As far as the
artistic talent needed, I generally provide a proof of concept
to Remdul, proving of course that my insane idea will actually
work, then I generally left it up to the master to make every-
thing look right; I'd script it from that point. More or less, if
you're dealing with something complicated and as yet untried
and unproven, it normally takes a few heads put together to
come up with a workable prototype. As you no doubt know
from atx user input suggestions, ideas are a dime a dozen,
implimenting them is the hard part.
BIG RED POST:
Quote (Rebel):
As you no doubt know
from atx user input suggestions, ideas are a dime a dozen,
implimenting them is the hard part.
No doubt about that, heheh. From land/sea/air combo vehicles to emulating Half-Life 2, I'm sure I've heard it all by now. I think you end up disappointing people more than actually creating anything, but then again you can never really shape expectancy no matter how hard you try to down-hype it. Oh well.
HILWO POST:
My post won't really have anything useful to add, except for encouraging you guys Mr. Green That, and the fact that the Dilo is my favorite dinosaur in Trespasser... Go for it guys I hope you succeed!!
REBEL POST:
*Quote (Big Red):
No doubt about that, heheh. From land/sea/air combo vehicles to emulating Half-Life 2, I'm sure I've heard it all by now. I think you end up disappointing people more than actually creating anything, but then again you can never really shape expectancy no matter how hard you try to down-hype it. Oh well.
I like the down-hype term. Personally, I just don't like to promise
anything that may not be deliverable. If I understand this correct-
ly now, your aim is to use tangible (and available) instances to
detect collision and subsequently record damage while these par-
ticular events trigger presumed animations of spit projectile, do I
have this right...?
Currently in tc_isle, just before the spitter launches an attack it
makes that distinctive hissin' noise which btw is pretty much the
time when his frill should fan out. Each AI 'Act' command has an
audio attached to those particulars; unfortunately though, as far
I can recollect through past experimentation, audio collision de-
tection doesn't work with dinosaur sounds which if it had would
have made some of this considerably easier in as far as when a
particular add-on action should be cued in. As far as projectiles,
in a created level, you could simply create a limited amount of in-
visible cubes to be used for collision and detection and being in-
visible, there'd be no need to teleport them out of the area after
an event; you keep them extremely small as not to hinder any
walkover. Distinct particle effects, ie. size, speed and color can
be assigned to any given object using Tres' existing particle sys-
tem and also supplement an animated collision effect.
Quote (Hilwo):
My post won't really have anything useful to add, except for encouraging you guys
Your input is always welcome, Hilwo. Wink
BIG RED POST:
Quote (Rebel):
your aim is to use tangible (and available) instances to
detect collision and subsequently record damage while these par-
ticular events trigger presumed animations of spit projectile, do I
have this right...?
Pretty much. The idea is to have the launching of the projectile separate from the damage code/animation so as to make the launching re-usable in the future. Yes, the instances thrown would be tangible and already present in a level.
Quote (Rebel):
you could simply create a limited amount of in-
visible cubes to be used for collision and detection and being in-
visible, there'd be no need to teleport them out of the area after
an event; you keep them extremely small as not to hinder any
walkover. Distinct particle effects, ie. size, speed and color can
be assigned to any given object using Tres' existing particle sys-
tem and also supplement an animated collision effect
I'll consider that alternative, but I'd still rather have the projectiles visible so the player can dodge them. That is, unless the invisible object could leave a particle trail in the air...
Anyhow, I've got the basic launching system in place right now, and I can get dinos to launch objects using ActionType 10 with X,Y,Z velocities on ActBite. However, I don't know how to keep gravity from affecting an object. Even at high speeds and small or null masses, objects don't get very far before plunging down. Do you have any idea how to get around this? I noticed the elevator in the Isle moves up at a constant rate without the effect of gravity; how did you manage that?
REBEL POST:
I call 'um 'movers'. They're small tangible blocks I used
as a conduit to complete the mechanical circuit, via tele-
cubes which are positioned inside a fixed trigger. If the
object is present, constant force is applied to the eleva-
tor until other stop triggers (or player actions such as a
reverse direction button pushed). A duplicate setup ex-
ists as described above to handle downward motion.
Eh, can it be applied to your launch system? Hmm. Are
you using exterior code to simulate actiontype 10 or us-
ing standard, ingame triggers?
Considering that gravity is a global presence, I can't see
a way of defeating it for select objects.
Quote (Big Red):
but I'd still rather have the projectiles visible so the player can dodge them
In theory, I'm not even certain 'dodging' them is possible.
Our dear Anne isn't exactly a speed demon, B.R.. Even at
my grandfather age, my own reaction time is still faster
than what the game can emulate in realtime. The transfer
from brain to keyboard to actual game motion laspes to
several seconds time; probably, the spit projectile should
have already come n' gone even if the attack was launched
from several yards away. Applied to a real life situation, I'd
liken it to trying to dodge an attack from a water gun. At a
few yards in distance, near impossible.
BIG RED POST:
Quote (Rebel):
Eh, can it be applied to your launch system? Hmm. Are
you using exterior code to simulate actiontype 10 or us-
ing standard, ingame triggers?
Yikes, I doubt it will be possible from how you describe it. Seems like it's going to be a major issue. I'm using ActionType 10 very directly, almost like you would in a regular trigger, the only difference being that the velocity directions are calculated in real-time. The problem as you probably know is that you can't have speeds higher than the lower hundreds (it seems to be a physics engine limitation and not an actiontype-set limit).
The only way I see around it is to emulate your constant AT10 calls, which I can currently do, and have an in-level trigger call a new ActionType upon collision with any object to tell it when to stop setting the constant speed. But it will be tricky...
Quote (Rebel):
In theory, I'm not even certain 'dodging' them is possible.
Our dear Anne isn't exactly a speed demon, B.R.. Even at
my grandfather age, my own reaction time is still faster
than what the game can emulate in realtime. The transfer
from brain to keyboard to actual game motion laspes to
several seconds time; probably, the spit projectile should
have already come n' gone even if the attack was launched
from several yards away. Applied to a real life situation, I'd
liken it to trying to dodge an attack from a water gun. At a
few yards in distance, near impossible.
Yes, yes, I know that, but it's no fun! If you look at anything else in the game, the speed is decreased. Take the basketball, for instance. Take the _dinos_, for instance. For such a slow-paced game, wouldn't you find it odd to round a corner and die instantly from a dilo shot 3/4 of your way through a level?
Besides, from my current tests, the projectile speeds are high enough that they're hard to dodge, just not impossible.
REBEL POST:
I'll take your word for it, Big Red. I'm certain you have a
handle and sound perspective on this. Wink
BIG RED POST:
Quote (Rebel):
I'll take your word for it, Big Red. I'm certain you have a
handle and sound perspective on this.
No, please don't, heheh. If there's one thing I've learned from reading Trespasser interviews and writing ATX, it's that the programmer _never_ has the sound perspective on things; he just thinks he does. I do need all the input you can give me even if I may make you want to think otherwise.
I'm only adamant about using instance-projectiles because it's the only solution available to me right now, and trying to discredit it will bring me back to zero. In fact, I've pretty much gotten the actual projectile launching done.
Dead Link Removed...
(You'll need the DivX codec). This one was recorded a few days ago, and it shows the launching being adequate at very short range. However, as I mentioned, the projectiles would die out quickly and it was weak in the vertical department.
Dead Link Removed....
This was after a good amount of work from yesterday. I wrote a new ActionType that works just like your Isle elevator, renewing the instance's speed at every frame. In the video, the renewing only stops after a certain time-out value, because before recording I didn't bother putting the collision triggers in the level that would call a helper ActionType to turn the first one off.
I also found that the dinos' heads were very rarely perfectly aimed at their targets when launching projectiles, which made them very ineffective. The solution? Auto-aim. It turns out that all ActBite calls (and all other CActivity-based AI actions) are accompanied by a CInfluence temporary instance that gives the current target (thankfully). The auto-aim basically follows what ActBite says is the target. It doesn't try to predict target movement, just centers on its current position and launches. It was ineffective in the first video, because of the gravity issue, but in the second it just shoots in a straight line so there's no problem.
The actual shooting will only happen at certain time intervals, with certain random probability, at certain distance, and most importantly, with the dino facing its target within a certain specifiable angle. There are a few sections of 3D code I haven't written yet (the projectile isn't always facing in the right direction, for instance), but all the basic ridiculous 3D stuff I can't stand to write is there
.As you can see, the projectile speed isn't 100% of what I had hoped for, but I'd say it's about adequate at short range. If I have to assume that it's what will be used for now, we're left with figuring out how that damage will be handled, how things can be animated, how we'll get that "blur" effect to work, etc. The only thing that's definite for now if we use this system is that every projectile will have to have a CCollisionTrigger assigned to it for collision with any object, because it will have to call the new helper ActionType to turn off the fixed speed renewer when it hits anything (pretty much like the elevcage, I guess).
Quote (Hilwo):
My post won't really have anything useful to add, except for encouraging you guys, and the fact that the Dilo is my favorite dinosaur in Trespasser... Go for it guys I hope you succeed!!
(oops, skipped over that...)
Thanks, and so do I.
REBEL POST:
Well, I don't see collision detection triggers being much of a
problem, though the cueing in of the animations will have to
rely on the actbite command action, I'd think. Any later, it'll
(meaning the anims.) would be out of sequence. First, Frill,
spit n' projectile, then damage assessment.
*1st video must of corrupted during download, 2nd it was a
little distant to see clearly, though I thought I saw something
flashby and/or near the yellow raptor before he croaked and
before the pretend spitter was near enough to actually bite,
so it appears the action itself does indeed work. Cool
BIG RED POST:
I forgot to say that I had to encode the videos using the h.264 codec because all my computers are messed up at the moment (not DivX, or both, or something). You know, typical Windows stuff. You can get the codec from
http://www.cole2k.net
Sorry!
You should be able to see the stones being thrown around the raptors in the second video. I stayed on the platform to try to get a global view, because it's difficult to catch anything from the ground. I'll try to get a better one when Windows lets me.
Quote (Rebel):
Any later, it'll (meaning the anims.) would be out of sequence. First, Frill, spit n' projectile, then damage assessment.
Sounds good. Let's start with damage. The projectiles from the videos were simply outfitted with the...
float Damage = 50.00000
... value script. I think it worked, but I don't know if the damage was due to this script or to the high velocity and mass. Do you know if it does? And would it work for Anne, or also all dinos?
As for the frill, maybe the easiest way would be to leave that up to you guys. Instead of having ATX call the ActionTypes required for the animation, you could set up something like a CLocationTrigger with all the necessary anim info, and when ActBite is called, ATX would teleport a certain object inside the trigger to set it off. I could write an extra ActionType to teleport the "frill" to the dino's head if necessary.
I obviously haven't thought much about the frill; I wouldn't know how to make it look good. I haven't really seen what you've accomplished on that matter either. Let me know.
REBEL POST:
I've never assigned float Damage = # to anything other than
logical items before, though I know dreamworks used it so I'd
have to say that yes, it does work. Example wise, note that in
the demo that you're experimenting in the trailer has a damage
value (though I think it's zero 'for no damage'). If we assumed
as much, there'd be no need for collision detection/damage trig-
gers.
*Note that by not assigning mass to an object, it becomes in-
variably deadly.
Frill: I've used similar trickery before with triggers/teleporting,
so having a separate trigger holding control of the frill and the
anims in general sounds like a solid idea. Teleporting the frill it-
self won't be necessary; centity works just fine with intangibles
and any object using anims can be held in an invisible state by
using a simple full opacitymap.
*Beyond looking at a few jp pics of the spitter, I haven't touch-
ed on this yet, I'm somewhat hopin' Remdul stops by and jumps
in for the artistic stuff. Scripting the frill itself is not a big thing,
the quality of the bmp frames is what'll make it look right. Any-
ways, it'd be a simple face, modelling to match the vert points
forming the spittter's head, the anim itself would appear as if a
fan were unfurling. Defeating 2D, hence giving it that 3D look is
all in the illusion.