ok so blocking is covered, great now about my new force powers, I have an idea for Force Levitate and for Force Blast.
Force levitate will allow you to levitate and obejct (if possible) or yourself (not fly but allow you to jump from very high places and not get hurt at all (unless you run out of force energy) and for other things, the Force Blast can be like a big bubble or force energy that pushes everything around you away like a massive force push to all around you, and than the level of it (1-3) can change how powerful of a puch it is and the radius of effect :) and ofcourse it should take like 80-100 force energy to use. (I say 100 but less is ok too) So if those are good ideas I can try and work on code for it and the animations (I think I can get the animations done) Also razorace you have a IM so we can talk about stuff I can do for the OJP?
btw this is what you say on the site:
Mouse Sabering:
Use your mouse to perform standard, special, and defensive moves and combos from all 3 stances at once! This will include several HUD additions including a fading crosshair trail and new crosshairs to make this as fun as possible. For traditional players, you can still do things the old fashion way with the addition of a defensive position system.
soo what you saying is that you move the saber with the mouse to attack and block? hows that supposed to work ?
Try reading the italian interview that's on the site, I beleive that goes more in depth.
And Force powers charges are a completely different subject. Start a new thread please.
ok I will look for the interview and sorry will make new thread.
so what about the IM? :D
So on topic any already plans for new styles? or moves?
IM? What IM?
At this stage, I'm still just digging thru things to figure things out and get back in the swing of things. New Stances and stuff will come later.
Baby steps. Baby steps.
i like the way the blocking and dodging is done, for anyone who doesnt understand mouse sabering go here
http://motf.jk2files.com/motf.cgi?action=interview)
i had an idea but they pretty much got it covered
is this going to have force powers???
We will see, it depends on someone actually working on it and then submitting it to OJP.
Anyway, I've added in the head lock grapple move of kyle's to the game but I'm not sure how I should handle things.
Should the grapple/kick/melee moves be availible when the saber is turned off or sure there be quick commands that directly do certain moves? I'm concerned about balance, realism, and the possibility that the quick commands will lag the game/be too slow to respond. Any feedback on this would be great.
Also, I think I have an idea on how to make melee moves vs sabers realistic and balanced. I'm thinking that the defender's saber (even in idle or a block) should cause damage to the attacker if he touches it at all. Is should force the attacker to dodge, take damage, fall down ("ARGH! I just burned my foot!"), etc. Since this will be based on the actual position of the defender's blade, an attacker can still make melee attacks if he's careful.
Plus, to make this worth it for the attacker, I'm thinking that melee damage should bypass Dodge (assuming that the defender is using a saber; melee vs melee should probably have Dodging) and/or cause knockback/Fatigue.
Sounds good to me.
But, how about shortening the headlock move and making it only work if hit from behind? Lower the damage and have the attacker drop his saber? And really, is the grabbing the foot and swinging them around realistic? Maybe if done by a Jedi.
Oh yeah, I'm also thinking that everyone should have melee as a "weapon" that is linked to some Force skill (I'm not sure which yet).
Pressing your weapon 1 button would switch between saber on and melee mode (instead of just turning the saber off) and using the buttons without the saber on will do melee moves instead of saber moves.
I also think Melee damage should scale inversly with saber attack level? But thats just me.
How about applying it to an acrobatics force level, with selectable flips, and cart wheels based on level?
Originally posted by keshire
Sounds good to me.
But, how about shortening the headlock move and making it only work if hit from behind? Lower the damage and have the attacker drop his saber? And really, is the grabbing the foot and swinging them around realistic? Maybe if done by a Jedi.
I beleive the animation is set up to be entered from the front.
Yes, the possibility of the defender dropping their saber is exactly the sort of thing I'm talking about. :)
And the move you describe would require new animations. Doable, but I'm not going to do them personally. :D If someone does the animations, I'll put them in the game as long as they were reasonable and don't suck.
Originally posted by keshire
I also think Melee damage should scale inversly with saber attack level? But thats just me.
Why? The point isn't to allow mercs to beat the living crap out of Jedi. :)
How about applying it to an acrobatics force level, with selectable flips, and cart wheels based on level?
Well, I consider new force skills/player attributes to be a seperate part of the project, I can mess with them laster. I just need something quick and dirty to link it to.
Originally posted by keshire
I also think Melee damage should scale inversly with saber attack level? But thats just me.
Why? The point isn't to allow mercs to beat the living crap out of Jedi. :)
How about applying it to an acrobatics force level, with selectable flips, and cart wheels based on level?
Well, I consider new force skills/player attributes to be a seperate part of the project, I can mess with them later. I just need something quick and dirty to link it to.
And the move you describe would require new animations. Doable, but I'm not going to do them personally. If someone does the animations, I'll put them in the game as long as they were reasonable and don't suck.
Some fiddling with the animation.cfg should do the trick. start it at the point where the victim gets turned around?
Why? The point isn't to allow mercs to beat the living crap out of Jedi
Very true. But it shouldn't be tied to sabering. I'm thinking poeple specialized in martial arts here.
Originally posted by keshire
Some fiddling with the animation.cfg should do the trick. start it at the point where the victim gets turned around?
That might work, but there's a concern over animation skipping.
Very true. But it shouldn't be tied to sabering. I'm thinking poeple specialized in martial arts here.
I think so too. Maybe Force Push/Pull?
What about jedi vs merc servers?
Only jedi get melee? Thats the problem with tying it to a force power.
Well, I was referring to the Force enhanced grapple moves. Most of them simply wouldn't be possible without using the Force.
looking at the anims the grab can be left the same. Skip the first few frames of the being grabbed in the animation.cfg and can you code it so it starts a little late to sync them up? Not to mention adding if attacking from behind? Is that even possible? Haven't seen it done yet anywhere in the code.
Well, I was referring to the Force enhanced grapple moves. Most of them simply wouldn't be possible without using the Force.
Ahh, so true, and yes that would make sense attached to push pull.
I'd like to follow up on the idea I proposed about making saber throw single use.
I found this saber flag that isn't helpful. since ALL the code related to it was taken out. q_shared.h
//#define SFL_STICK_ON_IMPACT (1<<?)//if set, the saber will stick in the wall when thrown and hits solid architecture (good for sabers that are meant to be thrown).
But I'm sure it can be re-implemented. Is it possible to also make it stick "in" players ala the AOTC cartoon? Then have force pull bring it back? And add some of that expensive physics mentioned in the source ;)
Also while I'm on the subject of sticking in players. What about the rolling stabs? can we do the same. stick in player, lose saber.
expanded use of the force powers (pull in this case) are always a good thing.
That's a good idea. However, I'm not exactly sure how we'll impliment it for player models since attaching something to the model usually requires it to be attached to a "bolt".
Can't attach it to closest bolt upon attack? You got plenty to choose from :)
Well, you could but that would require a pretty length bolt position scan function. Plus, models are bolted to bolts by their model origins. There's probably some function to get around that but I don't know about it yet.
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);
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.
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.
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.
looks more like some sorta broken arm deal...I want to be able to cut people in half and stuff online. :D
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. :D Well?
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.
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.
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
Well, it normally does what you tell it to do unless you're in a bounce, combo, or special move.
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?
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.
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.
It's possible but not without coding changes.
A dual phase saber is interesting but it would probably not be worth the coding effort.
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.
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.
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...
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! :D
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.
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.
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?
The problem with that would be that you couldn't move while doing that. I don't think it's a good idea.
Are we disabling certain movements while blocking? I must have missed that.
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?