i'm sure i'm not the only one whos notices but when you load a saber mod, say sbx, that the saber for the first person perspective has no trails like that of the 3rd perspective. when i was playing birth of a mercenary for mots i knowticed when i went in the vent of the 3rd episode right before you're "discovered" by vader that the 3d perspective camera comes in very tight on kyle making it so you only see his arms and saber. anyway if you swing it you can see trails and what not and the point that i'm trying to get to here is this, is there anybody out there who would know how to put the camera in kyle's perspective similar to the way outcast works, i think it would be a cool thing to have, and sorry for the long post

Use. Periods. Please.

There's no reason to have a first person saber trail, if you saber in first person, there's a reason you always lose. In-fact, I'm pretty sure SBX3.1 disabled first person view with the saber for this reason.

JediKirby

------------------
jEDIkIRBY - Putting the Romance back into Necromancer.
Proud Leader of the Minnessassian Council

Live on, Adam.

...well, the bashing of the idea aside I think it would be nice to do for at least the sake of being complete.

What you want can be done, and its actually not to hard and I've done something similar to make legs viewable in first person. Take a kyle model and set all nodes but the arms to be invisible or flat out remove them. Make sure the node heirarchy is preserved. Rather then setting the internal weapon mess, set it to nothing. Create and attach the new model to the player to create a second 'body'. Playkey on this body using the saber animations to match the external ones.

Add in some tweaks for when the things not immediately obvious and some code to flag the second body as invisible for 3rd person mode and you'll have yourself a matching set of internal animations.

You might want to clean up the hand models though...the default external ones are pretty boxy which will be very obvious when viewed from that close.

1st person saberist = pile of jedi meat

------------------
...how easy life would be... if only it came with a consistancy checker.
Fabricator of Neurotic for MLP4

wow I just tried that, I put a camera "inside" kyles head and it worked pretty well. Except for a few animations where you can see kyle's head when he swings, Other than that, it's very nice looking. You can even see your legs when you look down. It's smoother than the default JK pov saber and it looks almost like JO's first person saber, but it's still crap to handle compared to 3rd person.

------------------
I am __Ace_1__ , and I approve this message.

[This message has been edited by Ace1 (edited August 24, 2004).]

Ace that is another way that you could do it which is probably easier then my way now that I think about it. If the head is blocking some of the view, just amputate it and then use some code to swap remake the head when you switch to third person.

Notes that I found out the hard way.
* You will need to change the player model to a different model and then BACK to the original model to readd the head after amputation. If you just try to change model to the same model, JK/Mots just ignore the call and do nothing. It must check to see if your model matches before doing the change and if it does it doesn't bother doing so.
* Since amputatejoint() is not network synced, you shouldn't have to worry about funny effects on other multiplayer machines. This is one of those rare instances where the lack of network syncing is actually beneficial.

I'm pretty sure if you change to the same model it already it is, it doesn't send syncing data for the change either, so a pulse that constantly changes a model to the same model wouldn't lag due to this... so it's sorta a good thing.

Personally, I wish more things were unsynced. ParseArg() is probably my favorite verb. I didn't know AmputateJoint() wasn't sync'd though... good to know.

Also, I've beat the suck outta people in first person view with the saber (uhm, like 5 years ago when people still played JK), it's no different than 3rd person view if you have a good spatial understanding of where you are (though I do favor 3rd person view sabering).

All that said, go with a camera I'd say, that way you aren't having to deal with an unsynced, animated model. If your camera template has a timer of like 1 second, and you just use ParseArg(camera, 3600); after creating the camera, it will disappear on other computers, but stay on yours for your cog's use. Also, CaptureThing(camera); and have a removed: message in the cog that sets your camera back to the player just in case the camera is destroyed (to prevent crashes).

QM

That bit was a little unclear on my part. Let me explain what I meant. When you amputate a joint and then want to get it back you have to use setthingmodel() to 'reset' the model because there is no unamputate joint verb in cog. But if your model is say kyle.3do and you've amputated his head and then use SetThingModel(player, kyle.3do) to get it back nothing happens. Kyle still is missing his head. Why does it not reset the model? I figure JK checks to see if the model is already kyle.3do before running the calculations of changing the model, to save CPU time. We *are* kyle.3do...but we want the HEAD back! So my workaround for this was to setthingmodel() to say a tie fighter or a bryar bolt-whatever...then immediately setthingmodel() back to kyle.3do. No one sees the change because its so fast and it in effect forces JK to readd the model. Its just a way around a JK quirk. Things get even *more* dicy with this once you throw multiplayer syncing into the mix...you've got to be careful with your code.



Its been awhile since I played with this...but I'm almost positive it isn't. I remember working out some sendtriggers to assure the correct joints were amputated everywhere.



Remember that it doesn't matter if this model is synced...this is for first person mode, no one else is *suppose* to see this. Regardless, I agree that the faked internal camera in external mode is a good way to do this because its very hard to get internal and external animations to run the same...a lot of them are handled via pup which is triggered via the players controls.



Good advice about using removed as a last catch to avoid crashing. But in these instances, I either user fireprojectilelocal (which is MotS only I believe) or I take advantage of the fact that static.jkl templates are not created on other computers and make a new ghost/camera template and just use it as normal. Since the template cannot be created in multiplayer you don't have to worry about the other side. A cog using local flags works as well, theres no wrong way to do it...just different ways.

Parsearg is a cool verb...but its sometimes a pain to sync and parts of it are unstable. I tend to avoid if possible myself.

[This message has been edited by Wave_Of_Mutilation (edited August 24, 2004).]

Except that you weren't. I understood you 100%. I was just pointing out that besides not giving you back your head, if you SetThingModel to the model that it already is, it also doesn't sync this "not change" over the network.


My point was it's better if it's unsynced. If you have a visible model (as opposed to an invisible camera) you'll need to be even more sure it's unsynced. But, having the camera unsynced is a good thing so your computers won't try to reconcile it's location every now and again.

Also, I typo'd: ParseArg(camera, 3600); was supposed to be ParseArg(camera, "timer=3600");


Yet another thing I didn't know about syncing. I thought static.jkl projectiles caused no damage, didn't know they weren't even created on the other person's side. I eprsonally avoid static.jkl like the plague (like it sounds you avoid ParseArg).


I use it because I DON'T want the effects sync'd. Nearly everything ParseArg can do can be done with other cog verbs if I want a syncronized effect.

I guess I just don't use those (unstable) parts... I use ParseArg quite a bit and never get a crash from it. Well, I don't get crashes at all... I honestly don't understand how people make mods that crash (JK Advanced, I love the mod, but dang if I can't play it for more than 5 minutes).

http://everbot.tripod.com/toolbox.htm
My simple little mod has a few real nice examples of neat cogging tricks:
weapon 2: zooming in JK without a projectile
weapon 3: non-crashing thing based internal model
weapon 4: pulse based firing rather than fire (not really that special, but not often done)
weapon 5: shoots through walls
weapon 6: two weapons on 1 select key in JK. also rerouting of skill messages through a mediating cog
weapon 7: a projectile with air drag (not super special, just neat)
weapon 8: alternate style of arcing projectiles, produces better results than having the projectile effected by gravity (like thermal dets)
weapon 9: a projectile that traces walls (in other words, if it hits a wall it slides along it rather than exploding or attaching, hitting someone if it flies by)

I sorta made it to be a resource for other editors.

QM