SP Coding help for saber powers?

[Dusty]

So, would anyone, with the know-how, be able to help me with a little SP code editing? I'm not trying to do anything too crazy... 

 

What I'd like to do:

1. Fix saber defense 0 so blaster bolts don't go through the player

2. Make saber offense and defense hierarchal

-this means that saber defense can only block saber offense of lesser and equal value.

-basic system: 

 

Defense 3 - disarms offense 1, parries/knocks away offense 2, can parry offense 3

Defense 2 - breaks from concentrated attack of offense 3, blocks offense 0/1/2

Defense 1 - breaks from concentrated attack of offense 2, blocks offense 1/0

 

 

That's basically what I want to do. From a coding perspective, is that extremely difficult, or not so?

[Scooper]

I can't give an accurate estimate without actually looking into it, but here's my thoughts:

 

1) Didn't know that they actually went through the player, but if that's the case it means it's missing some part of the collision system. This could be an easy fix if it's just about enabling it for the projectiles. Or it could be a big task if it's not there at all.

2) This is most likely going to be quite a bit of work. Might not be too hard, but you're talking about tweaking a major gameplay feature that has a lot of code involved. And you want it done with SP, so it has to be done through engine-hacks =p

 

It could probably be done, but I certainly don't have the time to invest to help you with this, sorry.

[Dusty]

I can't give an accurate estimate without actually looking into it, but here's my thoughts:

 

1) Didn't know that they actually went through the player, but if that's the case it means it's missing some part of the collision system. This could be an easy fix if it's just about enabling it for the projectiles. Or it could be a big task if it's not there at all.

2) This is most likely going to be quite a bit of work. Might not be too hard, but you're talking about tweaking a major gameplay feature that has a lot of code involved. And you want it done with SP, so it has to be done through engine-hacks =p

 

It could probably be done, but I certainly don't have the time to invest to help you with this, sorry.

 

For saber defense 0 anyway, the bolts hit you if you turn to the side sometimes, but 90 percent of the time they go through you. Its like how when you give a .sab file "blocking 0" and then shots just bounce off a wide area infront of you.

 

However for saber defense 0 when a shot hits the saber's blocking field (which is overly huge btw) it doesn't know what to do so it just passes through you. I wouldn't mind letting shots bounce off saber defense 0, but then cause you to stagger.

 

 

For the hierarchy system, it could be a bit of work. Basic overview as I see it:

 

Whenever a saber attack is blocked by X entity:

1. Check saber defense level of defender

2. Check saber offense level of attacker

3. Basic attacks = (Offense level of attacker)

4. Special attacks = (Offense level of attacker) + 1

5. Compare the values of the attackers offense to defender's defense

6. Set up a stagger counter. If "Stagger Counter" > 3 then Defense is broken

 

 

Here a hypothetical coding model I made. No, it's not real code, but it's sort of a "concept", kind lays out the idea. I kinda wrote it in "Scratch style".

 

 

If Defense < Offense --->

{

  If Defense < Offense -1:

    {

    Defender effect: Breaks (like getting hit by strong style), disarms.

    }

 

  If Defense = Offense -1:

    {

    Defender effect: Standard block, Change "Stagger Counter" by 1. Wait 1.5 second. Change "Stagger Counter" by -1.

}

 

 

If Defense = Offense --->

{

 If Defense Level = 3:

     If Strong style/staff hit:

       {

       Defender effect: Standard block. Do not interrupt attacker swing. Change "Stagger Counter" by 2. Wait 1.5. Change "Stagger Counter" by -2.

       }

     Else

       {

       Defender effect: Parry/knockaway.

       }

 

If Defense = 1 or 2:

     If- Strong style/staff hit:

       {

       Defender effect: Standard block. Do not interrupt attacker swing. Change "Stagger Counter" by 3. Wait 1.5. Change "Stagger    Counter" by -1.

       }

    Else-

       {

       Defender effect: Standard block

       }

}

 

 

If Defense > Offense --->

{

  If Not (Defense = 3)   

{

 If  Defense Level = Offense + 1:

     If Strong style/staff hit:

       {

       Defender effect: Standard block. Do not interrupt attacker swing. Change "Stagger Counter" by 3. Wait 1.5. Change "Stagger Counter" by -1.

       }

     Else

       {

       Defender effect: Parry/ knockaway.

       }

       

If Defense is > Offense + 1:

     If- Strong style/staff hit:

       {

       Defender effect: Standard block. Do not interrupt attacker swing. Change "Stagger Counter" by 1. Wait 1. Change "Stagger    Counter" by -1.

       }

    Else-

       {

       Defender effect: Knockaway and Disarm.

       }

}

 

 

[Scooper]

The problem is how many places the SP code needs to be changed for the new hierarchy to work. Might just be one, but there's no telling before actually checking it out (or if you're already very familiar with how these systems are implemented in SP).

The logic behind the system that needs to be coded isn't very complicated, and your pseudo code works fine to explain it. Implementing it might be a whole other story.

 

I've given you my initial thoughts on your plan, I don't intend to attempt this for you though. But maybe another coder will, and my input might be of use to them. I don't want to discourage anyone from attempting it, there is a good possibility that it will be straightforward to implement.

[Dusty]

No probs, I wasn't expecting you to attempt it for me anyway, but I appreciate your input! Anyways..., I can't imagine the code being too hard to implement. 

 

I mean, I don't imagine the current saber system being too complex.

There are few differences between the saber offense and defense levels. As it is, all levels of defense have the same blocking strength roughly, but the main difference is speed, block radius, and ability to parry/knockaway. (at least that I can tell from gameplay)

 

The main issues for this:   differentiating power/defense between saber styles, which I have an idea on how to account for, and then dealing with parry/breakparry bonuses. 

[Scooper]

Example of the stuff you have to read through to do the changes you want:

 

.text:200B9553                 mov     edx, [esp+2980h+var_2970]
.text:200B9557                 push    64h
.text:200B9559                 push    7
.text:200B955B                 push    edx
.text:200B955C                 push    ebp
.text:200B955D                 push    edi
.text:200B955E                 call    sub_20032790
.text:200B9563                 mov     eax, [edi+110h]
.text:200B9569                 mov     ebp, 1
.text:200B956E                 mov     [eax+1190h], bp
.text:200B9575                 mov     ecx, [edi+110h]
.text:200B957B                 mov     [ecx+118Ch], bp
.text:200B9582                 mov     edx, [edi+110h]
.text:200B9588                 xor     ebx, ebx
.text:200B958A                 mov     [edx+1194h], bx
.text:200B9591                 mov     eax, [edi+110h]
.text:200B9597                 mov     cl, [eax+274h]
.text:200B959D                 add     esp, 14h
.text:200B95A0                 test    cl, 4
.text:200B95A3                 jz      short loc_200B95C7
.text:200B95A5                 fild    [esp+2980h+var_296C]
.text:200B95A9                 mov     ecx, dword_201F4B54
.text:200B95AF                 sub     esp, 8
.text:200B95B2                 fmul    dword ptr [ecx+1Ch]
.text:200B95B5                 fstp    [esp+2988h+var_2988]
.text:200B95B8                 call    _floor
.text:200B95BD                 add     esp, 8
.text:200B95C0                 call    __ftol2
.text:200B95C5                 mov     esi, eax

You can get it a bit clearer than that if you have the right tools, but in the end you'll have to find exactly where in this where you gotta change stuff.

[Dusty]

I see you got assembly code there. I was thinking this could be done using something along the lines of Eez's tools or what not... Perhaps I'm underestimating the work this would involve even for a skilled coder?

[Scooper]

I wasn't aware that he had released his tools, I don't know how extensive they are but they might help. =p

But yes, my opinion is that you're underestimating the work involved.

[Dusty]

Okay, so posting on this again after a little bit. After reading through again, I couldn't help but notice you did say this Scooper:

 

 I don't want to discourage anyone from attempting it, there is a good possibility that it will be straightforward to implement.

 

I mean, assuming the worst, just how tedious would this be to implement (for someone familiar with this kinda stuff)? Like say you had to do everything, aka start with assembly code, do some reverse engineering, and the SP code has to be changed in 20 places... how tough would it be compared to standard MP code-making/editing?

 

Now assume some reverse-engineering is involved, but that the SP code in place for the part of the saber system is fairly simple as I've been able to observe... would that be almost easy as pie, or not quite?

 

 

 

How the Saber System works:  (prepare for a wall of text)

There is actually almost no randomness to it. Whether you can parry an attack depends on your saber defense first. You need saber defense 3 or parry bonuses on your saber if at a lower level before you have the ability to parry attacks at all. Then it depends on the saberstyle of the opponent attacking. Then it depends on whether their saber has break parry bonuses or is "twoHanded". And you always parry an attack that is parryable, unless you haven't finished the recovery animation from the previous parry/knockaway yet.

 

Base Medium and Fast style are always parried. Strong style always staggers upon any contact whatsoever, except if the defender has a parrybonus of 3 more than the attacker's breakparrybonus, then it can't stagger you, and can be blocked slightly. Base Staff and duals styles are probably always parried. Staff sabers are normally two handed though so they act like strong style. Then a breakparry/two handed bonus on any saber causes medium style, and staff and probably duals to be like strong style, but fast style can still be parried.

 

Sounds complicated, but it's not really. Saber offense and Defense play hardly any part. It really depends on saber styles and parry/breakparry bonuses.

[eezstreet]

You still need to know how assembly code works in order to use my "tools" (it's actually mostly just a proxy). They are not a substitute for an SDK, nor are they a magic wand. It's merely a proxy with a set of plugins that can be turned on/off. I had to eventually abandon it because plugin discovery wasn't working properly. Your best bet is to talk to Mr. Wonko, since he's the last known person that I know of that dealt with this.

 

As far as toughness goes..I'd say it's fairly tough. I'm only just doing some basic memory patches now to change damages and fiddle around with a few things (making repeater spread vary based on standing/crouched/moving, et al). Even just that gets a bit sensitive sometimes, and I often have to use 3-5 different programming tools at the same time in order to solve problems (IDA Pro + Hex Rays plugin = not free, but well worth the money if you know what you're doing; OllyDBG for debugging; Microsoft Visual C++ for the code compilation; the list goes on). When it comes to the code you've written, I wouldn't say it's exactly easy to do, perhaps not even on an MP level (from my standpoint anyway, simply because the only code involving sabers was my more or less from-scratch creation of JKG's saber system). That's subjective though.

 

Basically, if you have no idea how to program for the MP code, you're better off not trying to start SP until a SP SDK is being released, since code edits are honestly about 20x harder once you introduce the factor of reverse engineering into the mix. I recommend doing these kind of code edits on an MP testbed to see what exactly you need to inject, and then rewrite this in either an ASM naked function wrapper hook (which is probably the easiest way, as BobaFett tells me) or a naked function that contains only ASM. Either way, you're going to have to get your hands dirty.

 

Though I will admit, not all changes involve hooks. If you want to change one line of code, say:

 

200C2C8F                 mov     [esp+50h+damage], 2Dh   ; Damage for bowcaster = 0x2D = 45

 

You could patch this using some code similar to this:

 

// note: unlockmemory and lockmemory are pseudocode, I can't give out code to these functions directly
UnlockMemory( DLLA(jagamex86, 0xC2CBE), 1);                // most memory is read-only. If you don't set the memory as being writeable, you'll get a shutdown with a console box saying "writing to inaccessible memory"
*((unsigned char*)0xC2CBE) = 75; // let's up the base damage to 75 
LockMemory( DLLA(jagamex86, 0xC2CBE), 1);

 

DLLA is a nice little macro I invented that accounts for ASLR and prevents random crashes.

 

..wait, why am I going off on a tangent.

1:19AM, fock you need coffee

[Dusty]

Eh. Too much work for too little payoff I guess. Any whoo, thank you for the help Eez and Scooper, I appreciate your telling/explaining to me about all this stuff. Seems like whoever would help me with this would just end up pulling their hair out for something that might not even work too well...

 

I can fiddle without code editing... I've gotten this far anyway.

[Scooper]

 

You could patch this using some code similar to this:

 

// note: unlockmemory and lockmemory are pseudocode, I can't give out code to these functions directly
UnlockMemory( DLLA(jagamex86, 0xC2CBE), 1);                // most memory is read-only. If you don't set the memory as being writeable, you'll get a shutdown with a console box saying "writing to inaccessible memory"
*((unsigned char*)0xC2CBE) = 75; // let's up the base damage to 75 
LockMemory( DLLA(jagamex86, 0xC2CBE), 1);

You could also patch it like this:

 

PatchMyStuff();

PatchMyStuff is a function that patches all my stuff.

 

I'm just pointing out the futility of posting code with function/macros you don't give the definition of. I know you're giving the general idea, but come on :/

[eezstreet]

I suppose you're right @@Scooper. I do have those macros and functions in the proxy DLL thing that dusty is referring to, however

 

I want to write up a proper guide at some point for reverse engineering SP properly.

[Fighter]

I want to write up a proper guide at some point for reverse engineering SP properly.

Do it!

[Scooper]

I do have those macros and functions in the proxy DLL thing that dusty is referring to, however

Didn't consider that, didn't download it =p

[Dusty]

So I was looking through the code/game/wp_saber.cpp text file in the SP code. Very complex, long, and messy... don't know how you coders use any of that... but anyway...

 

I noticed some bits where for parries and attacks they had saber offense checks going, but they were commented out, interesting...

 

Also slightly after these lines I saw where they said that strong styles are counted as attacking even in a transition animation... don't know why they thought that was a good idea *facepalm*

 

 

 

//base parry breaks on animation (saber attack level), not FP_SABER_OFFENSE

if ( entPowerLevel < FORCE_LEVEL_3 

//&& ent->client->ps.forcePowerLevel[FP_SABER_OFFENSE] < FORCE_LEVEL_3//if you have high saber offense, you cannot have your attack knocked away, regardless of what style you're using?

//&& hitOwner->client->ps.saberAnimLevel != FORCE_LEVEL_5 

&& activeDefense

&& (hitOwnerPowerLevel > FORCE_LEVEL_2||(hitOwner->client->ps.forcePowerLevel[FP_SABER_DEFENSE]>FORCE_LEVEL_2&&Q_irand(0,hitOwner->client->ps.forcePowerLevel[FP_SABER_OFFENSE]))) )

{//knockaways can make fast-attacker go into a broken parry anim if the ent is using fast or med (but not Tavion)

 

 

 

Now if I just knew where they put force powers...

[katanamaru]

I was mostly certain that ALL styles did damage when in transitions.

I know I've killed many enemies with transition moves. That was the bases for my idea of doing Makashi with attacks in the transitions.

[Dusty]

^Problem is that means strong style obliterates your guard by just touching it, funny, but very silly.

[katanamaru]

Yeah the breaking of the gaurd is a little silly, but that will be useful for saber styles I'm pondering right now.

[Dusty]

So, I found force powers I think. You know, the coding is actually starting to make some sense to me... *gasp*  :blink:

 

Anywhoo, some of them are defined in wp_saber.h header file, so they're coding is prolly in the wp_saber.cpp file. Then they're referenced in other places as needed I'm thinking.

[katanamaru]

Man I can't wait to dl this tonight and start looking at it!

I always told myself that when JA SP code was available I'd make an honest attempt at learning it.

 

Keep posting little things you find related to sabers, force, and/or animations in general you may find please.

[Dusty]

Force sense levels of 2 or greater give perfect aim for weapons I think from looking in g_combat.cpp.

 

I just tried it in game. I got that perfect aim for alt-fire on the e-11 o_O.

[Fighter]

So, I found force powers I think. You know, the coding is actually starting to make some sense to me... *gasp*  :blink:

 

Anywhoo, some of them are defined in wp_saber.h header file, so they're coding is prolly in the wp_saber.cpp file. Then they're referenced in other places as needed I'm thinking.

All commands, including force powers, call functions at the bottom of g_cmds.cpp. You can use that function call to go directly to the definition of the power.

[Dusty]

You mean in Visual Studio? I've just been looking at file in Notepad. I'm about to snoop in visual studio though.

[Dusty]

Ahh, I open the vc++ project file for the /game folder I'm guessing?

 

EDIT: There is tons of force power coding in wp_saber.cpp. Kind of an odd place to put it though...

Most of the saber combat coding starts at around line 4464.