TresCom Forums

machf wrote:(What annoys me most is not that I'm unable to read that section of the forums, but that the 'unread posts here' indicator shows up and I can't make it go away... when I come to the forum and notice it, II automatically click on it, and then I realize which section it is)

After the last forum section, there's a "mark all forums read" link. Try that machf.

Rebel, I'll say it again -- excellent work on the spitter.

Slugger wrote:
After the last forum section, there's a "mark all forums read" link. Try that machf.

There is? OK, I'll try that next time. Thanks!

EDIT: I did some more tests... it works in the demo with the ATX 1.59 patch and the updated effects.tpa file, and it also works on the TC_Isle latest beta, but with the ATX patch applied. It won't work in the retail, patched version, unless the effects.tpa file is modified... so, that means that step isn't optional, but a requisite, something that isn't quite clear in the readme file...

That's true! I think some of the AI code is intermingled with the "Play Effect From Effects.tpa" code, so skip one and you skip the other. In fact, removing effects.tpa altogether seems to stall the testscene raptor... Anyway, I second Rebel's thanks.

By the way, if it doesn't attack you, shoot it! (import a gun if you must)

great work boys
and machf sorry if I sounded a bit stupid in my post above was having a bad day

what no screenshots yet?

Well, there's the video Rebel posted...

Yeah it's a very fast download. Looks pretty neat! Hard to make out
the spitting part, though. Frill looks very cool.

Slugger wrote:
Rebel, I'll say it again -- excellent work on the spitter.

Don't throw too much praise my way, out of the 3 who worked
on it, Big Red had the most difficult task and needless to say, I'd
dread to think of developing something so artsy without Remdul's
talents.



*Drac comment on Video: Yea, it's rather short, but good in as
far as short vids go. I wanted to keep the download under 1mb
to avoid size complaints.

Well, after checking that edited thread about the spitter development (no, I haven't read it all yet, still a bit busy), I must say it's quite interesting. Regarding the effects of gravity, well, eventually the spit should fall to the ground - it should only be effective at a relatively short distance, so I don't think you should have worried too much.

A comment by Big Red about geometry and math (hey, if you need help figuring out some equation, just ask) got me thinking... is it possible to do mathematical calculations within Trespasser? Can you use variables, and increment or decrement them?

Also, reading about triggers and all that... I suppose location triggers are 'fixed' to the terrain? What about collision triggers, can they be attached to (moving) objects?

Sorry if this isn't the place to ask, but those two questions had already been in my mind for quite some time and reading that thread made me remember them...

Oh, and I suppose the same principle for the spit can be applied to independent-firing guns...

I suppose location triggers are 'fixed' to the terrain? What about collision triggers, can they be attached to (moving) objects?

Fixed? I'm not sure I get the question, or the second one, Machf.
Could you elaborate a bit?

I mean, I suppose location triggers can only make reference to a spcific location within the level, like "latitude -12 degreees, longitude -78 degrees" and not something related to an object like "the back seat of the bus, wherever it is as it's moving". But what about collision triggers, can they make reference to two moving objects colliiding, or has one of them to be fixed?

I can translate. By "fixed to the terrain", he means that they are fixed
to a location (actually nothing to do with terrain). This is correct; as I
think I said in one thread or another recently, location triggers cannot
be moved. And as a "location" trigger they refer to box or spherical
volumes, btw, not points in space (that simply represents the center
of the bounding volume).

As for collision triggers, I guess I'm not 100% sure what you're getting
at, machf. I'm not sure that ANY triggers in the game can move,
obviously some classes can (like CEntityAttached, etc.), but not trigs.
Maybe your conception of the class is wrong; collision triggers can be
miles and miles away from the objects they refer to. It doesn't matter,
the trigger itself monitors their whereabouts. If one "element" is
listed, the trigger will activate when there is a collision between it and
anything. If two elements are listed, it will only activate when these 2
collide with each other (this is obvious enough). It doesn't matter if
either of these objects are moving; in fact I would say most of the
time both objects will have Moveable = true, though not always.

That answer your question?

Yep, thanks. I asked because unlike location triggers, which respond when something enters a volume, collision triggers don't define a volume to be tested and instead fire when two objects are intersecting. I suppose something similar to a location trigger could be achieved by having one of those objects be an invisible instance attached to another (smaller) object, so as to respond "when object A gets into the proximity of object B".

But, unfortunately, collision triggers don't have the range of options that location triggers do (detecting when something enters, is inside or leaves a volume), right? Pity. It would be great if a location trigger could move together with an object - now you may understand why I asked...

Any limitations on the type of objects which can be tested for collisions? Do they have to be Tangible, Visible, or have Mass, or something else? Could you detect a collision between, for example, a Magnet and an invisible/intangible CEntityAttached? Has anyone ever tried that?

machf wrote:Any limitations on the type of objects which can be tested for collisions? Do they have to be Tangible, Visible, or have Mass, or something else? Could you detect a collision between, for example, a Magnet and an invisible/intangible CEntityAttached? Has anyone ever tried that?

As far as I know, as long as the two named objects exist inside the level, the collision trigger will fire if said objects collide. Don't forget about the collision of sound.

Regarding the effects of gravity, well, eventually the spit should fall to the ground - it should only be effective at a relatively short distance, so I don't think you should have worried too much.

The problem was mostly that the engine couldn't handle high velocities, in fact it doesn't work at all with speeds somewhere over 100.0, so you could never give it enough speed to make it seem nice in game. The only way to simulate high speeds (as far as I know) in this case is to give a relatively high fixed speed to the object.

I think you can still test that out yourself if you feel like it using the SPT INI settings. Use ProjectileSpeed to set the speed of the spittee and set ProjectileExtinguishTime (milliseconds) to a very low value (I think 0 works; if not, try 500). That'll emulate the problem we had. Notice that setting ProjectileSpeed speed to high causes projectiles not to launch at all (or freeze), which demonstrates the engine limitation.

A comment by Big Red about geometry and math (hey, if you need help figuring out some equation, just ask) got me thinking... is it possible to do mathematical calculations within Trespasser? Can you use variables, and increment or decrement them?

Technically, I do that all the time (in assembly, of course). If you mean using T-Script values for calculations for detection by triggers, that's another story, and no, not really (for now).