Enhanced Brainstorming: Saber System

[keshire]

Also maybe something ripped from the locational damage? As long as the saber kept the direction it pointed in when it collides I don't think there'd be a problem.

[razorace]

Originally posted by keshire

Would this be helpful for bolt detection? Its located in the expensive physics source. g_exphysics.c Obviously I'm not a coder but I have taken a few classes here and there.

 

if (hasFirstCollision)

{ //at least one bolt collided

//We'll get the offset between the collided bolt and endpos, then trace there

//from the origin so that our desired position becomes that point.

VectorSubtract(collisionRootPos, bestCollision.endpos, trajDif);

 

VectorAdd(ent->r.currentOrigin, trajDif, projectedOrigin);

}

}

 

//If we didn't collide with any bolts projectedOrigin will still be the original desired

//projected position so all is well. If we did then projectedOrigin will be modified

//to provide us with a relative position which does not place the bolt in a solid.

trap_Trace(&tr, ent->r.currentOrigin, ent->r.mins, ent->r.maxs, projectedOrigin, ent->s.number, ent->clipmask);

 

That sounds like it's something used for part of the rag doll physics. That won't help with what we're looking for.

[Vile]

having the saber get stuck in the person when you throw it at them before you pull it back would be wicked!

 

Also about model dismemberment.....Could we get it to work in multiplayer (if it isnt already, as I never get to see someone cut up in multiplayer) maby my problem but so far I have only seen a arm cut off and what not in single player.

[razorace]

Actually we were discussing fixing that issue over here.

[Vile]

looks more like some sorta broken arm deal...I want to be able to cut people in half and stuff online.

[MasterSidious]

Now, this is an idea which I'm pretty sure would be very hard/ time consumming to code, but here it goes:

 

A saber system in which you could toggle from being able to control the saber to being able to move about. When you would press this toggle key, lets call it a, your ability to be mobile is disabled and you can completely move your saber freely around using the arrow keys and mouse. For example, the up arrow key will make the saber go out more and arc down in the frontal direction or the direction away from the player. The right key for example would make the same arc movement only in the right direction and so on. The mouse is used as a complete control of the saber around following the main arc pattern of the arrow keys. Of course the other saber code will still be available when you're mobile. Now, I know this might make an embalance in the game, so we or I will have to think more about how to balance. But, this is the general gist of my idea. What do you think? Do you think this is even possible?

 

This would in essence give the shall we say real jedis out there a chance to really show their skill. Not how you can move about, of course the old code as I said before would be in there too so everyone would like it. Well?

[razorace]

I don't think that will be nessicary since Mouse Sabering will allow you to be able to move and swing at the same time.

 

Besides, that would cause a lack of control issue.

[MasterSidious]

Yes, this is the problem. I guess there could be more special moves implemented. There could be some enhanced movements, movements so that you could hurt/control easier, that would be concentrated in more of the same place in realation to the character. A kata type animation for example could be made so that you could control where all the rotations or attacks happen in relation to your body. Adding another special move so that you could use it and know where most of the attacks would occur, like on the right side of the character for example. This would give more of an assortment of specials that could be done, adding to the already long list, making the player more easily able to hit things on different sides, and implement different types of attacks depending on the situations. But agreed, players need to be able to control the saber and at the same time be mobile for a better experience. This would give both, more versatility and still give the same amount of mobility.

[MasterSidious]

Also something possibly a bit more realistic. The saber movements done with the strafe keys especially could use a little help getting over the randomness. to be able to ALWAYS do a right attack for example. Am I just a noob here or are other people starting to find its sometimes hard? Just another thought

[razorace]

Well, it normally does what you tell it to do unless you're in a bounce, combo, or special move.

[keshire]

If I wanted to code the saber wall sticking back in I'd need to use:

 

entityStates right?

 

entityState_t->eType and eFlags

 

ET_MISSLE //To turn saber into missle? Does saberInFlight already do this?

EF_MISSILE_STICK //when touches wall?

 

and maybe EV_MISSILE_STICK //for a nice sound.

 

Or am I simplifying it too much?

 

Also can I just add a saber deactivate when the throw button is let go to cause it to not come back? So I could later add force pull to cuase the same effect?

[razorace]

Uh, this thread is for brainstorming, not technical issues. I suggest you keep it to the JA Coding forum. Thanks.

 

And I imagine that doing what you suggested will take quite a bit of coding effect.

[TheLiberator34]

Is it possible to slow down the overall speed of movement? I was wondering if there is a setting to slow down how a person on screen attacks(not just how fast you run). On a brainstorming note I was thinking including a dual phase saber might be a good idea. This would allow single blade users to switch to a longer blade length that does less damage but gives a single saber user added range to their strikes.

[razorace]

It's possible but not without coding changes.

 

A dual phase saber is interesting but it would probably not be worth the coding effort.

[jheriko]

I only have one suggestion for your project but I have a few questions about the code side of things out of curiosity since I toyed with the q3 vm source a few years ago (I never finished a decent mod, the only one I made is lost, not that I care cos it was crap but it was called fnf, then escape q3). Anyway...

 

Are button4 and button5 still broken or do they do something in JA? Have they been removed since q3? Or have you just used all 5 buttons? You could use button3 at least... I used it for something ages ago in q3 and it worked fine...

 

'There weren't any free data slots so I could improve the animation system.... ' I know this problem is resolved but what did they do exactly to make their animation system limited? Even with MD2 (way before skeletal animation and slerp and such) pretty much limitless animations were possible, or is it just not possible to call an animation routine of whatever kind from the mod source? eg. modelclass->animate(delta_time) or whatever.. i guess things like that just get left in the binary. I never really got into q3 modding enough to need something like that but it would make tremendous sense to include it (or equivalent) for modders.

 

My suggestion is to model 'real' dismemberment if you have access to the model data. You should be able to calculate the plane in which the saber (approximately) moves quite easily and use it to split the model down in to two (or more) seperate models. Triangle splitting isn't as hard as some people make out, neither is capping a 'planar hole' in an object since you already have the plane and the vertices lying on it. Checking if a model is in seperate pieces and then splitting it into them shouldn't be too hard either provided that you have the triangle data, you just need to write a recursive algorithm that traverses triangles by adjacency by doing some clever vertex picking and dealing with the cases where you have to go through a triangle twice to go over the whole thing and such... and complains if it finishes before it has traversed the entire model then makes the complete traversal a seperate model and deducts it from the rest. This way you can make it so that you could slice through an arm and the chest and have three seperate pieces fall to the ground independantly. On the downside it would probably take a lot of physics code since you would have to deal with the physics thats already there for dealing with dead bodies. Thinking about it all together... its a bit ambitious, but hey.

 

'Is it possible to slow down the overall speed of movement?'

 

Well there was a cvar in q3 that wasn't very well known which had to be set from the ui - timescale. I've just checked that its in JO, unfortunately I have no copy of JA to check it out with but try setting it to 0.8 or 0.7 or something from the console in the menu before you play... then everything will be slower. Probably not quite what you wanted but it will make it easier for you to beat those SP enemies that are just too fast for you. If its too easy try timescale 1.5, I used to use timescale to make the q3 bots into a real challenge, very handy to improve your skills.

[razorace]

That's a good question about the buttons. I think they have been removed or changed to the force power commands.

 

Your real dismemberment idea is interesting but I don't think that it would possible to do that sort of direct model manipulation without the engine code. Plus, it would be a lot of hard work for a relatively small payoff.

 

And lastly, the animation system for JKA is majorly different than Q3, and it doesn't allow things like frozen animations, starttimes accounted for lag, and dynamic animation speeds.

[keshire]

Saber Stick in Wall

 

Hit wall, walk around it. It won't come back unless manually grabbed. Due to looped sabermoveback statement.

 

 

 

 

Thrown high, ran up wall grabbing it. I'm especially proud of these.

 

 

 

[babywax]

That's really cool, does the player do an animation when retrieving the saber? Could you possibly give single saberists the ability to pick up sabers that are stuck in walls etc...? That would be very interesting...

[razorace]

Originally posted by keshire

Saber Stick in Wall

 

If you're planning on submitting this to OJP, please post about it in the "what's new?" thread.

 

Otherwise, get your whorin' ass off my property!

[Marker0077]

This is about the blocking system with returning blaster fire.

 

#1 I think that if the person is not holding the block button, then blaster fire should hit the person.

 

#2 The person has to wait for the opponent to fire & then press the block button in order to return blaster fire to the person that fired it.

 

#3 If the block button is held down before the person fired, it blocks the shot but returns it in a random direction.

 

This is how the returning blaster fire with a lightsaber works in most SW SP games & a variety of other SP games as well, like I was playing a DragonBall Z game with my cousin & one person throws small fireball at another, the person has to block right before the fireball hits him in order to return it, otherwise it's just a standard block.

[razorace]

I like that idea, but I see there being a problem with the way the manual blocking will work. You can't simply hold down the button to block.

 

However, it could work based on when you last set a blocking position or something.

[keshire]

Just have the auto-block when the block button is held down for gunfire only (psuedo-manual). Otherwise its manual-directional for saber vs saber. I thought this was the plan anyway?

[razorace]

The problem with that would be that you couldn't move while doing that. I don't think it's a good idea.

[keshire]

Are we disabling certain movements while blocking? I must have missed that.

[keshire]

Since I'm moving off focus I don't know if this should go in a different thread. If so Feel free to move it into a saber system -saber throw thread.

 

anyways.

 

As I said I'm working on changing saber throw into a single use action. By single use I mean it won't come back and has to be manually retrieved. Either by force pull or picking it up like any normal item.

 

I want this to be able to mesh well with Razor or Renegade's system's. So I'd like to pull this away from the alt attack. (which will be used for block).

 

I'm also trying to make it as realistic as possible. So far I've (beta) implemented wall sticking.

 

With that out of the way here is a list from RazorAce that he came across that still needs changing and my thoughts on them as well. Most were code problems so I'll skip to the actual thought(s).

 

Ok I testing things out and it's looking pretty good but it needs some additional work before I'll think it's ready:

 

5. When the saber sticks into something, I suggest you make it act like a fallen saber, that way the player can do other things and it should hopefully fix issue 1.

 

6. While you're at it, it might be a good idea to fix the rest of the saber throw behavior...

 

Please note that I'm listing so much because you made great progress and I think it will be great when you're done.

 

Razor Ace

 

I think the force levels should be changed to reflect a new realistic system.

 

Take out the "follow view" that force throw 3 gives you.

 

And make it like so.

 

force level one.:

basic throw (ie use force to keep it on while in air)

 

vertical spin (ie easily dodgeable)

 

I plan on making a new throw animation to occompany the spin.

--------------------

Force level two:

Goes an amount of distance equal to how long the throw button is held or 3 seconds whichever comes first.

 

Diagonal spin

 

I plan on making a new throw animation to occompany the spin.

--------------------

force level three:

amount held or full 6 seconds that is the current coded limit.

damage * 1.5

 

current horizontal spin

-----------------------

I also want to impale oponents if a thrown saber hits someone before the full force level time is expired. Ala AOTC cartoon.

 

any other suggestions?