Editing Force Powers???

[Cyrus_AVN]

Current force usage makes the gameplay 'best jumper wins' in lightsaber combat. It causes a view far from the movies. Every bodies jumping in the air and running everywhere. Just like olympic games, many athletics with sabers

 

To solve this problem a force focus time will be added. Ex: Player will press the button until force jump level bar is full, the later relases the button the higher he jumps(level 3 if avaliable).

 

If he relases the button in a short period he uses level 1 force jump and if he releases the button after a long time he uses level 3 force jump.

 

'Dark Forces 2: Jedi Knight' and 'Mysteries Of The Sith' expansion pack uses this sistem and I think these games have better gaming experience for players!

 

Well... But I need help How can I edit force powers or where can I start?

[AJL]

In my opinion the way how force jumping works in Jedi Outcast

and Academy is much better than that in the earlier jedi games(its much more natural... easier to use...)

 

And I think the force jump shouldn't take much force energy but

there should be delay in it which allows you to use force in the

jump only once per ~2-3 seconds... (starting after landing so

the jumping time have no effect in it...)

[Cyrus_AVN]

Hýmmm... This could be difrent way...

 

But is there any body who knows about edit force powers...???

[Tinny]

do you have access to the ja sdk and a copy of visual c++ or studio?

[Cyrus_AVN]

I downloaded a file named 'jka-universalSource'. Is it the right file? If it is right one; I'll build this code but I don't know where can I start to edit...

[razorace]

w_force.c is a good place to start.

[robo85045]

The code for that is still in there (i think), look for #define METROID_JUMP and disable it.

 

I know ive seen several referances of some sort of charging method of jumping in the game that were disabled or just not called because of an #ifndef METROID_JUMP

[razorace]

Zombie thread!

[Vruki Salet]

I was going to make how much you can jump in a duel saber form-dependent, but generally limit it during combat. Maybe within a couple seconds of swinging at a lightsaber-weilding opponent duelers of most forms could only jump high enough to dodge a blow to their legs...or something...

 

Form 4 would be better, form 8 maybe somewhat better.

 

I think a limit on running during duels might be nice too. Any opinions on that?

[razorace]

So what's the overall purpose of your mod then? I'm interested in what you're doing with the saber system.

[Vruki Salet]

I've been working on a Saber Forms mod. Right now though I'm taking a step back to re-mod the dueling system. I modded it a bit but now I'm not satisfied so I'm going to take out the Forms part and just work on basic saber combat (call it Form 1 or 6 if you want) until I think it's good and then I'll go back to adding Forms variations.

 

Some things my system has or will have:

 

No more tying move keys to saber combat accept in certain cercumstances when an advance or retreat can benefit your offense or defense. I don't like have to run in a certain direction just to swing.

 

Limiting movement and jumping to someone in a saber duel (meaning someone who's trading blows with someone else and both have lightsabers or swords). I want the duellers to spend more time closer one another, trading blows. (Form 4 will be more active btw so save "what about Yoda" questions

 

More saber control. I don't like all the crazy saber bouncing that goes on. I want the move that comes after you hit someone else's saber to be under your control *unless* you are very low skilled or are being beaten really badly. The duellers in the movies are just so more sauve then us and I want to try to imitate that.

 

Several kinds of swings, four that I have in mind atm that I call "duelling attacks," "killing attacks," "duelling defense" and "killing defense." First I'll explain that those personal force-field shields will be gone unless you're a droideka or somesuch. I'm turning those points into duelling defense points (call em DDP) that any skilled person with a ready saber has lots of at least initially. Turn the saber off or drop it and they're gone and attacks go right to your body (Health Points) and you get chopped up. Turn it back on and the DDF are back as a buffer.

 

The default kind of swing will be the "duelling attack" and this is a swing to wear down or disable the opponent's DDP. The game shouldn't show these blows landing on a body. I noticed that in the movies many swings were aimed at the opponent's saber. I know really this is because it's just stage combat but I saw that in EP I and EP III sometimes they did a good job making it look like a fighter was trying to push/twist/knock the other's saber out of the way so I decided that these kinds of attempts to create an opening should be considered a real part of lightsaber duelling. These swings will probably cost nothing to make and there will probably be no penalty to you if yours are parried or miss.

 

"Killing attacks" aren't necessarily always literally killing but they are attacks meant to bypass or penetrate the opponents defenses (DDF) and do actual body harm, like to health points. They will probably have some cost to make and there is a chance of failure that's greater the more DDF the defender still has. Failure will incur some kind of penalty.

 

"Duelling defense" swings will be parries to counter the duelling attacks and "killing defense" swings will be parries and blocks to hold of killing attacks.

 

The exact costs and benefits of these swings vs. each other will vary by Form. For example Form 3 will be better in duelling defense while Form 2 will be good in killing offense.

 

I see lightsaber duelling as a struggle between combatants to be the one who controls both sabers with occasional opportunistic body attacks. The saber = your defense and when you lose all your DDF then you're too worn out to use it right, or it'll get pushed away, or you'll lose it, or you'll get knocked down or stunned like Qui-Gon. Then you'll be open to a real killing blow.

 

(The names I have for these swings - call them stances if you like - are just working names and I don't really like them so if anyone has any suggestions about that speak up.)

 

Maybe I'll put up more about planned future stages to my mod later, like how I want to do the Forms and what I might go on to afterwards.

[razorace]

Sounds interested. Have you tried OJP Enhanced saber system yet? It's a bit similar to what you described except it uses Dodge points and Fatigue points instead of your DDP concept.

[Vruki Salet]

I considered using OJP as a base but I only barely have any grasp of the original sabering code and just got confused trying to layer my changes on top of yours. I've tried ojp gameplay and it's cool but I haven't practiced enough to get any good with it. Haha I'm so out of practice actually playing the game instead of modding it that I'll probably suck at my *own* system.

 

I went online a long time ago to try the ojp server but I got killed too fast to learn the system there. (I'm one of those despised and reviled duel-FFA types who think of JA as a cool saber fighting game but a really lousy deathmatch game. If I want gun battles give me unreal tournament or battlefront.)

[razorace]

I agree, JKA is all about the lightsabers for me too. The beta server mainly just runs what players want rather than my personal favorites (thou my favs do come into consideration).

 

Anyway, my point is that it would be easier to just work together on a saber system than it would to make seperate systems, especially if our proposals are fairly similar.

[Vruki Salet]

When I started trying to put my system into ojp I made my changes appear only if a cvar was set to 1, otherwise it was default ojp. So I guess I could try to work alongside ya without breaking too much. I'll take another look at the ojp code and see if I can understand the differences between it and original JA and if I can work with it.

[razorace]

Well with OJP's saber system I basically rewrote the entire hit detection and CheckSaberDamage to make the system be completely different. I also made various changes to the bg_move files to make the transitions work much more smoothly. I really don't like the auto-bouncing of basejka. I can go into more details if you'd like but I think some of this is in the documentation.

[Vruki Salet]

No please go into detail. Explain your changes - I'm interested.

 

Oh, BTW adding frames to the saber anims isn't taking much time. Not all moves might need to be done, at least not at first.

[razorace]

Well, here's my fancy little changelog that I made especially for the saber system. I'm not sure if this is a complete listing or not. Most noteably, I also rewrote the saber throw code to have a more realistic behavior.

 

==================================

Enhanced v0.0.2 b6:

 

Super Duper Interplotation system - This gives you a higher level of hit detection without having to boost the sv_fps. We recommend you try this first before you touch the sv_fps. Is controlled by d_saberInterpolate. The game defaults to Super Duper interplotation.

 

d_saberInterpolate 0 = no interpolation

d_saberInterpolate 1 = Raven's interpolation

d_saberInterpolate 2 = Super Duper interpolation

 

Enhanced v0.0.2 b5:

 

- Fixed a major bug in the Real Trace function code.

 

- Fixed bug preventing saber bounces from occurring.

 

- idle sabers don't go into bounce anymore.

 

- added "bot_fps" cvar. This controls the fps of the bot ai code so you can raise the server fps without increasing the bot ai's. defaults to 20 (fps).

 

- fixed partial dodge math errors.

 

- Faking system tweaking:

- to abort an attack, simply let go of the attack button.

- to perform a fake hold down attack + block + movement key for the attack you wish to use. You need to already have started/be in an attack for this to work.

 

- Force Fall starting fall speed tweaked

 

- Fixed Bug in impact (fall) damage code logic. Client 0 was getting free pass. I beleive this is due Raven accidently leaving some SP code in MP. (BugFix3)

 

- Saber Clash Effects now use the saber wound debounce (g_saberDmgDelay_Wound) to prevent effect spazzing at different sv_fps.

 

 

Enhanced v0.0.2 b4:

 

- Removed manual blocking button. Replaced it with block/parry button. Hold to block incoming saber attacks. To parry incoming attacks, press and hold the block button right before an attack will hit. Entering block/parry mode costs 1 FP but you can stay in it as long as you want without cost. However, remember that your parry bonuses (chances of forcing your attacker into a knockaway, etc.) go way down after a second or so off holding the block button.

 

- Totally hacked the bots to walk instead of run everywhere.

 

- Remember to make sure that...

sv_fps is set to 50 or 100.

g_saberDmgDelay_Wound = at least 100

cl_maxpackets = sv_fps

 

- g_debugsabercombat 7 = Debug messages for the parry bonus results.

 

- g_dodgeRegenTime changed to 1000

 

- g_forceRegenTime changed to 500

 

 

Enhanced v0.0.2 b3:

 

- Dodge Blocking works now.

 

- PreCog (IE dodging before something happens) Dodges for thermal weapons and other explosive weapons.

 

- Walk speed increased.

 

- You can now use the block button to override the manual blocking.

 

 

Enhanced v0.0.2b2:

 

- g_saberDmgDelay_Idle & g_saberDmgDelay_Wound now control how often often hits against the exact same target will register. This is to prevent the damage levels and saber/dodge behavior from acting differently when you're using a higher sv_fps setting. This translates to more consistant damage as well.

 

- Players now become fatigued at 10% of max FP. When fatigued, players make attacks much slower.

 

- You can now only walk during a Knockaway.

 

- Default value for g_saberanimspeed changed to .5.

 

- Fixed issue with g_saberanimspeed affecting some of the wall animations.

 

- Activated the two hidden stances (tavion's and Dasain's). They are now part of the single saber's stance cycle but they don't have seperate hud icons yet. (HiddenStances)

 

- Proto Visual weapons code - While you're not using your saber, it will appear on your belt. This only works for specially prepared models. (VisualWeapons)

 

- Dodge guage now flashes and makes sound when dodge is under 30.

 

- Both Dodge and Fatigue guages flash when low.

 

- Moded Force Fall so that it gradually slows down = instant slow down.

 

- Saber Fakes - pressing the block button before an attack starts will make your player do a fake. Using Block + a direction will transistion the swing into different attack (based on the direction pressed). Using Block without movement will cause the player to abort the attack and resume the ready position.

 

 

Enhanced v0.0.2:

 

- Teammates' Sabers now collide with each other even if friendly fire damage is turned off.

 

- Teammate NPC blades now collide with other teammate blades.

 

- saberthrow is now binded to button12 (+button12 for binding purposes) and/or selectable thru the force menu. Either will still operate the kicks with the saber staff.

 

- Turning off g_saberBladeFaces will result in poor viewlocking on saber impacts so don't do that.

 

- changed d_saberSPStyleDamage to 0 for the default. It was causing problems with viewlocking with idle saber damage.

 

- Viewlocking!

 

- Manual Blocking. Hold down secondary fire and use your movement keys to set a direction. The current controls are inverted (backwards for upper positions, forwards for lower) The availible positions are Lower Left, Lower Right, Upper Right,Upper Left, Top.

 

- Hilt bash should in theory work now.

 

- Fixed issue with the double/dual saber animation spazing while standings still and holding block position. It was due to the block animation trying to restart each time the block position was refreshed. Since this is no longer the case, blocking will now take up less bandwidth. Yeah!

 

- Moved all the movement set code for the blocking to PM_SetBlock(). It should be easier to edit now.

 

- For now, I've made the special moves go at normal speed. We can mess with that stuff later.

 

- Added Movement locking.

 

- Sabers now bounces off players (and other damageable objects) when the saber does non-lethal damage. Layman translation: NO MORE GROSS SABER PASSTHRU.

 

- Added Corpse and saber throw checks to view/movement locking. Also, added a check to prevent moves from view/move locking when you hit the ground (since many animations do that naturally).

 

- saber throw button (button12) added to idle client checks.

 

- sabers now use actual saber radiuses for saber collision checks.

 

- Rewrote saber tracing system (I call it a Real Trace now) for better performance and accuracy. it's not 100% (there's some crazy situation where it isn't guarnteed to be perfect, like when multiple players and sabers touching the same saber @ the same time), but it's perfect enough for all the SANE situations that I could think of.

 

- sv_fps is now set to 50 for improved hit detection. Please note that you might have to do some setting tweaks (that I can't do for you) to get the most out of the change. See http://www.techspot.com/tweaks/jedioutcast/jedi-6.shtml for details.

 

- AI now uses saber throw correctly.

 

- anglar and linear movement now affects saber damage levels. Running towards an opponent while spinning into an attack is do more damage. Each element does about %60 +- when at maximum.

 

- Saber behavior completely rewrote.

 

- Running or moving faster than a walk greatly increases your chances of screwing up.

- Manually block an attack has a high probability of creating an openning in your opponent's defenses

 

 

- New Saber Defines can be found in w_saber.c under the tag "SaberDefines".

 

- new debug mode cvar - g_debugsabercombat 0 in debug mode. This cvar is used to test the new saber behavior.

 

0 = none

1 = attacker butter fingers

2 = attacker knockaway

3 = attacker knockdown

4 = defender butter fingers

5 = defender knockaway

6 = defender knockdown

 

- new saber hit detection cvar - d_saberBodyCheck 1. Determines weither or not a RealTrace does an additional ghoul2 trace to determine if the player body was hit when the saberEntity was hit. Layman translation: It takes a little bit more CPU (shouldn't be noticeable) to ensure that the player hit detection is accurate whenever sabers are colliding.

 

- Fatigue:

 

Your Force Points now regenerate at a slower rate and most combat actions cause Force/Fatigue Points. Attempting a saber move that costs more than your current FP will result in you doing the move much slower than normal. The objective of this system is to make players concentrate on fighting smartly by effective mixes of attacking and defending.

 

Fatigue Regen Rates (dependant on g_ForceRegen setting):

Standing = Standard (= 1 FP per g_ForceRegen milliseconds)

Running = No Regen

Walking = Standard/2

Meditate (using the meditate taunt) = Standard * 3

 

Fatigue Costs:

Standard Saber Attack = 1

Standard Saber Spin (transition) = 1

 

- I've set up some easy to find tags for the defines that determine their behavior.

Saber System (SaberSys) = SaberDefines

Fatigue System (FatigueSys) = FatigueDefines

Dodge System (DodgeSys) = DodgeDefines

 

Dodge:

 

Dodge is a brand new system that prevents you from taking damage. Whenever an attack is going to hit you, Dodge takes over and either automatically moves your saber to block the attack (Dodge Block) or Evades out of the way. Dodge operates from a Dodge reserve that is seperated from the other stats (health, ammo, etc). The new Hud in the upper left part of the screen displays how many Dodge Points (DP) you have. Dodge has a maximum of 100 points and is refilled by draining energy from your Fatigue (Force) Points at a ratio of 6 DP to 1 FP. Dodge regens at a much faster rate than Fatigue (is controlled by g_dodgeRegenTime).

 

There are several different types of Dodge:

 

Dodge Block - If the player is using a light saber and not attacking, he will automatically attempt to block incoming light saber attacks. This is the first line of Dodge defense. This currently doesn't have an DP cost but it also doesn't have the parry bonus of a manual block.

Dodge - The player physically evades an attack. This currently only works for saber attacks. Cost is dependant on method of attack.

Sabers = 30 DP.

Dodge Roll - When normal Dodge fails, like say when a very solid saber swing continues to hit the player, the player will launch into a Dodge Roll

 

Situations where Dodge doesn't work:

Choking

Knocked to the ground

In mid air

 

It's very important to remember these situations as sabers are VERY lethal without Dodge.

 

Dodge Cvars:

 

g_debugdodge 0 = debug cvar for Dodge. Set to 1 to receive messages whenever Dodge is used.

g_dodgeRegenTime 555 = Controls the rate at which Dodge regens. The value is in msecs between regens.

 

 

 

 

Base JKA Saber System Terms:

 

Knockaway - You (defender) just blasted an attacker into a Broken parry. The animation start points seem to be from the parry positions. (BOTH_K animations)

 

Broken Parry - Your saber just got blased pretty hard. (BOTH_V animations)

=============================

[Vruki Salet]

I was hoping you'd go into detail about super duper interpolation and RealTrace, and the dodging system also. To start! Haha. I'm so tempted by a lot of your changes. I wannem! But what I have in mind for a saber system is quite different. I see auto-dodge evasion as taking quite a bit of control away from the player and I want to give more. (I think one reason I have trouble playing your system is I'm having a hard time telling how many dodge/blocking/fatigue/whatever points I have and why I keep getting thrown the awful "you've got no points left" alarm sound. I'd like more feedback on my status before the alarm.)

 

BTW what is "viewlocking" and how do you use it? I had an idea that I might call view locking and I wonder if it's the same.

[razorace]

Well, simply put, the super duper interpolation and RealTrace code was designed to specifically eliminate some of the design issues with the basejka system.

 

==========

RealTraces

==========

 

The RealTracing code is specifically set up to fix a lot of the conceptual issues with the basejka hit detection. RealTraces can handle situations where a ghoul2 trace or a saber blade trace misses after the initial bounding box trace. This is a major issue in the original system as since basejka just counts this as if the saber didn't hit ANYTHING. This is a serious problem becuase the saber bounding box is normally inbetween the hit victim and the attacking saber. IE, a lot of actual hit situations in basejka are treated as missies when they are clearly hits.

 

==========================

Super Duper Interplotation

==========================

 

The super duper interplotation mode is set up to try to fix a lot of the problems related with having a slow frame rate for the server world processing which limits the game's ability to do hit detection for sabers. The basic concept of this system is to maximize the hit detection by firing a bunch of RealTraces between from points on the last server frame's saber position to points on the current saber blade's position. Super Duper Interplotation fires a traces in a pattern that covers every single space on the saber blade. This system isn't perfect as the traces are linear. IE, this system can't account for the slight curving of the saber path.

 

So far, this experiment in improving the hit detection has been a success, if not a perfect one. For example, blade-on-blade impact detection appears to be perfect or near perfect and the general hit detection has improved noticably. On the other hand, there's still some issues with hit detection @ the end of the blade during the faster saber moves. However, due to the inharent issues with the JKA saber system (the server FPS limitation,the curving movement of the blades, and the fact that game engine doesn't have true object-on-object physics) I'm not sure there's much more that we can do.

 

============

View Locking

============

 

View Locking is a fancy concept that I came up with to give the saber impacts some level of "feel" to them to make up for the fact that there's no true object impacts in the JKA engine. All View Locking does is prevent a player from moving their view into the direction of a saber impact whenever the saber hits something. The View locking is based on the surface normal of the object that was hit so the player is able move in directions away from the impact but not directly into it. This system should in theory also prevent the sabers from passing thru objects without reason after impacts. Unfortunately, I've only had limited success with this so far, It works fine for wall impacts but it doesn't seem to work well on saber-on-saber or saber-on-players yet.

[razorace]

As for Dodge, there's a level of "control" that we have to take away from players since players want saber combat at "normal" speed, but they also want to BE Jedi. However, we all know that players aren't REALLY Jedi and therefore don't have Jedi reflexes. As such, I created Dodge as a way for players to HAVE Jedi Reflexes.

 

In the earlier days, I thought that players would be able to do the saber blocking manually (like in MB2) but I discovered that that simply doesn't result in realistic Jedi Combat. The saber attacks are just too fast for players to be able to manually block enough of them to make the game work. As such, I moved blocking into Dodge system but still give players the ability to actively block thru their movement. Plus, this opened up a button for kicking which players wanted.