04-23-2014, 06:38 PM
04-24-2014, 03:52 AM
I will see what I can come up with in the code, I hope over time I can solve this safely without breaking anything. Over all it will come down to several things but some of these features that people like I rely on, is much to painful to just play and beat for story's sake. I love completing everything the game developers added to the game, *shrugs* i dunno, some of those missing features because of this just make me happy lol.
@tsunami yeah, its definitely not on the game side, and if I had to bet my money on what it "possibly" could be related to, I would say the way the address in the game communicates with the memcard / core. This is where I will begin my search after doing some dumps first.
I will be working with the source code both from stable and svn builds, this way I can pinpoint what has changed and prevent anything else from breaking. Here goes nothing.
@tsunami yeah, its definitely not on the game side, and if I had to bet my money on what it "possibly" could be related to, I would say the way the address in the game communicates with the memcard / core. This is where I will begin my search after doing some dumps first.
I will be working with the source code both from stable and svn builds, this way I can pinpoint what has changed and prevent anything else from breaking. Here goes nothing.
04-24-2014, 09:06 AM
I think the devs were talking about this before that a fix exist but that fix would break too many games.
04-24-2014, 12:44 PM
there is always more than 1 way to fix something when it comes to programming.
04-24-2014, 01:28 PM
(04-24-2014, 12:44 PM)Jwalters0814 Wrote: [ -> ]there is always more than 1 way to fix something when it comes to programming.
Yes, of course, and priorities too.
PS: That Xenosaga bug is annoying but it can be workaround by sstates till the end of chapter 1 in the worst scnery. Xion's own quarters is one of the safe save points at least.
What I tried to say in the previous post was about sstates aren't to be feared unless misused. It should not be used exclusively and should be "refreshed" once and again by loading from memcard at reasonable frequency. That bug is annoying but not unavoidable at all.
Actually is good idea making a sstate just before making a memcard save too (always and in all games), just in case of something going wrong.
The ultimate advice is: Do a memcard load once and again, be used doing so even if everything looks right. Then make a sstate immediately after, the point is to grant the sstate being clean as much as possible. Repeating, sstates don't corrupt games, it saves the current emulator's memory space and then records whatever corruption already there and then may accumulate corruption to a game breaking status if not cleaned frequently enough.
Other than this, sstate is perfectly safe and a wonderful feature. Just know how and when to use it.
Edit: Issues might arise if trying to do a memcard save after loading from a sstate, this is specially true if sstate loads are done more than once in a same game session. The reason is the possibility of the memcard having a near to current point save but the data was significantly changed, this could create problems and to prevent inconsistencies the emulator "ejects" the memcard. If that happens, sometimes is enough to force reload it from the GUI.
If the player has time enough to play till getting to a new save point, all the better, use memcard exclusively... but in a pinch the sstate might be your best friend.
04-24-2014, 11:26 PM
Yes @ nosisab, I am very aware of this and thank you for trying to help, but for what I need to get the most out of this game, I am gonna have to fix some of these small bugs in these rpg games.
04-25-2014, 12:36 AM
(04-24-2014, 09:06 AM)vsub Wrote: [ -> ]I think the devs were talking about this before that a fix exist but that fix would break too many games.
This is why it never been fixed, and why I told OP he free to try and fix it and "if" it dont break things for alot of other games it might get used.
honestly the bug is not an issue annoyance sure ,but it is in no way a game breaker nor does it make doing 100% of all things in the game difficult.
It simple make a save state before you use save point, to be safe once you learn which ones dont work (which like 3 or 4 which arnt really in bad places) you will adapt.
04-25-2014, 01:54 AM
(04-24-2014, 11:26 PM)Jwalters0814 Wrote: [ -> ]Yes @ nosisab, I am very aware of this and thank you for trying to help, but for what I need to get the most out of this game, I am gonna have to fix some of these small bugs in these rpg games.
A sorry, I didn't know you was going to do it, that changes everything and is most welcome.
May help to know that's somewhat random issue, at least in a few save points I was able to make the save from the first attempt (very seldom) or after coming back from a sstate (made just before attempting the save).
Edit: Or was it to know that save was not secure and then continue to try at another... don't really recall much, I played the game very long ago and don't know what changed meanwhile.
04-26-2014, 08:40 AM
No prob nosisab, words can be read wrong or taken wrongly, kind of easy to do without a voice to give it a contextual meaning. Anyways, I am getting closer, hopefully I can produce great results soon and upload via git.
01-10-2020, 05:45 PM
(04-13-2014, 06:11 AM)tsunami2311 Wrote: [ -> ]No this bug hasnt been fixed in all this time ( its a really old bug) cause last i checked coders said fixing it will break things so they never botheredother broken Savepoints involve the save screen post Woglinde.
Just use save state before you use save point till you know which one go to boot menu. there is only like 3 or so that do it, Shion room on woglinde/save on elsa by bridge and the first save when exit the encephalon. there ir probably 1 or 2 more but like i said just use save state before you use save point