I need an input/comments/suggestions and especially objections if any from the field on possible h files merger tool. What I'm think of is a simple merger.exe, that being run against two h files (like "merger game.h1 game.h2") will read all the planets stat data from the first one and append it to the second one (currently only planets data, but things like Designs and Scores could be also merged later). Let's imagine I can create such a tool (I have just merged one of the planet data from one h file to the another h file manually, so in general it works). Can someone imagine any cheating possiblity there if such a tool will be publically available (with no sources of cause)?

[Updated on: Fri, 11 February 2011 13:45]

Report message to a moderator

Hi,

It seems to me that Orca (or someone from the Stars! IRC channel) has already made this application.

Report message to a moderator

Report message to a moderator

I've been scavenging the forums A LOT!!
I don't think something that can merge H file data into stars is available.

If it is, please do post the link

http://starsautohost.org/sahforum/index.php?t=msg&th=453 7&start=6

http://starsautohost.org/sahforum/index.php?t=msg&th=453 7

Micha wrote on Fri, 16 July 2010 16:35

Quote: Now to see if I can add other player's .h data directly into my stars game... Good luck with that. There is (at present) no util that can do that for you. It's on the top of my wish list for all the +10 years that I'm playing this great game. mch

Report message to a moderator

It wasn't Orca, it was Wumpus... he had a webpage where you took the h-files and it would merge them into one.



(it was a few years ago though)

Report message to a moderator

Chuckle...

You started me digging...

at http://stars-util.sourceforge.net/olds.html

Quote:

2005-03-06 - michaelz_wumpus : Team knowledge pooling. Some time ago, I patched together an H file combiner and beta tested it for some teams in the ringsm game. It became moderately polished in that time, and now only really lacks a web service front end (I still don't feel able to release the binaries, let alone the source - see the update on the 10.10.2004). But that's work I find interminably boring, so the X file checker mentioned in the update below is going to get more attention for a while. If someone feels like working on this, I can write up a spec for what I need; it's fairly simple... Just e-mail me at Michael "Wumpus" Zinn <*****>.

email addy at link

Report message to a moderator

Report message to a moderator

Report message to a moderator

Report message to a moderator

XyliGUN wrote on Sat, 12 February 2011 01:39

can someone imagine how people can cheat having h file merger?

Decompile it, isolate the relevant un/encrypting functions, apply liberally elsewhere...

The best way to keep it from happening is Wumpus' way. Obfuscation and other anti-decompiler techniques *might* work, but you'll never know for sure. Actually, no-one knows for sure whether anyone might be using these algorithms already for nefarious purposes.

And the only other way to keep cheaters at bay would be a server-side "feeder" tool that scans all x-files and "sanitizes" them before letting the server go at them.

Some work has already been done in tools like that, including at least one that can also plug some of the better-known bugs.

Report message to a moderator

XyliGUN wrote

can someone imagine how people can cheat having h file merger?

m.a@stars wrote

Decompile it, isolate the relevant un/encrypting functions, apply liberally elsewhere...

Those, who have enough knowledge to decompile/disassemble merger.exe could also decompile stars.exe itself, so it looks like there is no additional help to cheaters in publishing merger.exe.

Any other issues in h file merger except possible decompiling?

Report message to a moderator

Report message to a moderator

Report message to a moderator

Report message to a moderator

XyliGUN wrote on Sat, 12 February 2011 18:16

Those, who have enough knowledge to decompile/disassemble merger.exe could also decompile stars.exe itself, so it looks like there is no additional help to cheaters in publishing merger.exe.

Stars.exe will always be harder to decompile/analize. Size matters!

Report message to a moderator

XyliGUN wrote on Sun, 13 February 2011 02:40

2. Designs - the most tricky part. Until design ids in the source and target h files are different the task is pretty simple, we just need to have a copy of all designs in the target file. Once both h files have a different design with the same design id - merger have to select one of them:

Do you mean that Stars! assigns different IDs for each race that meets the same design belonging to the same race?

Report message to a moderator

m.a@stars wrote

Stars.exe will always be harder to decompile/analize. Size matters!

Yes, it does, but I beleive merger value would be much higher for non-cheaters in team games than the risk of easier decompiling (especially there is pretty easy way to get algorithm anyway, since it's already published).

XyliGUN wrote

2. Designs - the most tricky part. Until design ids in the source and target h files are different the task is pretty simple, we just need to have a copy of all designs in the target file. Once both h files have a different design with the same design id - merger have to select one of them:

m.a@stars wrote

Do you mean that Stars! assigns different IDs for each race that meets the same design belonging to the same race?

Oh, no. I mean that "until source and target h files have different set of designs" - it's easy - we just a need to have a full set of designs in the resulted h file.
But source and target h files could contain different designs with the same id if this design owner has changed it after it was met\acanned by first player and before it was met\scanned by the second.

Report message to a moderator

XyliGUN wrote on Mon, 14 February 2011 08:42

beleive merger value would be much higher for non-cheaters in team games than the risk of easier decompiling (especially there is pretty easy way to get algorithm anyway, since it's already published).

Indeed the risk wouldn't be significantly higher...

XyliGUN wrote

source and target h files could contain different designs with the same id if this design owner has changed it after it was met\acanned by first player and before it was met\scanned by the second.

Hmm. That. So you haven't found an "age of scan" for ship designs the same that exists for planets?

Report message to a moderator

m.a@stars

Hmm. That. So you haven't found an "age of scan" for ship designs the same that exists for planets?

Yep, AFAIK there is no such info.

Report message to a moderator

OK, let's say I'd like to publish StarsHistoryMerger.exe. Any objections?

Features:
* Merging planets stat, like concentrations, original/actual values, planet owner, starbase design (you will see the planets that you didn't yet scanned, but your teammate did)
* Merging known designs (you will see the same designs that your teammate can see including his existing designs and enemy designs known to him)
* Merging progress timelines (you will see your and your teammate progress timeline in your turn, like if PPS were enebaled for your team)

Usage:
StarsHistoryMerger.exe game.mX game.hX game.hY passwordX
where:
game.mX, game.hX - source turn m & h files
game.hY - target turn h file
passwordX - password from game.mX

What it does? It reads data from specified source (m, h) and target (h) turn files, merges it and write result into the target h file. It does verify the password provided and no data will be written if password is incorrect (so you have to know source turn password to steal the data).

It's not yet been extensivly tested, but it works well for a bunch of turns I have from my old games. If somebody wants to see merged turns, you are welcome to send me your files to merge and the password and I'll send you merged h file.

[Updated on: Wed, 16 February 2011 11:19]

Report message to a moderator

XyliGUN wrote on Wed, 16 February 2011 16:08

reads data from specified source (m, h) and target (h) turn files, merges it and write result into the target h file.

Sounds like fun!

What about some parameter to exclude certain info or include just certain info, like ship designs, starbases, minefields, location of 3rd party assets, and such?

Report message to a moderator

XyliGUN wrote on Wed, 16 February 2011 09:08

OK, let's say I'd like to publish StarsHistoryMerger.exe. Any objections?

I object.

Quote:

Well, I was talking to wumpus last summer..

Perhaps Wumpus is wise. And so is Ron. You however, ???

Quote:

What I'm trying to find out is if there are any resonable points to hide compiled tools from those who would really like to use them without cheating and the most important thing can someone imagine how people can cheat having h file merger?

Yes there are. As already mentioned, it would be easier for cheater to hack your file and possibly get important knowledge (did you say password?), versus having to break the Stars code to try the same. The laws of probability? The more difficult it is for everyone to get access, the more difficult it is for cheaters to get access.

Quote:

... (so you have to know source turn password to steal the data).

Steal? Freudian slip or wolf in sheep's clothing? When passwords get involved in such a tool I already have suspicions. Remind me not to play in games you are playing in.

This tool would give advantages to players, that it would essentially require everyone in games to use the tool to have a fighting chance in games. Try playing against a team with this convenient merged info versus teams without the same. Try playing in a one-winner-only game where some of the weaker players pass their h-files to stronger players in exchange for favors. True, they can already pass files to be used in other utilities. But it requires much more time and work. And so is passing info on ship designs.

One of the most difficult tasks in one-winner-only games is overcoming all those weak players that tend to help the stronger to win, instead of trying to win themselves, they play as allies. etc. etc. etc.

I don't see this as an enhancement to games. I see it as another mountain to overcome in game play. But I could be wrong.

[Updated on: Wed, 16 February 2011 13:24]

Report message to a moderator

BlueTurbit wrote on Wed, 16 February 2011 19:16

weaker players pass their h-files to stronger players in exchange for favors.

That kind of "diplomacy" already exists. Some ppl use m-files directly. Tools could simplify the task, allowing different kinds of roles/playstyles to coexist.

Report message to a moderator

Report message to a moderator

FWIW,

I would approve greatly of such a merger tool, and would absolutely prefer it if a way to limit sharing could be configured...perhaps an "unmerger" tool that creates a sanitised .h file to provide to your friend for merging rather than merging the actual .h files.

Remembering .h files need to be maintained, you can't just grab the latest .m file...and for AH at least, unless you give out your AH password only you have access to your .m file(s).

While I see no need to provide a password to make this tool work with AH - the security is in the file management - I have heard rumors that people do actually play outside AH *.

Regarding fears of cheaters getting the encryption via reverse engineering...it is already available to any sufficiently determined & talented cheat. Those who would oppose this tool for fear that it might be easier to extract the encryption from this tool than Stars.exe are giving up liberty in exchange for security.

IMO, there are already more than enough Stars! tools to discredit the "I'm disadvantaged for not using tool X" argument.

Personally I would go further, and have been toying with contacting m.a.stars, Wumpus, PaulCr, LEit and anyone else who has knowledge of Stars! encryption & file formats, with the view of creating a set of libraries in a variety of programming languages to access and modify all of the files in the style of Stars! Host Editor. Done completely enough this would not only enable such tools as the above but could provide connection to alternative clients, automation tools, AIs & clones. * For a layer of security, requiring the user's game password to access files at the API level could be implemented i.e. on file open/save.

I myself have experience with Java and have worked on Stars! Autohost Client - it actually has a plugin system and some partially completed plugins for turn analysis based of the .f & .p files that were never completed.

[Updated on: Thu, 17 February 2011 01:54]

Report message to a moderator