Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
StateWindow::StateWindow() {
|
|
|
|
stateWindow = this;
|
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
layout.setPadding(5);
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
nameLabel.setText("Name:");
|
|
|
|
nameValue.onActivate([&] {
|
|
|
|
if(acceptButton.enabled()) acceptButton.doActivate();
|
|
|
|
});
|
|
|
|
nameValue.onChange([&] {
|
|
|
|
doChange();
|
|
|
|
});
|
|
|
|
acceptButton.onActivate([&] {
|
|
|
|
doAccept();
|
|
|
|
});
|
|
|
|
cancelButton.setText("Cancel").onActivate([&] {
|
|
|
|
setVisible(false);
|
|
|
|
});
|
|
|
|
|
|
|
|
setSize({400, layout.minimumSize().height()});
|
|
|
|
setDismissable();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateWindow::show(string name) -> void {
|
|
|
|
nameValue.setText(name).setProperty("input", name);
|
|
|
|
doChange();
|
|
|
|
setTitle(!name ? "Add State" : "Edit State");
|
|
|
|
setCentered(*toolsWindow);
|
|
|
|
setVisible();
|
|
|
|
setFocused();
|
|
|
|
nameValue.setFocused();
|
|
|
|
acceptButton.setText(!name ? "Add" : "Edit");
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateWindow::doChange() -> void {
|
|
|
|
bool valid = true;
|
|
|
|
auto name = nameValue.text().strip();
|
|
|
|
if(!name) valid = false;
|
|
|
|
for(auto c : name) {
|
|
|
|
if(c == '\\'
|
|
|
|
|| c == '\"'
|
|
|
|
|| c == '\t'
|
|
|
|
|| c == '/'
|
|
|
|
|| c == ':'
|
|
|
|
|| c == '*'
|
|
|
|
|| c == '?'
|
|
|
|
|| c == '<'
|
|
|
|
|| c == '>'
|
|
|
|
|| c == '|') valid = false;
|
|
|
|
}
|
|
|
|
if(auto input = nameValue.property("input")) {
|
2018-06-11 04:50:18 +00:00
|
|
|
if(name != input && file::exists({program->statePath(), "managed/", name, ".bst"})) valid = false;
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
}
|
|
|
|
nameValue.setBackgroundColor(valid ? Color{} : Color{255, 224, 224});
|
|
|
|
acceptButton.setEnabled(valid);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateWindow::doAccept() -> void {
|
|
|
|
if(acceptButton.text() == "Add") {
|
|
|
|
toolsWindow->stateManager.createState(nameValue.text());
|
|
|
|
} else {
|
|
|
|
toolsWindow->stateManager.modifyState(nameValue.text());
|
|
|
|
}
|
|
|
|
setVisible(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
StateManager::StateManager(TabFrame* parent) : TabFrameItem(parent) {
|
|
|
|
setIcon(Icon::Application::FileManager);
|
|
|
|
setText("State Manager");
|
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
layout.setPadding(5);
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
stateList.setBatchable();
|
|
|
|
stateList.onActivate([&] {
|
|
|
|
editButton.doActivate();
|
|
|
|
});
|
|
|
|
stateList.onChange([&] {
|
|
|
|
auto batched = stateList.batched();
|
|
|
|
loadButton.setEnabled(batched.size() == 1);
|
2018-06-10 08:07:19 +00:00
|
|
|
saveButton.setEnabled(batched.size() == 1);
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
editButton.setEnabled(batched.size() == 1);
|
|
|
|
removeButton.setEnabled(batched.size() >= 1);
|
|
|
|
});
|
|
|
|
loadButton.setText("Load").onActivate([&] {
|
|
|
|
if(auto item = stateList.selected()) {
|
2018-06-11 04:50:18 +00:00
|
|
|
program->loadState({"managed/", item.cell(0).text()});
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
saveButton.setText("Save").onActivate([&] {
|
2018-06-10 08:07:19 +00:00
|
|
|
if(auto item = stateList.selected()) {
|
2018-06-11 04:50:18 +00:00
|
|
|
program->saveState({"managed/", item.cell(0).text()});
|
2018-06-10 08:07:19 +00:00
|
|
|
}
|
|
|
|
});
|
|
|
|
addButton.setText("Add").onActivate([&] {
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
stateWindow->show();
|
|
|
|
});
|
|
|
|
editButton.setText("Edit").onActivate([&] {
|
|
|
|
if(auto item = stateList.selected()) {
|
|
|
|
stateWindow->show(item.cell(0).text());
|
|
|
|
}
|
|
|
|
});
|
|
|
|
removeButton.setText("Remove").onActivate([&] {
|
|
|
|
removeStates();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateManager::loadStates() -> void {
|
|
|
|
stateList.reset();
|
|
|
|
stateList.append(TableViewHeader().setVisible(false)
|
|
|
|
.append(TableViewColumn().setExpandable())
|
|
|
|
);
|
2018-06-27 01:56:27 +00:00
|
|
|
for(auto filename : program->managedStates()) {
|
|
|
|
stateList.append(TableViewItem()
|
|
|
|
.append(TableViewCell().setText(filename.trimRight(".bst", 1L)))
|
|
|
|
);
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
}
|
|
|
|
stateList.resizeColumns().doChange();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateManager::createState(string name) -> void {
|
2018-06-11 04:50:18 +00:00
|
|
|
program->saveState({"managed/", name});
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
loadStates();
|
|
|
|
for(auto item : stateList.items()) {
|
|
|
|
if(item.cell(0).text() == name) item.setSelected();
|
|
|
|
}
|
|
|
|
stateList.doChange();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateManager::modifyState(string name) -> void {
|
|
|
|
if(auto item = stateList.selected()) {
|
2018-06-27 01:56:27 +00:00
|
|
|
string from = {"managed/", item.cell(0).text()};
|
|
|
|
string to = {"managed/", name};
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
if(from != to) {
|
2018-06-27 01:56:27 +00:00
|
|
|
program->renameState(from, to);
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
loadStates();
|
|
|
|
for(auto item : stateList.items()) {
|
|
|
|
if(item.cell(0).text() == name) item.setSelected();
|
|
|
|
}
|
|
|
|
stateList.doChange();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto StateManager::removeStates() -> void {
|
|
|
|
if(auto batched = stateList.batched()) {
|
|
|
|
if(MessageDialog("Are you sure you want to permanently remove the selected state(s)?")
|
|
|
|
.setParent(*toolsWindow).question() == "Yes") {
|
|
|
|
for(auto item : batched) {
|
2018-06-27 01:56:27 +00:00
|
|
|
program->removeState({"managed/", item.cell(0).text()});
|
Update to v106r37 release.
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
2018-06-07 11:48:41 +00:00
|
|
|
}
|
|
|
|
loadStates();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|