Standalone [1.4.4] Terrasavr, web-based inventory editor

You should add where you can see what your character would look like with all of your armor and accessories on.
 
Email notifications have betrayed me again, so these are some very late replies.
I think I'm not allowed to access websites in the Cocos Islands, for some reason.
It is rather strange, since while the domain is in CC zone, actual server resides in France.
Question. Will this update to 3.1 when that comes out if not NOO!!! If so yay!
Yes, I intend to update the program when 1.3 comes out.
You should add where you can see what your character would look like with all of your armor and accessories on.
It would be a good addition but it's tricky to make an exact copy of some drawing algorithm when you have no idea how it works (especially with making dyes color items the same way as they do in-game).
Also would increase the size of the program a fair bit because of newly obtained need to store item variations (e.g. male/female armor differences), information about how items are attached, and more, and more...
Maybe it would work as a separate application, but it's hard to tell if something will be popular or not, and it's a bit heart-breaking when you've worked on something for a while and then it just goes unnoticed.
 
Will it be back in time for 1.3????? :'(
I sure hope so... basically it appears as if the server hosting my site was suspended for the lack of payment, but payments are charged only in the start of the month. And tech support folks have not replied anything so far (1.5 days now).
If this nonsense continues, I'll find some other place to host the program at.
For now, here's an offline version of SWF for 1.2.4.1. These can't auto-update, so it's worth keeping an eye on this topic.
 
Hi, Yellow I'd like to say thanks for the website, and for rehosting it after it went down a couple of days ago.
And thanks for making it as a pure browser implementation, though obfuscated/minified it still gave me motivation & clues to make a Python player-editor when I was struggling against how C# uses the RijndaelManaged & BinaryReader classes.
 
Server issues were resolved and everything should be fully operational again. About time!
I have also updated both versions a little:
* Changed tab titles to make more sense to people not familiar with modding the game. "General" is now "Character", "Stash" tabs are named "Bank" and "Safe" accordingly, and "Servers" is "Worlds" (since it applies to local worlds as well).
* Fixed a glitch where beam swords (and a few other items) would display use time as 100 instead of the actual value.
* Fixed a glitch where app area in the flash version could be cut off by sidebar (or vice versa, depending on your browser).
itch.io version will remain available.
 
Good news: Today I had actually managed to get Terrasavr to compile to C++ for a native (Windows/Mac/Linux) version:
h3u4mzk.png

Bad news: At the moment it runs... at 4FPS. And somehow takes up whole two CPUs for that. Need to investigate.
 
Good news: Today I had actually managed to get Terrasavr to compile to C++ for a native (Windows/Mac/Linux) version:
-snip-
Bad news: At the moment it runs... at 4FPS. And somehow takes up whole two CPUs for that. Need to investigate.
I know with C#, too much input and output at the same time would bog down the application and intensify resource usage. I made a translator that would output binary, Al Bhed, and even give you an upside down translation as you typed. Perhaps you have too much input/output activity going on in your C++ application? Or are you using strictly a web browser control to load a webpage as a resource inside the web browser or streaming the HTML code to the web browser control? (Perhaps this can explain a bit more on what I'm talking about.) I'm not too familiar with C++. I fancy C# and its easy to understand language, you can usually figure out what's going on just by looking at the lines of code.

Hopefully you can find the exact cause. I'm looking forward to seeing binary release.
 
I know with C#, too much input and output at the same time would bog down the application and intensify resource usage. I made a translator that would output binary, Al Bhed, and even give you an upside down translation as you typed. Perhaps you have too much input/output activity going on in your C++ application? Or are you using strictly a web browser control to load a webpage as a resource inside the web browser or streaming the HTML code to the web browser control? (Perhaps this can explain a bit more on what I'm talking about.) I'm not too familiar with C++. I fancy C# and its easy to understand language, you can usually figure out what's going on just by looking at the lines of code.

Hopefully you can find the exact cause. I'm looking forward to seeing binary release.
Terrasavr is written in Haxe (somewhat similar to C# in functionality), which can converts source code to various languages on compilation - JS for HTML5, AS3 for Flash, and C++ for native in this case. This helps a bit with not writing the same code thrice.
A problem was revealed to be in the library I've used for graphics - while for Flash I've used the standard classes (Flash has excellent software rendering), and for HTML5 I've made my own library to map Canvas' 2d rendering functionality for similar results, for C++ neither can be used, so I've had to use someone's library that implements a Flash-like API over OpenGL, but it seems to not be intended for software rendering. To the point where just clearing a 800x480 rectangle with a solid color at 60FPS takes 20% CPU. So it would probably take changing code to use hardware-accelerated rendering everywhere, but that may not work too well either (2850 item images are pretty hard to fit into a sanely sized texture page that would load on all videocards).

Packaging a HTML5 or Flash version would be easier, but that's adding 20MB of Flash Player or a 30MB browser component to a 1MB application. Maybe I'm just being too picky about this.
 
Not being funny, but Terraria itself manages to handle those 2850 item images & hardware-accelerated rendering, and on mobile devices too apparently. ;-)
 
Ok, couple of tech questions for you, honestly a bit general-Terraria rather than Terrasavr:

Do you know the correct decoding of a world's address? Currently Terrasavr displays the 4 bytes as a 32bit int. I can't seem to find a transformation into an IPv4 address that gives me something that makes sense, like 127.0.0.1 or 192.168.etc. Even correctly accounting for 'network' bytes being big-endian. i.e., in Python3:
ipaddress.ip_address( struct.unpack("!I", server_address)[0] )
doesn't seem to do it right.

Do you know how the 1.3 changes are likely to encode the 'favorited items' data? I assume it'll have to be stored in the Player file, but not sure if it'll be a new section (i.e. a bitmask, forming a contiguous byte block to be easily identified & handled by 3rd party devs) that is applied by the game logic to the inventory, or a new byte flag for every item. Or some magic-number abuse stuff like <0 sized stack for an item (assuming you can only favourite singular items, not types/stacks). How do developers expect to find out? Reverse engineer the files, and just assume the encryption won't also be changed & make it much much harder to do so?
 
Last edited:
Not being funny, but Terraria itself manages to handle those 2850 item images & hardware-accelerated rendering, and on mobile devices too apparently. ;-)
Regarding this, it's not much of a concern in general, just subject of worry in the scope of the graphics library used - as previously mentioned, it simulates Flash API, but does so weirdly, making it hard to warrant optimal execution.
Ok, couple of tech questions for you, honestly a bit general-Terraria rather than Terrasavr:

Do you know the correct decoding of a world's address? Currently Terrasavr displays the 4 bytes as a 32bit int. I can't seem to find a transformation into an IPv4 address that gives me something that makes sense, like 127.0.0.1 or 192.168.etc. Even correctly accounting for 'network' bytes being big-endian. i.e., in Python3:
ipaddress.ip_address( struct.unpack("!I", server_address)[0] )
doesn't seem to do it right.

Do you know how the 1.3 changes are likely to encode the 'favorited items' data? I assume it'll have to be stored in the Player file, but not sure if it'll be a new section (i.e. a bitmask, forming a contiguous byte block to be easily identified & handled by 3rd party devs) that is applied by the game logic to the inventory, or a new byte flag for every item. Or some magic-number abuse stuff like <0 sized stack for an item (assuming you can only favourite singular items, not types/stacks). How do developers expect to find out? Reverse engineer the files, and just assume the encryption won't also be changed & make it much much harder to do so?
I also used to think that the 32-bit int is a world address, but it isn't - it's world ID. If you think about it, it kind of makes sense, as server addresses may change, and various worlds can be hosted on the same computer at different times.

At the moment I have no idea if/how "favorited items" are going to be stored in files.
Since the file is encrypted as a whole (including the version number), encryption can't be easily changed around without breaking something.
File format changes can be discovered either via reverse engineering the game binary, or via black box testing - decrypt the file, save the decrypted version somewhere. Make some changes via the game. Decrypt the file again, view differences in hex editor. Once the pattern becomes clear, change the file, encrypt it, and see if the game reads it correctly. When everything seems to work fine, also test it with other random files.
will it be updated when 1.3 comes out?
Yes, it will be. Supposedly quite hastily if I'll be awake when 1.3 comes out.



Also uploaded the supposedly last mini-update before 1.3. Few small tweaks and an updated "starting screen" (multicolored text, heh)
 
Yeah I just wasn't sure if reverse engineering would be the only way to learn the new format, or if there were public resources for such things, or favoured/approved 3rd party devs that get a headstart via info sharing, or closed beta access, etc. Also whether 3rd party devs work together publically to share their progress, and if that's here or at more of a distance from official systems?

I figured the encryption could be fairly easily changed while maintaining backwards compatibility. You'd just default to trying the latest scheme, and if it didn't produce a valid file, try the next oldest system. A newer scheme than current could do this more robustly for future plans to vary it often by the addition of a more complex header and/or digest rather than AFAIK the current simply format/version number int/first 4 decrypted bytes.

W.r.t. worlds, I was assuming the name would be unique, but I realise that would only work locally, and have never iirc played multiplayer to see how the game handles players with the same name, as it probably uses the same solution for worlds, and wouldn't work to ensure persistant unique identifies of them.
Do you know what assigned the world id? Is there a central server/steam mechanism that doles them out? Or is it a hashed timestamp, or random, or something else? TBH this doesn't matter atm, just curious.
 
Regarding public sharing of progress, I don't know actually - perhaps some do. Personally I usually try to figure things on my own, reverting to asking for help only if something makes no sense whatsoever.

For <=1.2.4.1 format, you can find TSGE' (another inventory editor) source on Github: https://github.com/atom0s/TSGE
I haven't looked much into it, but I think the implementation should be correct.
The chances of it being updated for 1.3 are pretty slim though - the author has explicitly declared that they are not going to continue development unless donations are made.

As per encryption, the trouble is not in backward compatibility, but in forward compatibility - if encryption was to change, the earlier versions of the game would see the file as simply corrupt, and some of them would have the courage to remove the "invalid" file upon trying to load it. If it was to store the version bytes outside the encrypted region, it could reliably tell if the file is corrupt or just in newer format.

As per world IDs, I don't know actually. It might be plain random, which by default in C# is seeded from the current system time IIRC. The potential negative effects are also too insignificant to give a 1/(2 power 32) chance of an ID collision further attention. Probably not a centralized mechanism given that Terraria can be played offline and you can later put up your single-player worlds on a server.

On players with the same names, server does not seem to store much per-player information unless you're running some TShock, which adds passwords for proper auth.
 
Back
Top Bottom