Messages

Hey, just wanted to provide some technical info and usage tips for these codes.  First off for independent subroutines, the currently available specials (last byte of the basic) are set to the max available specials whenever the fighter becomes grounded (grabs a ledge or physically makes contact with the ground and are decremented each time the corresponding special is used.  When a given group of bits becomes 0 and it has a max number of specials set that special cannot be activated.  This has a couple of important things to note: 1) if you have a special that changes to itself (specifically to the first 11X action) for some reason it will consume multiple uses of the special and potentially fail to work properly, 2) if the user becomes grounded during the special they will recover all uses (many DO NOT become grounded even when they touch the ground), and 3) if the user uses the special and remains grounded for the entire move the special's uses will be consumed and will not refresh until the user jumps or lands.  The specials also do not refresh on taking damage, as this is not always intended behavior and refreshing on taking damage is fairly easy to implement.  Create a subroutine setting LA-Basic[71] to the value of your choice and copy past that subroutine call to wait1, squat, swim, and if you want refresh on damage all of the damage and captureDamage subactions.

For the independent subroutines code threads 5-8 are generally safe to use (I think, 7 and 8 are safe on every fighter as far as I can tell).  Thread 0 is the action thread, threads 1-4 are the subaction threads (main, gfx, sfx, and other tabs in PSA), thread 9 is the default concurrent infinite loop thread, thread A is the default independent subroutine thread.  Articles and other non-fighter entities that run PSA commands do not necessarily have the same number of threads as fighters, and may not have any free threads.  Also, the specific thread number does matter for some commands, flash overlay effects for instance behave differently when called from thread A.  In terms of how to use independent subroutines, there are a couple of very nice general purpose uses.  The first is for generating flashing effects for fully charged moves.  The way that you'd implement one of these is something like:

if flashing condition
if thread is null: A
independent subroutine: (Thread A):  @flashing subroutine
end if
end if

With the flashing subroutine of the form (this is actually how flashing effects are implemented in Brawl)

Flash Overlay Effect:  Color 1
Sync Wait: 1 frame
Change Flash Overlay Color: Transition Time=4 Color 2
Sync Wait: 4 frames
Terminate Flash Effect
Synch Wait: 1 frame
goto: @flashing subroutine

The second general purpose method for independent subroutines is in conjunction with limited specials to create cooldowns for specials.  This is implemented using two different threads, one of which runs once per character frame and one which runs once per actual frame.  So if you wanted to give neutral special a 3 second cooldown starting from when it's activated you could put the following code in neutral special:

Float variable set: LA-Float[255] = 180

Then in an independent subroutine in thread 8 you can run this code:
if compare: LA-Float[255] > 0
Float variable subtract: LA-Float[255] - 1
End if
Sync wait: 1 frame
Goto start

And in thread 7 run this code:

If compare: LA-Float[255] > 0
Basic variable set: LA-Basic[71] = 27180100
else
Basic variable set: LA-Basic[71] = 0
end if
sync wait: .1 frames
goto start

This code turns on limited specials and sets neutral special to be limited and have no remaining uses whenever LA-Float[255] is non-zero.  Because of how action changes are checked this very easily prevents neutral special from ever being activated when you don't want it to be.

The final comment I'd like to make is to mention that attribute modification makes no attempts to limit the user to sane inputs.  If you run Attribute Range Set: IC-Basic[10,000,000] = 0 the code will gladly attempt to 0 out the 5 kilobytes of memory you told it to zero out, probably crashing your game.  At the same time, if you happen to know where some relevant piece of information occurs relative to the fighter's attribute table you may be able to use attribute modification to write to that value.  Also, I suspect that the way attribute modification is written may remove certain safeguards on bad PSA commands, specifically 12 type commands with a subtype of 14-1F (commands which do not exist) may attempt to branch into random memory crashing the game.  This is very easily avoidable though, since you shouldn't be using non-existent commands in the first place.

I've been getting crashes when starting a game with a brawlex clone selected via the css after previous games using the base fighter selected via the css without having selected or played against the brawlex clone getting (iirc) something like a file not found error for gfx.  I don't have a lot of brawlex fighters and the crash is annoying, could I just force the character select routine that loads data into memory for each of the clones upon entering a css?

The charging is probably done via asm, although that's probably something that's worth checking.

Double post, but this doesn't fit with my previous post and is probably interesting enough to share:
Each fighter has 11 AnimCmd threads (projectiles can have less, which is why I believe concurrent infinite loops have such a range of thread types; articles don't always have the thread 9 that fighters use), with various types that are used for various things.  Threads are held in a fixed size array with the threads stored in a structure of [ soAnimCmdInterpreter thread, soAnimCmdAddressPackArraySeparate something, word threadID, halfword threadType ].  Thread id is directly referenced by at least some commands (flash overlays in probably behave slightly differently for thread A), but thread type affects how each thread processes stuff; it makes intangibility and charged move flashing not terminate on (sub)action change and ignore frame speed modifiers (type 0x10) or makes commands be run every frame instead of terminating when the action is finshed (type 0x4), and changing the thread type does cause them to gain the new thread type properties.  Some threads can be directly interacted with by psa commands (type 0x4 threads for instance), but I don't think all of them can.  In any case here's some info about how the threads generally look for fighters:
Thread ID - Thread Type (hex) - What thread is used for

Sorry but you are not allowed to view spoiler contents.

Also, I found where 00 and 01 commands are run.  00 commands are handled starting at 0x801398c8 in memory (so somewhere in main.dol, I think) and 01 commands are handled starting from 0x706F8 in section 1 of sora_melee.  Oh, and if anyone wants to dig through PSA code soAnimCmdImpl's methods, which are used for accessing info about the current command, are almost all fully documented on the OpenSA wiki (only missing method [0][10]).

Ultra-basic tutorial for how to work in hex:
Open windows calculator
Switch to programmer mode (alt+3)
Then,

To convert hex into decimal:
Go to hexidecimal mode
Enter your hexidecimal number
Switch to decimal mode

To convert decimal into hex:
Go to decimal mode
Enter your decimal number
Switch to hexidecimal mode


Actual mathematical explanation for hex:
In the decimal system (aka normal numbers) we write numbers as a combination of 0-9 in an order that represents how many powers of 10 those numbers should be multiplied by.  So when you write 123 in decimal what you're actually expressing is 1*A^2+2*A^1+3*A^0 (where A here is a symbol representing what you'd normally call the number 10).  Hexidecimal is very much like decimal, except instead of using 0-9 and powers of 10 you use 0-F (with A representing 10, B representing 11, etc, F representing 15).  So if we were to write 123 in hexidecimal it would be 1*G^2+2*G^1+3*G^0 (with G representing what's normally called 16), or in decimal notation 1*16^2+2*16^1+3*16^0 = 1*256+2*16+3*1 = 291.  Hexidecimal is used a lot in programming because two base 16 numbers fully represent a byte and 16 is close enough to 10 to neither require an absurd amount of space to write nor require an absurd number of extra symbols.

So I was able to change g&w's projectile count using PW's info, but unfortunately the game crashes trying to generate the 9th onscreen projectile.  It doesn't seem to be due to issues with where the projectile is being loaded/instantized (as the game doesn't crash when any projectile other than the 9th is instantized into any of the constructed objects); I'm assuming it's a memory issue, although it seems kind of odd that that little extra loaded stuff could cause a crash.  I'll go ahead and post a g&w with 8 chef projectiles once I resize the cap and clean stuff up.  Also thanks for the awesome info PW!

Edit:  Yeah, it does seem like there's some crazy stuff going on behind the scenes that's causing stuff to behave oddly.  No idea how, but the 15 count had weird t-poses at the beginning of up-b (in addition to aforementioned crashing) and the 8 count somehow shaved off 90% of the la-float space that g&w had allocated (although maybe that just happens because la-floats end up writing into unused memory sections under normal circumstances and the change in object structure causes that memory to become unusable).  In any case though, definitely possible to implement this on other fighters.

Also, download link for anyone who's interested: https://www.dropbox.com/s/2yv6tgkst3mhp5e/ft_gamewatch.rel?dl=0

Thank you very much for the info PW!  I'm gonna see if I can implement this on G&W.

Using a wifi code and assuming you're not using anything that inherently causes desyncs (eg codes that read raw controller input during the game) then you should be able to play online.

Hey PW, I've been looking over your Lucario 8 aura sphere module since I'm trying to up G&W's sausage count to 15 instead of 5.  You replaced a couple of (what I assume to be) target offsets in the main fighter constructor and destructor functions with some new offsets as well as modified the fixed offset accessor functions with a proper function that looks up the address via some well thought out multiplication and addition.  I'm not quite that clever/knowledgeable about module layouts though, and I was wondering if you'd be willing to go through the basic process you had for figuring out the numbers to use for replacing the constructor/destructor offsets as well as the multiplication/addition constants for accessing the new articles?