Attn: Almas, Light shielding info

[shanus]

Will update this more as we go through, but:

Fighter.pac offsets for shield prereqs:
A2EC
(Just need to insert an additional change action when the variable we modify is set)

Code to set new variables to find in memory:

For Light-shielding, Use Air Dodge to set these values!	
07060C00 00000060	
00000000 00000046	
00000001 [COLOR="SandyBrown"]00123456[/COLOR]	
00000005 2000006F	
00000001 [COLOR="SeaGreen"]00567899[/COLOR]	
00000005 20000070	
00000002 80FB18FC	
00000002 81060C38	
00070100 80FB18E4	
04000100 81060C00	
12000200 81060C08	
12000200 81060C18	
00090100 81060C28	
06FB18F4 00000010	
00090100 81060C30	
00020000 00000000

Variables: RA-Basic[111 & 112]

RA-Basic 111 stored value
RA-Basic 112 stored value

For Air Dodge Floats, use air dodge
07060C00 00000060	
00000000 00000046	
00000001 [COLOR="DarkOrange"]00123456[/COLOR]	
00000005 [COLOR="Teal"]210001F4[/COLOR]	
00000001 [COLOR="DarkOrange"]00789978[/COLOR]	
00000005 [COLOR="teal"]210001F5[/COLOR]	
00000002 80FB18FC	
00000002 81060C38	
00070100 80FB18E4	
04000100 81060C00	
12060200 81060C08	
12060200 81060C18	
00090100 81060C28	
06FB18F4 00000010	
00090100 81060C30	
00020000 00000000

 

[Almas]

Okay, well, fluffles, here are my intentions:

There exist locations where the hardness of L/R presses is stored. However, they are volatile and unprocessed; it is very common for the value to jitter from 0-1-2-1-0, and if you press the button down hard, you can fetch different values each time. So it's an approximation, but not amazingly perfect. Still, it's enough.

Whenever one of L, R are pressed beyond a certain threshold (e.g. something very small to stop it from accidentally going off), one of the variables is set to some value. Then either using the magic of PSA or some simple coding, every frame the value is decremented. The code is essentially:

If variable > 0 then
variable = variable - 1
else if L>x or R>x
variable = 100

(This way, the variable is only set if it doesn't already have a value - pressing L while it's still counting down won't do anything)

Then, you set up your L-cancelling code to cause half lag if the variable is, say, >40 when they land. This allows a failure window. If I have to time in the variable decrement in ASM, there will likely be flaws in timing due to the varying duration of a processor cycle unless I take time to find a frame increment.

With the other variable, I intend to store in it (every processor cycle):

If Shield is pressed, Var=A
else Var=MAX(L, R)

So, if they're holding down shield i'll turn one value, and if they're partially holding it'll return another.

Then, you use a PSA code to make it so that you can only turn on your shield if Var>some X. Again, this value is chosen to stop arbitrarily light presses from accidentally triggering the shield.

We have old codes which change the global constants of shields from spunit. Using these, I can tap into the ASM behind shields (hopefully), and modify them based on the value of the variable set. There could be a few hurdles in this part, but I hope not (clearly there will be and I'll be sad and frustrated). Generally, the shield strength, decay and damage will be affected proportionally to the hardness they are pressed. Of course, some consideration will be needed as to the ratios, and I could use some clarification from someone who understands melee's shields here. A simple example:
Say the hardness of L/R presses can range from 0-200. We set a full shield to be 200 (so if the button is pressed it's set to 200 regardless of how hard the press is).

Shield strength (size) = 400/(200+press)

And similar ratios for others.

I hope this explains some. I won't be able to get this all done in one coding session - luckily I have some extra free time right now because two of my classes have held off on exercises, but this is diminished by it being valentines day and chinese new year, and my girlfriend is chinese. SUCKS TO BE ME I GUESS.

 

[shanus]

I hear ya, valentine's day and my girlfriend is chinese too. Busy weekend for both of us lol.

I suggest what we do is that instead of setting the value to some threshold like 40, simply after its gone a certain distance, we simply set a variable to true.

Also, I suggest we try and do L-canceling first since it'll be far easier to modify my code to test it quickly. If that registers, i can set up a second quick injection to register shields with light presses.

Maybe I'll write both of them this afternoon.

 

[Almas]

Well, can you do the decrementing function? Finding things that operate frame by frame is a hassle I'd rather avoid, and it may be trivial in PSA. If you want to do L-cancelling that way I'm indifferent - that'd just be my approach, but I don't know what would work best.

 

[shanus]

i can only decrement the value within the action that is called. I don't know any global run commands that are run *all* the time.

 

[Dantarion]

I have a ASM code that reads input data for all GC controllers and makes L or R register as a button press if they are held down over the value 0x10 (My controllers sometimes went neutral at 0x08, but almost never go back to 0x00)

Ill post it in a bit

 

[Almas]

Oh, sweet. It's important to consider that this should only work if people have L/R set to shield. But I'm sure that's just a complicated but mechanically easy fix.

 

[Dantarion]

The thing is, I don't know WHERE that data is stored.

 

[Almas]

Neither do I. That's why it's complicated ;p.