BlueTurbit wrote on Sun, 20 February 2011 11:36

So, with my experience with cheats in several games, put me down as more cautious and suspicious than your average rookie here. Everybody has their own opinions, and right or wrong, these are mine, based on my own experiences with Stars this past decade.

I defer to the experience and wisdom of players who've been around for years, while I can count my time in days.

To take that a bit further, wouldn't Ron hosting a server side app work? Xyli seem's to be holding back a public release.

I wonder if pretty soon, we'll be able to use the SAH server to upload the 3 files, the password and get back updated H files.
(a small change from the current output, which seems to update only the H file for the other player.. or am I reading it wrong?)

Not sure if the bandwidth usage would shoot up for Ron. The files might be small, but 200 players doing it could add up..
I sure hope Ron tries it out for a week

Report message to a moderator

m.a@stars

Any chances of adding an "include just this info" mode? Or a "don't include this info" mode?

I guess it's possible, but would take a bit more work. For example if you'd like to share planets stat (concentrations and habs), but wouldn't like to share planets ownership - tool will have to remove that knowledge in process of transferring planets stat (all that info is stored in one file block, and currently these blocks are transferred with no changes).

Could you give me an examples of what you'd like to be able to export separetly that would be valuable in the non-team games?

Report message to a moderator

nmid

To take that a bit further, wouldn't Ron hosting a server side app work? Xyli seem's to be holding back a public release. I wonder if pretty soon, we'll be able to use the SAH server to upload the 3 files, the password and get back updated H files. (a small change from the current output, which seems to update only the H file for the other player.. or am I reading it wrong?)

Well, I'm still going to relese it (imho, there is no resonable objections except security), but I'd like to make a favor to those who concerned about security. Currently I'm looking for a ways to sort this out, and it will take some time.

If somebody needs to merge h files feel free to PM or mail me, I can merge it for you (but please include some details, so I can check that you are not trying to cheat).

Report message to a moderator

XyliGUN wrote on Sun, 20 February 2011 21:11

Could you give me an examples of what you'd like to be able to export separetly that would be valuable in the non-team games?

Hmmm, lets see:

warmongers exporting 3rd party designs... but perhaps only about certain races, not all they know...
anybody exporting 3rd party (perhaps enemy) data: planets, fleets, minefields... and perhaps wanting to keep their allies' data safe...
someone letting a CA know where to gate its OAs but hesitant to let same CA know where all their small colonies are...
races sorting out whether intersettling is possible by sharing uninhabited planet info... before signing a deal...

There's probably lots more, and the precise filtering of everything would likely require a significantly more complex program than just plain merge, but it could be worth the effort, as it would be addressing a very real shortcoming of Stars! itself.

Report message to a moderator

XyliGUN wrote on Sun, 20 February 2011 21:11

if you'd like to share planets stat (concentrations and habs), but wouldn't like to share planets ownership - tool will have to remove that knowledge

Hmmm, perhaps start with something simpler, like "include just data about this race" or "include just fleet data".

Report message to a moderator

XyliGUN wrote on Mon, 21 February 2011 09:11

Could you give me an examples of what you'd like to be able to export separetly that would be valuable in the non-team games?

I'd base it on a config file with rules for every possible variable(well...as many as possible) with a few psuedo-variables built in to shorten rules a bit where any given rule either evaluated to true(planet.x<500) or is a valid set expression ("planet.others" is invalid when testing whether to share a ship or design, but "planet" would contain all planets)
ie
planets have a position (x,y) an owner, a hab(g,t,r), minconcs(i,b,g) etc
ships have a position (x,y) an owner, a type etc
with each list based on OR
so..for a NAP
whitelist rules - blacklist rules
whitelist:
planet.enemy
#not near me
planet.others.x<500
planet.others.x>1500
planet.others.y<500
planet.others.y>1500
#useless to me
planet.value<-10
#our common enemy
planet.player3
ship.player3
ship.enemy
design.enemy
#show shared border planets (NAP is first in owns its)
planet.mine.x<700 AND planet.mine.x>500
blacklist:
ship.mine
planet.mine

finally...can we have it in sections..whitelist-blacklist for each player so it generates all the custom histories a once

Report message to a moderator

Report message to a moderator

nmid wrote on Tue, 22 February 2011 17:03

Can you merge one game's H file into another game? I guess it might not be possible, so is there a way to tranfer only ship designs from one game to another.

Wow. I should have asked that before. It's been a long-standing wish since forever.

If only it could be possible... players could build "libraries" of their favourite designs, or even of the commonest "enemy" designs...

Report message to a moderator

m.a@stars wrote

Hmmm, perhaps start with something simpler, like "include just data about this race" or "include just fleet data".

This one could be done relatively easy (I'd add it to the "to do" list), but it would be more complex to use, than now.

gible wrote

I'd base it on a config file with rules for every possible variable(well...as many as possible) with a few psuedo-variables built in to shorten rules a bit where any given rule either evaluated to true(planet.x<500) or is a valid set expression ("planet.others" is invalid when testing whether to share a ship or design, but "planet" would contain all planets) ie planets have a position (x,y) an owner, a hab(g,t,r), minconcs(i,b,g) etc ships have a position (x,y) an owner, a type etc with each list based on OR so..for a NAP whitelist rules - blacklist rules ...

This is a nice idea, but I think such customisation is out of the merger scope, it's more looks like a part of something like StarsPlayerAPI, where you have full controll over planets and can filter them by location, ownership and so on.

nmid

Can you merge one game's H file into another game? I guess it might not be possible, so is there a way to tranfer only ship designs from one game to another.

Designs could be easily transferred from one game to another, but there will be a problem with tech level verification, since each design requires specific tech levels. Another problem here is that to add design you will need to modify x file (or m + hst files).

m.a@stars wrote

Wow. I should have asked that before. It's been a long-standing wish since forever. If only it could be possible... players could build "libraries" of their favourite designs, or even of the commonest "enemy" designs...

Again, designs library sounds great, but it looks like a part of something more complex than just merger.

Report message to a moderator

XyliGUN wrote on Thu, 24 February 2011 20:17

Another problem here is that to add design you will need to modify x file (or m + hst files).

Uh oh. Even for "foreign" designs?

Report message to a moderator

Currently several peoples in a couple of SAH games are using merged history files (tool isn't released, I only merge files on my side), I guess I'll treat that as merger beta testing (everybody is welcome to join). Any comments are welcome.

Report message to a moderator

It works quite nicely.
Just wish I could get others to use it as much as I do

When will you take it to the next level.

Report message to a moderator

Report message to a moderator

[Updated on: Mon, 28 February 2011 11:33]

Report message to a moderator

Report message to a moderator

Report message to a moderator

Was just going through this thread again and came across this.

XyliGUN wrote on Sat, 19 February 2011 01:23

Wow! While answers like that was expected, I'm still surprised... so much surprised. BlueTurbit Steal? Freudian slip or wolf in sheep's clothing? When passwords get involved in such a tool I already have suspicions. It's just a word. I was trying to show that you cannot take any information from the m/h file untill you know password. Yes I can get any information from the m/h files without password, but merger do password veification, just because I'd like to avoid situation where playing host, having access to m files, can export all the data into his own h file. That's the reason to verify password. And I guess it's resonable. Also you don't have to provide your password to your teamamte to merge your h file, instead your teammate can give you his h file and you will merge info into it and then return h file back.

So, I finally understand why you are using the current method of the password usage.

Quote:

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).

This means I first mail the other player my H file.
When it will get released, he will then have to use merger with his m file, h file, my h file and his password.
and then mail it back
Lot of to-and-fro.

However, Can't I simply ask for the H file data from someone and update my own h file?
I get the H file from him.
I merge it myself.
Only 1 exchange.

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

This is better than your original approach as I can just have to give my password to update my H file.
I can't get hold of the other player's H file data, even if I'm a playing host.

And the best thing, people who don't want to give out their passwords, will not have a problem giving out their H files, so "I" can get my updated H file.

Report message to a moderator

Report message to a moderator

XyliGUN wrote on Thu, 10 March 2011 14:37

Agree, but IMHO, real solution is in another of my posts: XyliGUN wrote It just comes to my mind, that while history merger is mostly intended to be used by players on their side (to be used by host it needs to have your h files, that it wouldn't normally have), it can make it simplier to use it on server side by wroting a turn merger, which woudn't need to have your h file at all and would only merge m files knowledge right after generation, so it will be sort of "share knowledge" feature for SAH, which gives player possibility to ask SAH to share his knowledge with selected player. In that case you will receive m file that already contains all data merged. In that case it will be extremly easy to use.

Well, I'll have to refer to another of my posts

nmid wrote on Sun, 06 March 2011 19:25

...........no offence meant, but I don't think that server option will be out soon. Cutting to the chase, can you make merger.exe available (either directly or online utility).. and when ? It's a fantastic tool that you've created and I would really want to start using it in 2 of my games, which will be coming into the information exchange mode really soon..........

and to paraphrase a mail I wrote.. it's like showing water to a thirsty man in a desert and not letting him drink

Report message to a moderator

XyliGUN wrote on Thu, 10 March 2011 10:07

Agree, but IMHO, real solution is in another of my posts:

Since there's legitimate privacy and usability concerns, why not do it in a way more similar to what Stars! already does?

1st, export h-file data in a text-readable format, like Stars! own Reports are exported and readable/editable.

2nd, edit, share, or handle said data in the desired way.

3rd, import received data into own h-file.

This approach, while it would need a recoding of the merger tool, would fix both privacy and security issues, as well as allowing each player to select what they want to share and/or import, freeing the tool itself from such complexity.

Also, a similar tool could perhaps be created to export/share selected m-file data not currently available from Stars! own reports.

Report message to a moderator

m.a@stars wrote on Thu, 10 March 2011 19:53

XyliGUN wrote on Thu, 10 March 2011 10:07 Agree, but IMHO, real solution is in another of my posts: Since there's legitimate privacy and usability concerns, why not do it in a way more similar to what Stars! already does? 1st, export h-file data in a text-readable format, like Stars! own Reports are exported and readable/editable. 2nd, edit, share, or handle said data in the desired way. 3rd, import received data into own h-file. This approach, while it would need a recoding of the merger tool, would fix both privacy and security issues, as well as allowing each player to select what they want to share and/or import, freeing the tool itself from such complexity. Also, a similar tool could perhaps be created to export/share selected m-file data not currently available from Stars! own reports.

That sounds really cool and I feel a bit guilty at all the work we are dumping on Xyligun, but then again, he gets all the thanks and credit too

However m.a., I was wondering, your method still doesn't address the problem of security of the stars executable (w.r.t. decryption).
The new exporter/merger will still not be releasable to the public, just like the current merger.exe.

Report message to a moderator

nmid wrote on Thu, 10 March 2011 15:33

That sounds really cool and I feel a bit guilty at all the work we are dumping on Xyligun, but then again, he gets all the thanks and credit too

I hope the "indirect" approach is easier to code than a full-fledged filtering-mergering tool, while also allowing for full player control about what and when and how gets shared.

Quote:

your method still doesn't address the problem of security of the stars executable (w.r.t. decryption). The new exporter/merger will still not be releasable to the public, just like the current merger.exe.

Alas, no, but at least everyone's h-files shouldn't need to be shared around.

Report message to a moderator

ma.stars wrote

Since there's legitimate privacy and usability concerns, why not do it in a way more similar to what Stars! already does? 1st, export h-file data in a text-readable format, like Stars! own Reports are exported and readable/editable. 2nd, edit, share, or handle said data in the desired way. 3rd, import received data into own h-file.

ma.stars, the key problem of your proposal is usage complexity - it adds more manual work to the player, and this is exactly what I'm trying to avoid, that's why I start thinking of server side merger for m files. You should just have fun, all other boring work should be done by game or/and server. So, the idea is to have a sort of checkbox ("share vision") on AH, which says share my knowledge with players X, Y and Z. So, you will have more fun, but no additional manual work, at all. Peoples don't actually like complexity, especially if there is already a lot of other complexities.

[Updated on: Thu, 10 March 2011 16:08]

Report message to a moderator

XyliGUN wrote on Thu, 10 March 2011 20:20

ma.stars, the key problem of your proposal is usage complexity

You mean when sending a textified h-dump instead of the original binary h-file? Or when reading/editing a text file instead of trying to guess/control what's inside an encrypted binary?

Quote:

the idea is to have a sort of checkbox ("share vision") on AH, which says share my knowledge with players X, Y and Z. So, you will have more fun, but no additional manual work, at all.

Except when you want/need to control what's actually shared. Current Stars! infodumps already allow that, with no added complexity and no need for extra options either at AutoHost or inside Stars! itself.

Leveraging what already exists instead of trying to duplicate it still seems like the easiest/best option to me.

[Updated on: Thu, 10 March 2011 17:49]

Report message to a moderator

XyliGUN wrote

ma.stars, the key problem of your proposal is usage complexity

ma.stars wrote

You mean when sending a textified h-dump instead of the original binary h-file? Or when reading/editing a text file instead of trying to guess/control what's inside an encrypted binary?

No, I mean the need to send any files (doesn't matter is it h or txt file) and the need to use any additional tool.

XyliGUN wrote

the idea is to have a sort of checkbox ("share vision") on AH, which says share my knowledge with players X, Y and Z. So, you will have more fun, but no additional manual work, at all.

ma.stars wrote

Except when you want/need to control what's actually shared. Current Stars! infodumps already allow that, with no added complexity and no need for extra options either at AutoHost or inside Stars! itself.

That's correct it is already allowed, but the complexity I'm talking about is in the way it allowed - you have to export data into the text file, probably import it into excel, remove what you want to hide, save, send to someone, he than have to import it into some third party tool, analyse, switch to Stars! and use the new knowledge to make his turn... Just compare to my suggestion - once implemented you'll go directly to the last step.

ma.stars wrote

Leveraging what already exists instead of trying to duplicate it still seems like the easiest/best option to me.

Reinventing the wheel almost always is a bad idea, but if we can minimize complexity (instead of adding it with new tool(s)) we should do it.

PS: I'm still think that client side merger should be published, but server side merging would be a real solution, which adds value with no additional work.
PS2: Remember lazyness is everywhere and it's one of the reasons Stars! looses its' players.

Report message to a moderator