Sharing of cheat used in Raine

[Tux]

The link sends a request for authorization, oh well... ! But from the description it seems again impressive. I don't know where you find all this knowledge about these games but wow !

edit : ok now, I guess I'll have to merge all these cheats in the next version then, since you added them at the beginning of what there was, it shouldn't be a problem. Congrats again, I should spend more time on this game too one day !

edit again : the run part of the script is quite huge, using a debug build the profile % (f11 key) show misc jumping to about 23% cpu time when activating the console cheat ! It's 5-6% only when using an optimized build like what you have for the releases, but there might be some ways to optimize this...

Edited February 11, 2023 by Tux

[ffman1985]

Hello, Tux, thank you for interested in my cheat. I have updated the link, you can download the the file now.

Actually, I don’t have very good knowledge on hacking, all I did is just the trial-and-error works. I use an emulator with the ability to make change to the ram address in a window. I started doing this about 2-3 months before. At first, I just want to make a vs mode for the fighting game that can reselect character after match. To do this, the main concept is ‘how the ram address is changed when a action is taken?’. For example, in real bout fatal fury special, go to the character select screen, then initialize a cheat search (can be treated as an reference point), then select a character. There should be change in some ram address. After listing all the changed address, l test with these one by one, returning them to the original value, finally I find out that $100026 is relevant to this. After changing this address back to the 00, player can reselect character when returning to the character select screen.

 

After this small success, I even try to change the ram address that I don’t know what it is about (with some special value like 00 , ff, etc), that why I can find out some very strange function, like pause the game, return to the character screen or the test service screen. Of course, after gaining more experience (especially  for the same series), I am more abled to find out which part of the ram is more relevant and should test first.

 

P.S. My computer programming knowledge is very limited, all I do is just following what I see in the original script. (So, i only using the basic function like poke, peek, if, endif, etc.). So, the script written might not be optimistic. Therefore, I welcome everyone to make changes to my script.

P.S.2 Thank you Tux for considering merge all these cheats in the next version.

Edited February 11, 2023 by ffman1985

[Tux]

Well for now the optimization makes a difference only for the debug build, going from 20+% to about 13%, not bad, in the optimized build no real difference.

A lot of things would need to be rewritten to make a real difference, and for now it would be overkill, this thing works quite well.

For a very limited coding experience your latest script is state of the art, comments inside and identations !

Even Antiriad almost never idented his code in the old sources for raine 0.28 and before !

So great work, and it probably took you quite a lot of time !

[ffman1985]

I didn’t add any comment in my script at first. But after following the advice from you and mer-curious, I try to add some comment for the important part. And I find it very useful now as the script getting much longer.

I spend 5-6 hours a day in front of the computer and take about 5-7 day to finish a game cheat. Most of the time are used for testing the ram address and jot note in iPad to describe all useful and important ram address. I usually deal with 2-3 games at the same period of time, as it is alway discouraged when I can’t discover any new findings in one game. (In fact, I have about 3 game cheat waiting to be uploaded now, just need to make minor adjustments and add some comment first.)

Edited February 11, 2023 by ffman1985

[Tux]

Congratulations for your motivation, it's rather impressive !

[Tux]

I simply moved your cheats to the end of the file, because the main ones are generic, those you added are very specific, and inserted the lines

script " "
script "Forum cheats, see topic 'sharing of cheat used in Raine'"
script " "

just before so that it makes a title section when displaying the cheats in the dialog. I'll do that for the other games you handled later and put that in git.

[ffman1985]

There will be update for street fighter alpha 1 and real bout special soon. So, don’t add this 2 games now. I will try to finish the update as soon as possible (maybe tonight or tomorrow).

[Tux]

No rush... and I found a very particular crash here while testing something else, linux only, 32 bits only, and recent system updates only, it reminds me of the recent problems in windows with the cps2 driver. I committed a workaround in git, there doesn't seem to be a better fix for now.

edit : finally found the problem, it was rather tricky, sdl2 was using a SSE memcpy in this case, but starscream, the asm 68k emulator we use in 32 bits aligns the stack on 4 bytes boundaries, which seems reasonable, except that SSE requires 16 bytes boundaries for the stack ! Luckily there is a function attribute to ask for a stack realignment in this case, it saved the day. Still no rush though, I have other ideas but it will take some time.

Edited February 12, 2023 by Tux

[ffman1985]

Update for Real Bout Fatal Fury Special (rbffspec.zip):

https://drive.google.com/file/d/1naLV90TyNSbpSHrd_3__W1IjU8wdm7Ah/view?usp=share_link

(temporary link, will be deleted if the script is included in the new version of Raine.)

The new version combine the vs mode and practice mode script into one called Console Mode Plus.

-In the menu, highlight 'Game Start' and press left or right to select vs mode and practice mode.

-In vs mode, it can now return to character select screen smoothly without relying on savestate.

-In practice mode, press start button to change character. There is no "Here come a new challenger" message after the update.

Edited February 12, 2023 by ffman1985

[ffman1985]

Update for Street Fighter Alpha Phoenix Edition (sfad.zip):

https://drive.google.com/file/d/1FFksCbzAi1VUz_X1IP4dWu5AsRVeJf8O/view?usp=share_link

(temporary link, will be deleted if the script is included in the new version of Raine.)

 

There are several fixes:

-Prevent skipping the opening if the cheat is enabled at start up.

-In the menu, the text 'Akuma' or 'Gouki' is changed automatically according to region chosen.

-In akuma(gouki) mode, in case of akuma vs akuma, the cpu can have a different color from the player.

-In Dramatic Battle mode, the characters are automacally selected. This prevent player from choosing the alt. color and auto block which result in failing to enter the Dramatic Battle.

 

Besides the fixes, there are some new seperated cheats for Dramatic Battle (use together with the console mode). Considering that most people play the game alone for most time, I create the cheat called Single Dramatic Battle which allows to play singlely. There are 3 variations:

1. Play as Ryu and CPU as Ken

2. Play as Ken and CPU as Ryu

3. Control both Ryu & Ken instantaneously

All of these are actually quite challenging. For the first two, you may find the cpu partner is so weak and you may finally want to switching to the instantaneous mode. However, you may need some special practice first before winning the the battle. Please have a try on it.

P.S. These 3 cheats only support for controller 1 and you do not need the second controller for selection and continue.

 

Edited February 12, 2023 by ffman1985

[Tux]

After looking a little more at your scripts, some notes about optimizations :

when I added support for these scripts, I thought they would run only for 1 frame, and that's all.
But then mame introduced the "run:" part, where the scripts run as long as they are active, every frame. Yeah I had thought about that too for values which need to be poked every frame, like invulnerability, but simple stuff that's all, but sometimes it really became quite big.

And you beat them to the record of the big stuff which runs every frame ! But since you change the way the game works, you are forced to do it this way of course, it was just unexpected.
I chose this script system because it was easy to add, but in this kind of circumstances it's awfully inefficient, there is no compilation so all the lines in the script which are executed are interpreted all the time, and this every frame, so it means 60 times / second. At least we have crazily fast cpus now, so they can sustain the load, but here it's a lot of wasted cycles anyway...

So if you want to see the load of your script on the cpu, just switch to the profiler display (press f11 until you get some % displays on the upper right corner of the screen), the cheats appear in the misc section, it's always at 0% in normal operation...
Now some simple tricks you can use to lower the load : when changing the menu displayed on the screen, what is displayed stays, it doesn't have to be sent in every frame. So you can use a variable here like printed. Set it to 0 by default, then when you have displayed one entry set it to 1, so this entry won't be displayed again in the next frame. For xmcotar1d it produces something like this :

    if (dpeek(choice)==$0000)and((peek($FF4BAB)==$04)or(peek($FF$4BAD)==$04))
        dpoke choice $01FF
        printed=0
    endif
    if (dpeek(choice)==$0100)and((peek($FF4BAB)==$04)or(peek($FF$4BAD)==$04))
        dpoke choice $02FF
        printed=0
    endif
Oh yeah I also added
credits=$ff4bdd
choice=$ff2000
at the beginning of the script to be able to use variables here.
So this is the part where you navigate the menu and update the choice address with what you receive, for each update you set printed to 0. Then the display itself :
#Menu Text#
    if !printed
        poke $908E73 $14 #Text Color#
        poke $908EF3 $14
...
       if (peek(choice)==$00) #Arcade#
        poke $908E71 $20
        poke $908EF1 $41
        poke $908F71 $52
        poke $908FF1 $43
        poke $909071 $41
        poke $9090F1 $44
        poke $909171 $45
        poke $9091F1 $20
        printed=1
        endif
This way you set printed to 1 once Arcade has been displayed, so in the next frame it won't have to do it again.
The small drawback of this method is that if you exit this menu by an unexpected way like the f1 key to reset the game, next time you arrive to it, the computer will believe it's already displayed since printed will still be at 1. Well just press up or down key and the menu text appears again. It's a choice...
The if !printed finishes after the last entry has been displayed, so after Option here.

Anyway these are just some ideas, you can keep your script as it is if you prefer, I'll just have to find more complex ideas to work with this !
And if !printed means "if not printed", it's the way to write it in most languages like C, but you can do this in basic too... (except in basic it's "not " instead of ! alone).

Edited February 13, 2023 by Tux

[ffman1985]

Hello, Tux, thank you for spending your time on reading my script and providing the way to optimise it. There are many instructions that I want it only operate once and then stop. For example, the change in text color in the menu, and all instructions involving rom hack (like the switch of control and the change of ‘press start’ text in the opening), etc. Can I use the printed at different area in my script to do so?

Also, I have set the conditions requirement for different part of instructions. For example, for the cheat to enable bosses, I use the if…endif  statement to make it only operate in the character select screen. However, does that mean that it will not affect the run during the actual game (during the battle)?

Similarly, as you can see, the script for different modes (vs mode, training mode, etc) are divided into group under the if..endif statement. If I play in the vs mode, it surely not operate the instructions  inside the training mode part, but can it still affect?

In short, I want to know, if there are too much if..endif statement, and the instructions inside is very long, can they still affect the run even the condition is not fulfilled?

[Tux]

38 minutes ago, ffman1985 said:

Hello, Tux, thank you for spending your time on reading my script and providing the way to optimise it. There are many instructions that I want it only operate once and then stop. For example, the change in text color in the menu, and all instructions involving rom hack (like the switch of control and the change of ‘press start’ text in the opening), etc. Can I use the printed at different area in my script to do so?

Yes but careful if you use that on 2 scripts which can be activated at the same time : variables are global only for now so if they have the same name, they will collide.

38 minutes ago, ffman1985 said:

Also, I have set the conditions requirement for different part of instructions. For example, for the cheat to enable bosses, I use the if…endif  statement to make it only operate in the character select screen. However, does that mean that it will not affect the run during the actual game (during the battle)?

You have some useful instruction to check that : print_ingame. It works like this :
print_ingame number_of_frames text
so if you want to check if a part of a script remains active at a certain time, add something like

print_ingame 1 "message"

at the start of the section you want to check. If you see the message all the time, it means it's always active.
I am not sure I understood completely your question here, but this instruction should be useful anyway !

38 minutes ago, ffman1985 said:

Similarly, as you can see, the script for different modes (vs mode, training mode, etc) are divided into group under the if..endif statement. If I play in the vs mode, it surely not operate the instructions  inside the training mode part, but can it still affect?

In short, I want to know, if there are too much if..endif statement, and the instructions inside is very long, can they still affect the run even the condition is not fulfilled?

For now yes they do sadly. As I said the scripts are really not intended to be run this way and there is no optimization to jump a big section of an if whose condition is false, which means that it will still parse all the lines inside, but not execute them, so it will not take too much time, but it will still take some execution time.

I am thinking of a way to improve that, but for now that's how it works yeah.

By the way you can also use print_ingame to display variables, but it works like the printf command in C, so it's a little special : %d is replaced by the variable in integer form, while %c is replaced by the character whose ascii code is the value of the variable, %x is the value of the variable in hex, and so on. And contrary to what the internal help of the console says you can use this from the console, but in this case use a high number of frames to have the time to see the message, so you must do that with a loaded game, like this for example

a=3
print_ingame 120 "test a=%d" a

and you should see "test a=3" for 2 seconds (1 second is 60 frames) in the lower left corner of the screen when you close the console.
I hope it helps !

Edited February 13, 2023 by Tux

[ffman1985]

I have some more question on printed. As I understand, it is something that cannot use multiple time in the same time. So, can I self defined some variable to deal with this function? For example, I set something like these:

stopper1, stopper2, stopper3, etc

and i set them equal to 0 or 1 at the appropriate time.

[Tux]

11 minutes ago, ffman1985 said:

I have some more question on printed. As I understand, it is something that cannot use multiple time in the same time. So, can I self defined some variable to deal with this function? For example, I set something like these:

stopper1, stopper2, stopper3, etc

and i set them equal to 0 or 1 at the appropriate time.

yep as many variables as you like, no restriction, just once a variable is defined it stays there, any script can access it, even if you load another game it's still there, so just be careful that 2 scripts executed at the same time don't use 2 different variables with the same name, it wouldn't work.