TiTsEd - A save editor
- Thread starter Chase
- Start date
Not sure if this has already been brought up, but I noticed that, in TiTSEd, if I open a savefile and save to a slot, even if didn't change anything, if that save has an amount of credits with 7 digits and it starts with a "2" or a "3" the amount is halved when I loed that save in the game or open it in TiTSEd again.
Sounds like an encoding issue - 2097151 is the largest int that can be encoded with 3 bytes. Looks like it tries to save a value that need 4 bytes to encode with 3 bytes discarding a bit somewhere...
just as I thought
// Skip if:
// * Those 7 most signficant bits so far are zero
this is wrong for 22 bit values - since the least significant byte stores now 8 bits we actually have to save 7 zero bits with a continuation bit at the start
(eg 2097152 has to be encoded as 04 80 c0 80 00)
just as I thought
// Skip if:
// * Those 7 most signficant bits so far are zero
this is wrong for 22 bit values - since the least significant byte stores now 8 bits we actually have to save 7 zero bits with a continuation bit at the start
(eg 2097152 has to be encoded as 04 80 c0 80 00)
Last edited:
I should have mentioned that this doesn't occur when the first digit is a "4" or higher.
Last edited:
then it is a 23 bit value and the 4th byte is written because the 7 bits stored there are not 0 and everything is fine again
Code:
21 bit value:
c2211111 c1111100 c0000000
c1098765 c4321098 c7654321
22+ bit value:
c2222222 c2221111 c1111110 00000000
c9876543 c2109876 c5432109 87654321
notice how 22 bits fit now into the last 3 bytes, but to be interpreted correctly the 4th byte has to be written even though all data bits are zero
Isn't it also a characteristic of the Laquine? I swear I remember seeing it in Kelly's sex scenes/description.
No, Kelly has two dicks, supposedly from her father despite mods not being inheritable.
I know, but wait; whenever the devs start a dual-stream, they announce it with a post on the main site, including a picture of Kelly and Penny With a horse doing frotting, and I swear Kelly's looks like they have a twin set of glans on them. You know what I'm talking about?
If you mean adding one to your inventory, it's in the consumable section. It's called Horse Cock.
Btw @Chase and @alkeiser (sorry for pinging both,but idk who is going to update the save editor) Volley still works with the latest public build, even though it isn't available in game anymore (a dumb choice imo), so please don't nix it. Idk if this helps any, but I added the level 9 perks to my xml, which should be attached to this comment. I also have no clue what I'm doing, so sorry if I'm bothering for nothing. It worked on my version of the game though, so...yeah, idk.
Edit: Lol, changed the file because level 10 is a thing in the public build now
Last edited:
Latest release of the editor has the new perks and items from the 0.7.59 public build
I just marked them "deprecated" like I did to the Level 1 perks.
This helps quite a bit, actually
Last edited:
!!! The new Fixed quantity options! I needed something this! Messing around with the wetness and milk multipliers to get the numbers I wanted was annoying as hell!
Call me weird, but I like seeing numbers that end in zeros when looking at the codex. Seeing messy numbers like 458 mls bothers me. Between this and the improved thickness ratios from the last update, getting the numbers I want for my new characters is getting better all the time.
Thank you. Being able to make my characters start off the way I want them to before exploring the world improves this game by a lot for me. With every improvement to the save editor, this only gets better. I barely touch minerva at this point. Thank you.
Call me weird, but I like seeing numbers that end in zeros when looking at the codex. Seeing messy numbers like 458 mls bothers me. Between this and the improved thickness ratios from the last update, getting the numbers I want for my new characters is getting better all the time.
Thank you. Being able to make my characters start off the way I want them to before exploring the world improves this game by a lot for me. With every improvement to the save editor, this only gets better. I barely touch minerva at this point. Thank you.
To reiterate, it only happens when it is a 7-digit number that starts with a "2" or "3". Anything that doesn't meet both criteria is not halved
Oh come on guys - I told you what's wrong.
You have to fix AmfWriter.WriteU29 instead of converting the value to a different type and hope for the best.. otherwise the problem persists for every other int/uint value (and string length and what else is using this serialisation function)
if (!fourBytes && b == 0 && numBytes == 0 && shift >= 0) continue;
will probably do the trick.
You have to fix AmfWriter.WriteU29 instead of converting the value to a different type and hope for the best.. otherwise the problem persists for every other int/uint value (and string length and what else is using this serialisation function)
if (!fourBytes && b == 0 && numBytes == 0 && shift >= 0) continue;
will probably do the trick.
It wasn't just hoping for the best, the source for TiTS defines those values as a Number, the closest to a Number in C# is a double.
A whole lot of other fields would have the same problem if they could ever be that large...
tried sleeping or something? - the xp screen update is strange
I created a new save, changed the xp and credits to 3.000.000 (in my editor, saved as int) and loaded the game - credits would display 3000000 but xp would only update to 102. Sleeping would 'fix' the xp to 2.999.900 and when I now load the 3m save it would display 3.000.000 for both values immediately after loading...
btw this is the diff
the file got 5 bytes larger (3 bytes for xp 2 bytes for money) so saving 3m as integer does work
I created a new save, changed the xp and credits to 3.000.000 (in my editor, saved as int) and loaded the game - credits would display 3000000 but xp would only update to 102. Sleeping would 'fix' the xp to 2.999.900 and when I now load the 3m save it would display 3.000.000 for both values immediately after loading...
btw this is the diff
Code:
6c6
< 63 c
---
> 68 h
66732c66732,66735
< 00 .
---
> 80 .
> db .
> c6 .
> c0 .
67171,67172c67174,67177
< 8b .
< 5c \
---
> 80 .
> db .
> c6 .
> c0 .the file got 5 bytes larger (3 bytes for xp 2 bytes for money) so saving 3m as integer does work
Last edited:
This is now really odd apparently it's tied solely to this one save.
Because when I tried to enter "3000000" or "2000000" it wouldn't be halved, but when I opened this one save in slot 5 and save it to slot 2 or slot 3 the credits, which were 2244964, got halved, but when I corrected it back to "2244964" it wasn't halved and when I deleted the original save on slot 5 and replaced it by saving the save on slot 3 to slot 5 when I tried save to another slot again the amount wasn't halved.
I guess it was fixed.
I apologize for wasting your time....
Because when I tried to enter "3000000" or "2000000" it wouldn't be halved, but when I opened this one save in slot 5 and save it to slot 2 or slot 3 the credits, which were 2244964, got halved, but when I corrected it back to "2244964" it wasn't halved and when I deleted the original save on slot 5 and replaced it by saving the save on slot 3 to slot 5 when I tried save to another slot again the amount wasn't halved.
I guess it was fixed.
I apologize for wasting your time....
do you still have copies of the files? I'm really curious what could trigger such a behaviour...
I think there is a possibility that the broken WriteU29 implementation wrote corrupt save games, but i have no idea what would happen on loading such a file (I would guess a crash/exception but who knows)
theory
write this binary value as u29
this would require 4 bytes split 7 7 7 8
0000000 1111111 1111111 11111111
first byte would be incorrectly dropped
second byte would be expanded by continuation bit to
11111111
third byte would be expanded by continuation bit to
11111111
fourth byte would not be expanded but as 8 bit value already includes the continuation bit
11111111
so on reading it would load these 3 bytes with cont bit set and continue to read the next byte as fourth byte of this value making a mess of the remaining file content...
I think there is a possibility that the broken WriteU29 implementation wrote corrupt save games, but i have no idea what would happen on loading such a file (I would guess a crash/exception but who knows)
theory
write this binary value as u29
Code:
3 2 1
2 4 6 8
00000000 00111111 11111111 11111111this would require 4 bytes split 7 7 7 8
0000000 1111111 1111111 11111111
first byte would be incorrectly dropped
second byte would be expanded by continuation bit to
11111111
third byte would be expanded by continuation bit to
11111111
fourth byte would not be expanded but as 8 bit value already includes the continuation bit
11111111
so on reading it would load these 3 bytes with cont bit set and continue to read the next byte as fourth byte of this value making a mess of the remaining file content...
Last edited:
I'm not sure if I'm doing something wrong but when I try to launch the save editor I get an error: https://puu.sh/wgr6V/d952869c13.png
not sure how to fix this
not sure how to fix this
No, the process of fixing this required me to delete it, but, in hindsight, I should have backed it up.