Home » Stars! Clones, Extensions, Modding » Stars! Extensions » xy modification after game has started
| |
Re: xy modification after game has started |
Sun, 06 July 2014 09:07 |
|
raptor | | | Messages: 138
Registered: June 2014 | |
|
I'm open to other ideas and suggestions, but my current idea was that you could do something like the following (not real code):
1. blocklist = Decryptor.readFile("game.xy")
2. Modify a block in the blocklist
3. (eventually) Encryptor.writeFile(blocklist, "game.xy")
Or:
1. Create new types of Blocks as java objects (FileHeaderBlock, etc.), setting their properties through Java.
2. build up a block list
3. Encryptor.writeFile(blocklist, "game.xy")
The whole idea is to be able to edit the data using standard java objects, then reading/writing to a file using those objects. Internally, we could easily have other data types as members of the blocks themselves, then allow API access to them.
I don't know the best way to go about it.. I just started coding and this is what happened. Above all, I want to make the code semi-easy to follow as that will lower the barrier to entry for contributions.
Report message to a moderator
|
|
|
Re: xy modification after game has started |
Sun, 06 July 2014 15:14 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
raptor wrote on Sun, 06 July 2014 15:07The whole idea is to be able to edit the data using standard java objects, then reading/writing to a file using those objects. Internally, we could easily have other data types as members of the blocks themselves, then allow API access to them.
I don't know the best way to go about it.. I just started coding and this is what happened. Above all, I want to make the code semi-easy to follow as that will lower the barrier to entry for contributions.
Sounds good. Hardcoding could do for starters, but I'm guessing some parameterization will be needed for better flexibility. At the very least, avoid having to hardcode so many things if there's a way to "softcode" the main details (type, size, sub-blocks, kinds of payload, etc) for each blocktype.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: xy modification after game has started |
Sun, 06 July 2014 16:53 |
|
raptor | | | Messages: 138
Registered: June 2014 | |
|
Maybe I'm misunderstanding what you mean by 'hard-code'. Right now, I have hard-coded nothing except the deserialization code in things like FileHeaderBlock (decode() method). If this is what you refer to, then yes, I believe that we could do better - I was thinking that we could implement our own serialization class that could encode/decode data points in some sort of regular pattern, and apply the rules to each of the block types. Then it would just be a matter of laying out the class structure appropriately. I'm not that experienced in the area of serialization, but I'm a quick study (or at least a stubborn study).
I am curious, though, what coding abilities do you have (and could you help out)? If you've worked with some of the other developers, maybe you could answer some of my questions... like, why do I have to swap bytes so often?
Ideally, I'd love to get my hands on as much source code from any of the other projects as possible. Although, from what I gather, I'm the first to post source code? which seems crazy...
Report message to a moderator
|
|
|
Re: xy modification after game has started |
Sun, 06 July 2014 20:31 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
raptor wrote on Sun, 06 July 2014 22:53Maybe I'm misunderstanding what you mean by 'hard-code'. Right now, I have hard-coded nothing except the deserialization code in things like FileHeaderBlock (decode() method). If this is what you refer to, then yes, I believe that we could do better - I was thinking that we could implement our own serialization class that could encode/decode data points in some sort of regular pattern, and apply the rules to each of the block types. Then it would just be a matter of laying out the class structure appropriately.
You're probably right. Must be my romantic side wanting to have everything handled by just one super-flexible magic class that didn't have anything hardcoded at all but instead relied on pre-filled data tables and whatnot.
Quote:I am curious, though, what coding abilities do you have (and could you help out)?
From Assembler and C to Java, including Basic, SQL and shell scripting, plus a knack for "black-box" testing, though I seem to be developing some kinda laziness lately which pushes me more towards the design side of things and away from the thrills of pure coding.
Quote:If you've worked with some of the other developers, maybe you could answer some of my questions... like, why do I have to swap bytes so often?
I'd bet there must be some integer math going on which handles bytes in pairs or even quartets, but the disassembly didn't quite piece together. I wanted to look into that this weekend but the hours somehow seemed to fly past in a blink.
Quote:I'd love to get my hands on as much source code from any of the other projects as possible. Although, from what I gather, I'm the first to post source code? which seems crazy...
It is, but the general consensus is far from settled on the issue, since most "source code" would concern the (en)decryption routines, and too little has been done on the far more interesting fronts of bug-stomping, cheat-killing, MM-automation and scenario-creation.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | | | | |
Re: xy modification after game has started |
Sat, 19 July 2014 02:18 |
|
raptor | | | Messages: 138
Registered: June 2014 | |
|
I think I have settled on an optimal way of reading the byte stream. The data I'm after usually comes in 1, 2, or 4 byte chunks (before bit-twiddling to get higher packed data points). Here are the rules I follow:
1. If a single byte, read the byte
2. If two bytes, read them in swapped (little-endian)
3. If four bytes, read them in swapped
You can see how I implement it here:
https://github.com/raptor/stars/blob/master/python/decryptor .py#L253
So basically, instead of bonkers structures that are parsed directly from the byte stream, without swapping, that look like this:
XXXXXXXX YYYYYYXX NNYYYYYY NNNNNNNN
(This is a 4 byte planet chunk from the XY file)
X = X coordinate offset
Y = Y coordinate
N = Planet Name ID
The byte stream now looks like this:
NNNNNNNN NNYYYYYY YYYYYYXX XXXXXXXX
Everything lines up! This makes the decoding code much simpler and easier to follow.
On another note - I find I'm enjoying writing python,so I'm not sure I'll continue with the Java. Also, my time is very limited and porting code like this from decompiled C# is slow-going. Honestly, it's slightly demoralizing that there is source code out there that has most of my work done already, but it was never released (XyliGUN's tools in particular interest me, but they were not written in a language that's easily decompilable).
I encourage anyone who wants to add to my work by either forking the project in github or even sending me other code to merge.
Report message to a moderator
|
|
| | | | | |
Re: xy modification after game has started |
Mon, 21 July 2014 00:22 |
|
raptor | | | Messages: 138
Registered: June 2014 | |
|
Which one are you looking at? I decompiled StarsPlayerTool.exe, but pulling out raw strings does indeed show names for Blocks 6,7,8,12,13,16,17,20,26,28,30. Most of this data is already in the decompiled sources for PaulCr's tools, of which I'd like to exhaust first before I attempt learning about disassembly.
Report message to a moderator
|
|
|
Re: xy modification after game has started |
Mon, 21 July 2014 12:11 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
raptor wrote on Mon, 21 July 2014 06:22Which one are you looking at? I decompiled StarsPlayerTool.exe, but pulling out raw strings does indeed show names for Blocks 6,7,8,12,13,16,17,20,26,28,30.
2013.09.01. IDA-free finds all strings and many func names, and IDA6demo flags most RTL calls too. You can forget about Boomerang's fake C src. IDA's true ASM is much clearer.
Quote:Most of this data is already in the decompiled sources for PaulCr's tools, of which I'd like to exhaust first before I attempt learning about disassembly.
By all means, milk PaulCr's code for all its worth. I can handle the (dis)assembly if needs be, though I reckon the exe itself will be more useful as benchmark than what can be guessed about structs and algorithms from the ASM.
Are there any more tools that might harbor other useful information?
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| |
Goto Forum:
Current Time: Fri Mar 29 03:10:15 EDT 2024
|