SB2R Developer Guides

SB2R Dev Team

Contents

1 Basics 3

1.1 Basic setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Regions Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 TortoiseSVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Commiting Content 5

2.1 Committing Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 RMXP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Recompiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Updating News . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Good Practices 7

3.1 Sourceforge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Locked Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Move And Rename . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Ignore lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Others 9

1
4.1 Event Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 DevHacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2
1 Basics

1.1 Basic setup

In order to use the editor, you need the following files:

• Game.rxproj
• Game.exe
• Game.ini
• SB2REditorLauncher

If you can’t see file extensions (.rxproj, .exe, etc.), enable them first.

Game.rxproj can be obtained by starting an empty project with your RPG

Maker XP. This will create a Game.rxproj file in the project directory. Copy
the project file Game.rxproj to SB2R Current Version directory.

Game.exe is simply a copy of SB2R.exe. Make the copy and rename it.
Game.ini is exactly like Game.exe. Make a copy of SB2R.ini and rename it
to Game.ini.

Finally, to create SB2REditorLauncher you need to go to the hooks/ direc-

tory in the developers repository and make a shortcut for the SB2REditorLauncher.exe
executable. Then, rename it exactly to SB2REditorLauncher and place it on
Current Version directory.

If you did all this right, none of these files should appear when you try to
commit anything, because they are already in the ignore files list.

To learn how to actually launch the editor, see regions editor section.

1.2 Regions Editor

The regions editor is a system required to overcome the 999 map limit for RPG
Maker XP and be able to work with it more or less comfortably. In order to start
the editor, you need to launch SB2REditorLauncher and select a region to
import.

Once you are working with it, you can use the test button inside the editor or
click directly on the game executable, and the system will detect you are editing
files and will do an export of the files you are working with so you can test the
changes.

3
 When you are done with changes, close the RPG Maker XP editor and launch
SB2REditorLauncher. Click on export. Commit the changes, done.

Now on to the important parts:

• If you use the editor, never commit or update without exporting first.

• If you have no developer ID, your work may be overridden by other develop-
ers. You must also always commit your revision????.info file. More
info on hooks section.

Also notice that if you test some changes and later want to revert them, you
must do so with the SVN revert option, not the editor launcher clear option.

Edit for dummies, example workflow by Space:

1. Open SB2REditorLauncher

2. Select the region you want to edit

3. Edit as usual, test as usual, save as usual

4. Close RPG Maker, reopen SB2REditorLauncher and Export from there

5. NOW you can commit or update. DO NOT commit or update before com-
pleting these steps or your work is likely to go bye bye

1.3 TortoiseSVN

Make sure to have TortoiseSVN updated.

When you modify game files, you need to commit them. This means upload-
ing your changes (in your computer, local changes) to the main repository, on
Sourceforge servers.

This has some problems since multiple users modifying the same files can cause
conflicts, but it allows us to work collaboratively on different parts of the game at
the same time. If you are working on shared parts with other developers, make
sure to talk with them to avoid conflicts.

4
2 Commiting Content

2.1 Committing Basics

Committing is usually quite easy. When you (or the editor) modify a file, you will
see an icon ! on the file, which means that the file has been modified.

TortoiseSVN automatically tracks these files. When you have modified files,
your repository is not in a clean state. This means that your local repository is
different from the server copy (as far as you know).

So when you finish your changes, you must select the commit option from the
right-click contextual menu.

In the commit menu you need to make sure you are going to commit the right
files. Write an explanatory commit message briefly explaining your changes, and
click on commit.

If you want to commit all changes, select commit from the root folder. If you
commit from a sub-folder, only the changes of that sub-folder will be committed.

Most of the time, before starting making changes, you want to update the
game to make sure you have the most recent version of the game. Otherwise,
another developer may have already committed changes to a file that you will
modify again, and then conflicts will happen. Always update the root folder,
since updating sub-folders will only update those sub-folders.

Very important: close editors before updating, otherwise you may update,
then accidentally save on your editor (game, scripts or whatever) and overwrite
the updates.

On your first commit you may get a prompt. More about it on hooks section.

2.2 RMXP Problems

The problem comes with RMXP. When you use the game editor, many files
that haven’t been modified can be marked as modified. You want to revert the
“changes” (remove the “modified” flag by reverting the file to its original state)
for those files right before committing, or we will get unnecessary conflicts later.

Basically, you have some false positives. What’s happening here is that files
have actually been modified by the editor, but the changes may be so trivial as
your cursor position on an editor screen. You don’t want to commit that because
that will prevent other developers from working with those files at the same time.

5
 In this context, revert allows you to restore the files to the current revision
version before changes were made.

If you are only changing maps/events, you should only push the map file you
changed. Don’t push MapInfo.rxdata unless you are adding/removing maps
or changing their properties by right clicking on them. Same for all the system,
states, enemies, actors, etc. files. Only commit those that you actually changed.

In my opinion, using the revert option is the best way to avoid committing
incorrect files. But you should be careful, since you may accidentally revert the
work you’ve been doing. You can also unselect files you don’t want to push while
committing, revert them later.

Always make sure that you only commit the files you need to commit and
nothing else.

2.3 Hooks

Hooks are programs that are executed before doing a certain action. For example,
we have hooks when committing that update revision numbers in config/Revision.

You should always commit the revision????.info file. This will happen
by default, just do not change it. The first time you run a hook, you may need to
include the file manually though.

You should always execute hooks. The first two-three times, you should execute
manually, and if they work fine, you can set them to always be executed. The first
time they may even ask you to give some info, like your desired developer id.

You can make SVN forget your script execution choices by going to:

TortoiseSVN > Settings > Saved Data > Approved Hook Scripts > Clear

2.4 Recompiling

If you need to recompile you can remove the Cache.rxdata file and start the
game again, since this will force a cache recompile.

If you need to recompile multiple times, you have different options in the
config/general.cfg file (you need to play once to generate this file, since it’s not
distributed directly on the repository). Open it with Notepad++ or any other
plain text editor, and change Cache Recompile from false to true. You can also
set Quick Recompile to true to recompile only once, but removing the cache is
usually a faster approach.

6
 Notice that most of the time you don’t need to recompile. You should only
recompile when updating XML files, and if you are making multiple changes you
don’t need to push the recompiled cache until you have all the changes prepared,
though you should make sure that recompile works even if you aren’t pushing the
recompiled cache. That’s because many users have custom content and will recom-
pile themselves, or have automatic recompile activated. So make sure recompile
works before pushing new XML files or changes to them.

2.5 Updating News

You can update the game news by simply modifying the config/news.txt file. No
recompile, nothing else required. Make sure to update the date too!

3 Good Practices

3.1 Sourceforge

Sourceforge is a great resource, since it allows you to do many of the operations

you can do in your computer (or other devices when you don’t have the repository
accessible), some of them even in an easier way.

You can go to the game repository at sourceforge.net/projects/hsbr,

then click on Browse Code to see the latest revision contents.

You can:

• See last commits and keep track of the project changes, by going to Browse
Code followed by Browse Commits. You can also do this with TortoiseSVN.

• Navigate the project folders and download files. Sometimes you want to
see/download specific files, and you can get them here.

• See previous revisions and changes history for specific files. Sometimes prob-
lems may arise, where you will want to see previous versions of an specific
file, and see what changed between commits, or when. By clicking on any
folder or file, and then on the history icon, you will be able to see and
download previous commits related to those files/directories.

7
3.2 Locked Files

There are some files that you should never or very rarely modify. Many of them
are unique for each user (like most config/ files) or simply shouldn’t be changed.

In order to prevent developers from committing files that they shouldn’t, we

use ignore lists and locks. Unless you don’t know very well what you are doing,
you shouldn’t generally mess with those.

3.3 Move And Rename

With TortoiseSVN you can also move and rename files. This is important if you
are moving a large amount of files, because if you don’t use the move option, they
will be copied instead of moved, and people will have to redownload them.

To move a file or group of files, select them, and then drag and drop them
wherever you have to while right-clicking the mouse. When you release the mouse,
an small contextual menu should appear which will give you the option to move
the files.

In order to rename a file, right click it, go to Tortoise SVN and select Rename.
Type new name, done.

Notice that these two operations do not only save us from unnecessary new
files download, but they also won’t break the repository history. If you delete and
create a new file, that new file doesn’t have history, and it’s harder to track many
issues.

3.4 Ignore lists

Ignore lists are lists of unversioned files (files that are generated by the game but
are not in the repository, like the config/ ones) that shouldn’t be committed.
Ignore lists are shared for all developers, and should be correct already, so in
general you should avoid using the option to untrack files for yourself, since it will
also affect other developers.

If you want to ignore files only in your local copy of the repository, you can
use changelists. Go to the commit menu, then right click on the file you want to
ignore, add to ignore list. Make sure if you ever have to revert the file, you don’t
revert the changelist or you will have to add it again.

8
4 Others

4.1 Event Analyzer

The code contains an event analyzer. For coders, it can be accessed easily in
the Event Analyzer script, but non coders can also use good part of it through
analyzer.cfg and even generate map dumps directly with DevHacks. A copy of
the file can be found on the developer guides section. If you want to use it, you
only need to copy it to the config/ folder. There, you only need to open the file
and read the examples to get an idea of how to use it.

The system should be quite error proof, so don’t worry about typos or mistakes;
if something isn’t correct, the system will tell you.

Here a brief list of useful things you can do with current configuration options:

• Quickly find a map by id.

• Find where a variable or switch is being modified, useful for debugging.

• Find where specific items are being given/sold.

• Search specific text or code in the events.

4.2 DevHacks

While you are in the game map, you can press CTRL + SHIFT + H anytime to
access an special menu for developers. There are many useful options for testings.
Most are intuitive enough to use without explanation, but we clarify a few details
here:

• Manual Teleport: you will get a new prompt to enter the map id you want
to go to. If there are multiple maps with that id in different regions, you
will have to select the region you want to go to, and finally you will have
to enter the coordinates where you want to appear. You can use the Jump
option later to adjust your position if you end up in a non-passable tile.

• Jump: you get a new prompt with your current position, which you can
adjust to teleport inside the current map you are in.

• Open/Run CFG Code: this is an advanced option to run arbitrary code

directly from inside the game. If you are not a coder you have a few already
written useful lines, but it’s mainly oriented to help coders do random tests,
so you shouldn’t worry much about it.

9
 Keep in mind that some options are a bit hacky and might break something
on long runs or if you use them in the middle of certain quests, so use only while
testing.

10