I'm wr0king on my saber mod, and I come up with a cool little idea - make the anims normal for blocking a lightsaber, but when blocking bullets, play a swinging animation, so they bat it away like in the movies.

It sounds fine on paper, but I have absolutely no idea how to identify the thing that initiates the block.

See... erum... this is the part where Massassi saves me...

Ive never done saber cogs before, so I dont know which message handles the saber block . . . but try Getsourceref() under that message...

Tried. -_-

Getsourceref() doesn't work, and getsenderref() is the player.

I don't know what else to do.

You can't. Had you gotten a copy of the Datamaster, you would know that the blocked: message doesn't send info on what was blocked. You could however, use damaged: and get exactly what damaged the player, and just fire out a projectile of the same type in a random direction with an appropriate keyframe. Mind you returnEx(0); when you do. Just like Rbots.

That's kinda what I'm doing for the Magician Saber System. Removing the auto-block and replacing it with a dammaged message (for Saber Locks). But that is the only way to do it, remove the autoblock, check the damage flags, and play the blocking animation, haven't gotten far enough to tell you what to do about reflecting projectiles. Sorry

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

The Magician Saber System.

Just list the projectile templates in kyle.cog, and just GetThingTemplate(GetSourceRef()) inside the damaged: message. Easy as pie. Add all the neccessary checks tho so you don't wind up creating a walkplayer if you fall and get hurt.

[This message has been edited by Hell Raiser (edited November 16, 2002).]

It's a good idea, but it can't be realised in a good looking way, because you would have to start the animation BEFORE the player gets hit. And that is impossible.

------------------
"Häb Pfrässe, süsch chlepfts!" - The coolest language in the world (besides Cherokee)

Hmm...you could make the weapon fire two projectiles, an invisible one with a Y-Offset of 1 and the standard projectile, then have the blocked: message only react on the invisible one...but that's probably too much work for that effect...

------------------
"Häb Pfrässe, süsch chlepfts!" - The coolest language in the world (besides Cherokee)

Hmmm... how would you make a saber block other sabers, but not projectiles, and how would you make a saber only block on secondary fire?

Would it be conceivable to have a super fast pulse running a firsthinginview() to check for projectiles about to hit the player and then start the reaction prior to the projectile ever hitting the player that way?

It most likely wouldn't work, and if it did it would probably be buggy. But I'm just brainstorming.

This might work, but probably not for multiplayer...

------------------
"Häb Pfrässe, süsch chlepfts!" - The coolest language in the world (besides Cherokee)

It would work perfectly in MP. A projectile in a players view is a projectile in a players view. Only problem might be executing it at the right time, every time.

Hell Raiser: So you're saying that even when the bullet harmlessly bounces off of my saber, it still calls damaged:? And I have datamaster, you personally sent it to me over IRC, remember? This was before I got kicked out of #dbztdir by Vash.

You see, that would be really convenient, because blocked: and damaged: are both in Kyle.cog, so I wouldn't have to do a whole lot.

And Zagibu: Why the hell go through all that trouble? Just open the 3do and orient the bullet so the actual center is a little in front of the visible bullet.

[This message has been edited by Checksum (edited November 24, 2002).]

No. You disable saber blocking and do it "manually" with damaged:



Has anyone actually seen the way JK does the blocking? It's not like JO. The projectile actually hits the player, a super duper fast keyframe is played and the projectile is bounced back. It'd look the same to do it this other way.

Hell Raiser is correct, moving the projectile's model back in the 3do file wouldn't really change the way JK reacted.

The fact that its multiplayer shouldn't affect the firstthinginview() method at all really, all the relevant searching and reacting would be done pretty much locally anyway.

But, because the bullet turns around when blocked, it would create the effect of covering the gap.

Either way, I came up with a different approach, so there.

If you just moved the center forth, the visible bullet would never hit the player, but turn around some feet in front of him...

------------------
"Häb Pfrässe, süsch chlepfts!" - The coolest language in the world (besides Cherokee)

Um.. no... it wouldn't...

When it turned around, it rotated on its center, making the bullet appear to come from the player.

Still, no matter what it does, it will never look like it's just turning around in front of him.

Yes, you are right...it would appear BEHIND the player...

------------------
"Häb Pfrässe, süsch chlepfts!" - The coolest language in the world (besides Cherokee)

Ok, update on this whole thing: I found out that touched: is called if you block a bullet, so I just ran a check for the 0x2000 flag in touched: and used it to identify it, got it working perfectly.

Thanks to everyone for their help.