Allow PCSX-Redux users to dynamically and manually add new and remove existing GUI windows, tabs, menus and controls to easily and quickly execute common scripts

[ghost]

For example I would like to be able to add a "Condition" and "Action" TextBoxes to the "Breakpoints" window/tab and a "Add Conditional Breakpoint" button that allows me to add a breakpoint that is triggered on some condition and does some action when triggered.

Another example is the ability to add a "Assemble" and "Enable/Disable Breakpoint" commands to the context menu of the Assembly window/tab.

The new controls can be programmed in Lua script and use the Lua API.

This can be very useful because all these features that are missing from the GUI can already be done with the Lua API.

I highly recommend you to give a high priority to this feature request because this feature request is very useful and if implemented everyone else don't have to wait for you to add new windows, tabs, menus and controls to the GUI because temporarily they will be able to do this by themselves both dynamically and manually.

Until this feature is implemented PCSX-Redux users will have to use the Lua API with both the "Lua Console" and "Lua Editor" windows to do anything that can't be done with the GUI controls to do what they want to do like adding conditional breakpoints for example.

If PCSX-Redux is open source then this is always possible to change the source code to add new GUI controls and build it but since Lua API and scripting already exist and supported by PCSX-Redux I would like to have a quick way to do this because Microsoft Visual Studio is very slow, large and consumes a lot of disk space and compiling and building can sometimes fails with errors and can be very annoying in general requires to download and install a lot of thing in your device.

The source code of PCSX-Redux should be used only when what you want to do can't be done with a Lua script because the Lua API doesn't have a function that does what you want to do or you either want or need to use a different language that is not Lua which can be automatically optimized by modern C and C++ compilers with the -O3 option or for some reason and you may want to use the source code of PCSX-Redux to extend the Lua API and add new functions to it for example after the user began a new feature request to add this function to the Lua API to be used with Lua scripts or a pull request and optionally add a new GUI control that uses this new Lua API function.

[wheremyfoodat]

ImGui and OpenGL are almost fully accessible through Lua scripts, so you can spawn your own GUI windows with buttons and actions very easily. I don't think there's any way to edit an existing widget like the assembly window within a Lua script, unless @nicolasnoble has some idea.

Btw is your name a Naruto reference?

[ghost]

ImGui and OpenGL are almost fully accessible through Lua scripts, so you can spawn your own GUI windows with buttons and actions very easily. I don't think there's any way to edit an existing widget like the assembly window within a Lua script, unless @nicolasnoble has some idea.

I didn't know about this! I am imprest! Looks like that I need to do more research before posting here! You are so good if this is already possible!

All my ideas are always based on what I don't see in the GUI but I didn't know that they are already possible with Lua! This is so awesome!

If that so then all my requests are to add these features to the GUI then so I can see them in the GUI on a future build and release of PCSX-Redux and meanwhile I will use Lua for all these.

Btw is the "Check for Updates" feature can also be already done with Lua too?

Btw is your name a Narutu reference?

No, in the time that I was registered to GitHub I watched the Buruto movie with my adult brother and I liked the Buruto character which is the son of Naruto. I liked both the movie and the character so much that this caused me to create a new GitHub account with that name.

[wheremyfoodat]

If you'd like an example of creating custom GUI elements for game hacking, see here

https://youtu.be/vy98V4HlIS0

As you can see, this allows not only defining new windows and widgets to do things, but even binding in-game variables to the GUI if you know their addresses. Can't find example code rn cause I'm in uni.

[wheremyfoodat]

Btw is the "Check for Updates" feature can also be already done with Lua too?

Mmmm not very easily but it should be fairly easy to implement in Redux itself. There's also an auto updater that you can turn on. It will tell you if there's an update available when booting.

[ghost]

Btw is the "Check for Updates" feature can also be already done with Lua too?

Mmmm not very easily but it should be fairly easy to implement in Redux itself. There's also an auto updater that you can turn on. It will tell you if there's an update available when booting.

And how to turn on this auto updater?
Also is this possible to freeze/unfreeze any memory address with Lua?

[wheremyfoodat]

System configuration menu -> "Enable Auto Update". Not sure what you mean by freeze/unfreeze. As in, set to a constant value?

[ghost]

System configuration menu -> "Enable Auto Update".

It appears that the "Enable Auto Update" checkbox is already ticked so there is nothing that I need to do about this.

Not sure what you mean by freeze/unfreeze. As in, set to a constant value?

There are two possible implementations for the freeze feature:

One way is to constantly and repeatedly write some given constant value at a frozen address exactly like what Cheat Engine, DuckStation and Bizhawk already do which can work with both recompiler and interpreter.

Another way, which probably will work only with interpreter until breakpoints will work with recompiler one day, is just to ignore and not execute at all or temporarily treat as nop all the sb, sh and sw instructions that will write to a frozen address and thus prevent the values of frozen addresses from changing.

Third way, which also probably will work only with interpreter until breakpoints will work with recompiler one day, is just to remember the value of the memory address when it became frozen and set the operand register to this value every time the frozen address is read by a lb, lbu, lh, lhu or lw instruction or temporarily treat both lbu and lhu instructions like a li (ori $OutReg, $r0, 0xMemory value just before freeze), lb and lh instructions like a li (addi, addiu, subi or subiu $OutReg, $r0, 0xMemory value just before freeze), which the Assembly of PCSX-Redux shows as a move instruction whose source operand is an immediate number, and lw instruction like lui $OutReg, 0xMemory upper half just before freeze and ori $OutReg, 0xMemory lower half just before freeze.

I personally most both like and prefer the idea to just ignore and not execute or just temporarily treat as nop any write instruction (sb, sh and sw) that will change the value of a frozen address. For me this is the best way to implement this feature even if the interpreter is necessary for this in order to work because PS1 games and roms run fast enough with interpreter on modern computers, devices and processors anyway.

The way that both Cheat Engine, DuckStation and BizHawk implement this feature may unnecessarily create burden on the CPU and make the CPU more busy and cause other applications to take more time to respond to their user especially if the user of this feature freezed a lot of different memory addresses.

Unfreeze simply undoes freeze and removes the frozen flag so the value of the memory address can be changed again by sb, sh and sw instructions again or the operand register of lb, lbu, lh, lhu and lw instructions is again set to the current value of the referenced memory which is the initial state of all memory addresses by default when booting any game or rom.

Is this clear enough?

I have both edited and updated my freeze/unfreeze feature request in https://github.com/grumpycoders/pcsx-redux/discussions/1062

I highly recommend you to read it again.