- 853
- Posts
- 3
- Years
- Seen Nov 9, 2023
I've worked with scripts for a short time, but before I got started I always assumed that the way it worked was, you could preview your scripts in a sandbox type environment, before you applied them to your rom, actually making any changes.
That way you would see the effect before you broke anything, kind of like how in github you can test/debug before actually committing code.
So here's my idea. and sandbox type environment that will allow you to visually play out your script.
Would require map integration.
As well as a new tab that would define player state, which should allow you to check boxes that change flags as needed to give player that state.
ex. give player pokemon field in menu, another section for checking gym badges, setting them as elite four champion, check to allow fly to all locations. etc.
This player value editor would also need to allow you to edit your party pokemon. I'm guessing buffer pokemon may be the best way to do this, to create and give a pokemon of a selected species , lvl, and then define its moveset.
(For travel and for testing types and move effects and battle things)
Defining/Editing the player values is the first thing the user should do before attempting to play any script, to make sure they meet the minimum requirements to access it. But the defualt should be a new player, with the base menu. Maybe have it set to choose player gender in the menu so it knows which sprite to use. Ok add fields for player name, and gender.
You would navigate to the map you want to add scripts to, ( like in advance map) (assume advance map interface for my descriptions)
you click on the event you want to edit to select it. Next you select open script so you can read it in xse.
But here's where its different you have an option to "play" your script.
(The directory of the rom you load into the program to open the maps, and the one the program plays the script from should be 2 different places.
So you have a edit rom, but all changes would be applied and saved only to the test rom, until you're satisfied with your changes and click save as and commit the changes to your main edit rom.) So the program needs to have a option to define default save location, you would set that to the directory of your test rom, that way no saves would ever overwrite the rom you're loading from.(the one you actually use)
[ create backup (.bak) button that would make a copy of the test rom in the same location, for easy startover if bugsj are introduced to the test rom]
setting this to a button and not key press would allow for making backups while play testing your script. Like when you solve one thing before moving to the next.
the map edit window would load the game, skip any intros, check the program to see what map you're viewing and tell the game to load the player to that map.
On the map edit page below the place that shows the position of the events, we should have a box for player position its empty by default but before we press play script we should put values in this box to define where the player will appear.
(maybe create a pop-up dialogue that prevents user from selecting play script if the program doesn't have a value for the player position, and tell them define player position)
There should also be a check box, that would automatically set the player position equal to that of the selected script.
Near this space we should also have a Movement type option box for the player, (obviously it wouldn't be as expansive as the npc one because several of the behavior options are base on player action, so are useless here. The player should also be able to execute very basic actions based on the type of script we are playing.
This would mostly be to deal with different types of events, only warp and script events could be tested by setting the player right on them.
So for these events no special player behavior is required, but for a person event we'd need them, to be able to press A or to activate it and move through text....
>Ok thinking further maybe it would just be better to just associate your emulator and be able to play the rom from the emulator with full control from the window of the program. ( So you'd have the map open, hit play script and the window would be replaced by the game ran from your emulator, including all your emulator mapped controls. All keyboard controls would work as if just playing from your emulator until you pressed the "stop scipt button" which would send you back to the map view.
Check the pictures attached for an idea of what I'm trying to say, first would be how it could like playing, then back to map view after.
So summary On play script it should start a new game from chosen emulator, input the player values and skip all intros, then load the player onto the pre-selected map in the position defined beforehand from the program menu. Limit emulator dimmensions and position to that of the map view window, then hand over keyboard control to the emulator so you can move as normal. Users should make sure they have a "reset rom" hotkey assigned so they can quickly test things they change, without having to stop script and then play script again.
If they have a reset button setup they can change script, compile to the rom reset and then test those changes quickly.
Also when they're done and want to move to a new map to edit, as long as they have set player position equal to script position checked
you can select from the headers on the left, click to change maps, (and the program would automatically select a script on that page (as advance map does), so even if the player/user can't see it the program has loaded the new map location and player location, so by pressing the hotkey for reset rom they assigned to their emulator they can quickly reload and change positions without having to move to press stop script | start script.
This should make for a very nice streamlined workflow. Allowing for quick and efficient bug fixes/testing with next to no danger of corrupting or damaging your main rom file.
Required knowledge for build:
Now to actual make this I believe you'd need pretty adept code experience, knowledge of advance map or other map editor source code, intimate knowledge of flags/vars associated with rom-specific progression for player state values. If you really want to go the extra mile, you can make it work for multiple roms by setting a rom base toggle in the player tab, that would repoint/point to the correct flag/var you're trying to setup.
ex. A person wants to set their player to have the pokemon field in their menu and running shoes available. These require setting specific flags that are different in each game, so creating a toggle based on the rom base selected in the player tab would let the program know to look for a different flag name etc. to accomplish the same affect when the box is checked for pokemon menu and running shoes.
Required Knowledge cont.
Access to and knowledge about emulator-specific source code and I guess embedding, (I think that's what you would be doing embedding the program and make it usable within another)
You would probably need to include different instructions for whatever emulator you want to port to work with the program.
Or just do the simple thing and just use one, mgba would be my recommendation, either-way transferring saves between emulators is easy enough for the most part.
Ok that's the limit of the advice I can give on how to implement these ideas, I can't say what program language to use because I honestly don't know what's best, if you're taking up this task I'd assume you already have experience building programs before this, I completely understand that this is a big project, so I wouldn't really recommend a novice try this, but anyone is welcome to try, any progress on this would only benefit the whole binary community.
To any that wants to try making this, THANK-YOU and Good luck.
That way you would see the effect before you broke anything, kind of like how in github you can test/debug before actually committing code.
So here's my idea. and sandbox type environment that will allow you to visually play out your script.
Would require map integration.
As well as a new tab that would define player state, which should allow you to check boxes that change flags as needed to give player that state.
ex. give player pokemon field in menu, another section for checking gym badges, setting them as elite four champion, check to allow fly to all locations. etc.
This player value editor would also need to allow you to edit your party pokemon. I'm guessing buffer pokemon may be the best way to do this, to create and give a pokemon of a selected species , lvl, and then define its moveset.
(For travel and for testing types and move effects and battle things)
Defining/Editing the player values is the first thing the user should do before attempting to play any script, to make sure they meet the minimum requirements to access it. But the defualt should be a new player, with the base menu. Maybe have it set to choose player gender in the menu so it knows which sprite to use. Ok add fields for player name, and gender.
You would navigate to the map you want to add scripts to, ( like in advance map) (assume advance map interface for my descriptions)
you click on the event you want to edit to select it. Next you select open script so you can read it in xse.
But here's where its different you have an option to "play" your script.
(The directory of the rom you load into the program to open the maps, and the one the program plays the script from should be 2 different places.
So you have a edit rom, but all changes would be applied and saved only to the test rom, until you're satisfied with your changes and click save as and commit the changes to your main edit rom.) So the program needs to have a option to define default save location, you would set that to the directory of your test rom, that way no saves would ever overwrite the rom you're loading from.(the one you actually use)
[ create backup (.bak) button that would make a copy of the test rom in the same location, for easy startover if bugsj are introduced to the test rom]
setting this to a button and not key press would allow for making backups while play testing your script. Like when you solve one thing before moving to the next.
the map edit window would load the game, skip any intros, check the program to see what map you're viewing and tell the game to load the player to that map.
On the map edit page below the place that shows the position of the events, we should have a box for player position its empty by default but before we press play script we should put values in this box to define where the player will appear.
(maybe create a pop-up dialogue that prevents user from selecting play script if the program doesn't have a value for the player position, and tell them define player position)
There should also be a check box, that would automatically set the player position equal to that of the selected script.
Near this space we should also have a Movement type option box for the player, (obviously it wouldn't be as expansive as the npc one because several of the behavior options are base on player action, so are useless here. The player should also be able to execute very basic actions based on the type of script we are playing.
This would mostly be to deal with different types of events, only warp and script events could be tested by setting the player right on them.
So for these events no special player behavior is required, but for a person event we'd need them, to be able to press A or to activate it and move through text....
>Ok thinking further maybe it would just be better to just associate your emulator and be able to play the rom from the emulator with full control from the window of the program. ( So you'd have the map open, hit play script and the window would be replaced by the game ran from your emulator, including all your emulator mapped controls. All keyboard controls would work as if just playing from your emulator until you pressed the "stop scipt button" which would send you back to the map view.
Check the pictures attached for an idea of what I'm trying to say, first would be how it could like playing, then back to map view after.
So summary On play script it should start a new game from chosen emulator, input the player values and skip all intros, then load the player onto the pre-selected map in the position defined beforehand from the program menu. Limit emulator dimmensions and position to that of the map view window, then hand over keyboard control to the emulator so you can move as normal. Users should make sure they have a "reset rom" hotkey assigned so they can quickly test things they change, without having to stop script and then play script again.
If they have a reset button setup they can change script, compile to the rom reset and then test those changes quickly.
Also when they're done and want to move to a new map to edit, as long as they have set player position equal to script position checked
you can select from the headers on the left, click to change maps, (and the program would automatically select a script on that page (as advance map does), so even if the player/user can't see it the program has loaded the new map location and player location, so by pressing the hotkey for reset rom they assigned to their emulator they can quickly reload and change positions without having to move to press stop script | start script.
This should make for a very nice streamlined workflow. Allowing for quick and efficient bug fixes/testing with next to no danger of corrupting or damaging your main rom file.
Required knowledge for build:
Now to actual make this I believe you'd need pretty adept code experience, knowledge of advance map or other map editor source code, intimate knowledge of flags/vars associated with rom-specific progression for player state values. If you really want to go the extra mile, you can make it work for multiple roms by setting a rom base toggle in the player tab, that would repoint/point to the correct flag/var you're trying to setup.
ex. A person wants to set their player to have the pokemon field in their menu and running shoes available. These require setting specific flags that are different in each game, so creating a toggle based on the rom base selected in the player tab would let the program know to look for a different flag name etc. to accomplish the same affect when the box is checked for pokemon menu and running shoes.
Required Knowledge cont.
Access to and knowledge about emulator-specific source code and I guess embedding, (I think that's what you would be doing embedding the program and make it usable within another)
You would probably need to include different instructions for whatever emulator you want to port to work with the program.
Or just do the simple thing and just use one, mgba would be my recommendation, either-way transferring saves between emulators is easy enough for the most part.
Ok that's the limit of the advice I can give on how to implement these ideas, I can't say what program language to use because I honestly don't know what's best, if you're taking up this task I'd assume you already have experience building programs before this, I completely understand that this is a big project, so I wouldn't really recommend a novice try this, but anyone is welcome to try, any progress on this would only benefit the whole binary community.
To any that wants to try making this, THANK-YOU and Good luck.
Last edited: