I just had an idea. Instead of using triggers for multiplayer projectiles, can't we just use normal old +bryarbolts and modify them with a cog using commands like ParseArg() or SetThingWhatever(). A 0x200 cog running a fast pulse could pick up these templates and modify them depending on a certain value you put on them from the weapon cog, like a flag, something synced in a multiplayer game, or maybe even the model.
The problem I have is that I don't know how the cog would pick up these templates. I'm guessing FirstThingInView() might work but can it see through walls and can it have a full 360 fov?


------------------
GetThingSignature(Ace1);

That would be cumbersome and might be real laggy. Thats my opinion, but I am open to suggestions anytime.

------------------
The Sniper Missions. Current project, The Sniper Missions

The Magician Saber System.

The 2 riddle!

i agree it would lag like a ***** if any one had a 56K dial up or less.

but still, its worth lookling into. if everyone had IDSN or up, and a good computor that would allow you to amke a mod that would work from only one computor.

------------------
I am pjb.
Another post......
another moment of my life wasted.....
at least i made a level.
PJB's JK page's

-the PJB jedi rule book-
rule one, "never trust a bartender with bad grammar"-kyle katarn in JO

Rule Two, "Gravity is a crule misstress" -kyle katarn in MotS, and the alternatior MK I in AJTD

I don't see any benefit. One way or another, if you want something to sync over the network, data must be sent. Speed increase from an alternate method is probably negligable.

------------------
Bassoon, n. A brazen instrument into which a fool blows out his brains.

HR has done alot of work with triggers.

He says that they lag, badly. Sometimes they dont even get recieved. So using projectiles fired from the master.tpl is alot faster. And puts less of a load on the network.

If the pulse was local and checked which gun the player had out to set up the weapon specifications, then I'd assume it would have a speed increase.

------------------
Team Battle.

Yeah, FireProjectile is better for most stuff. If you need something like a rapid fire weapon, triggers or messages of some type are the only way to go. One message to turn on a local pulse, another to shut it off. JK uses UDP, a connectionless protocol with no error checking, just like most other MP games. It's much faster than TCP, but if packets drop, it doesn't care. That's probably why games' netcodes have some sort of error checking. It's my guess that FireProjectile does, and triggers do not.

------------------
Bassoon, n. A brazen instrument into which a fool blows out his brains.

Parsearg isn't synced over multiplayer. You would have to use a trigger to sync the effects... heh..

------------------
Project leader of Dbz:TDIR

I came up with this because I though it would lag less than triggers. The cog with the fast pulse that really does all the stuff with the projectiles is not synced. Everyone has this cog running but it doesn't send the data to other players, because their cogs on their side will be doing it to. The only thing that will be synced will be the special value that the non-synced cog looks for to change the projectile.

------------------
GetThingSignature(Ace1);

It's a good idea, but the flaws you have already noticed - "FirstThingInView() can't see through walls or have a full 360 fov" will prevent it from being an acceptable solution for most people. Plus there would be a fraction of a second that you see the original template before it is modified.

Your thinking is correct though - MoD / Level authors should try to do as much locally as possible. SendTrigger in a fast pulse is always a bad idea.

------------------
- Wisdom is 99% experience, 1% knowledge. -

[This message has been edited by The_New_Guy (edited June 25, 2003).]

I think it's a good idea. A lot of you are saying that it will lag. How will it cause any more lag than a normal projectile?

Think about it. You have playerx fire a bryarbolt. All computers are running a fast local pulse that looks for anything with a bryarbolt template. Once these pulses find playerx's bryarbolt, they'll change it on each comp to the new projectile - whether they change that projectile or create a new one.

There is no latency problem there, the problem is that using a pulse like that is not an elegant solution, and this limits you to replacing original templates. On the plus side, it's easy to implement and it gets rid of the triggers.

------------------
Author of the JK DataMaster, Parsec, Scribe, and the EditPlus Cog Files.

How would it know the difference between a +bryarbolt to be changed and a +bryarbolt to kill?

------------------
Bassoon, n. A brazen instrument into which a fool blows out his brains.

That's why we put a special flag or some kind of value on the projectile that is always synced in multiplayer. I was thinking its model could be this value trait since there is a SetThingModel() and a GetThingModel() and models are always synced.

------------------
GetThingSignature(Ace1);