XyliGUN wrote on Fri, 11 March 2011 00:43

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.

Ahh, yes, for the unrestricted sharing simplest would be best.

XyliGUN wrote

you have to export data into the text file, probably import it into excel, remove what you want to hide

For most removals of sensitive data just any text editor will do, as you'd be snipping whole lines of text. Excel is for the special cases where you want to sort things or remove columns. Remember the Jeffs used excel-format for their textified infodumps in large part to allow that kind of thing.

Quote:

save, send to someone,

Well, that's what will be needed for sharing h files too, at least until a server-side option is added.

Quote:

he than have to import it into some third party tool, analyse,

All simple point-and-click operations, certainly much simpler than operating Stars! GUI itself.

Quote:

switch to Stars! and use the new knowledge to make his turn...

That'd be the complex part, and why direct h-file merging would be really neat.

Quote:

Just compare to my suggestion - once implemented you'll go directly to the last step.

Once implemented...

Compare with my suggestion: most flexibility and control with a mimimum of fuss just with a change of intermediate format. Something Stars! itself does, so every player should be already familiar with it.

Plus, you'd be opening the door to improved 3rd-party tools, somehing always interesting!

Quote:

if we can minimize complexity (instead of adding it with new tool(s)) we should do it.

Well, you yourself admitted that filtering h-file data by race or category would need a fairly more complex tool, and even that wouldn't give complete control over what's actually shared / merged in.

Plus, this is Stars! not tic-tac-toe. Some complexity is already part of the user experience.

Quote:

client side merger should be published, but server side merging would be a real solution, which adds value with no additional work.

non-disclosure would be another point for server-side merging, at least until security ceases to be a concern.

Report message to a moderator

Report message to a moderator

Spionage, deception, sabotage... a whole new game!

Report message to a moderator

Ron wrote on Fri, 11 March 2011 21:46

Hmmm, hows this for a can of worms? Create a .pla report file in Stars!, edit with any text editor you like to remove or alter any data you like, send to teammate or ally, who then uses a third-party tool to merge the .pla file with their .m/.h files. Open in Stars! to view.

m.a@stars wrote on Fri, 11 March 2011 22:12

Spionage, deception, sabotage... a whole new game!

Exactly...
I like the concept of adding .pla files into my .m file but it's abusable in a different way, that I am uncomfortable with as a player.

Adding .pla files into .m files would lead to misleading info.. and I have a strong initial hesitation to this method.

I can imagine some pretty misleading universe maps coming out, if that utility comes out.

The current method could give rise to security problems, but I was pining my hopes down to various alternatives (server side processing etc) that were being spoken about, to take care of it.

@Ron, Could I ask, if that's going to be an option in the near future? (The .h file merger utility.)

Report message to a moderator

Report message to a moderator

Report message to a moderator

[Updated on: Sat, 19 March 2011 17:22]

Report message to a moderator

XyliGUN wrote on Sat, 19 March 2011 11:20

Once you can see a fleet that you normally can't (only your teammate can see it) you will be able to target/follow him, which impossible in case it invisible for your scanners.

That would be a really nice improvement for Team games, once everyone has access to the tool, of course.

Report message to a moderator

m.a@stars wrote on Sat, 19 March 2011 16:21

XyliGUN wrote on Sat, 19 March 2011 11:20 Once you can see a fleet that you normally can't (only your teammate can see it) you will be able to target/follow him, which impossible in case it invisible for your scanners. That would be a really nice improvement for Team games, once everyone has access to the tool, of course.

I'm a staunch supporter of the .h file merger, but the .m file merger gives me pause.

I like the fact that I can see wormholes that my starting scanners might have missed. Even information of battles, perhaps.
However the ability to see fleets is a mixed blessing.

Information that I would normally welcome, but not the ability to target fleets.
That ability is messing with the game dynamics or in other words, gives a game advantage which goes beyond simple information exchange (aided by the .h file merger).

Consider 3 races.
SS, ally of SS and a target race.
A regular SS scout (upto 2430) is 75% to 88% cloaked. If placed within the 45/67 LY pen-scanning distance of the 'target race' planet, once a .m merger is done, then the "SS ally" could easily target ships, much beyond their own pen-scanning abilities.
The 'target race' normally would require only a 100LY scanner to protect against "SS ally" targeting [scouts within 67LY, even if the "SS ally" are using transferred 88% cloak scouts (which would loose their 75% inbuilt SS cloak). (5 Chameleons on FF + Stealth Shields)] ... but with an SS scout and 88% cloaks and 67LY scanning, it would require 560 LY scanners... more than a Cheetah Scanner with NAS. Only a Scoper 280(and beyond) with NAS would work.

Even if you do not consider SS cloaked ships, "target races" currently know that if there are no enemy scouts around, then their orbiting fleets can't be targeted.
If the fleet information is shared, then no such security would exist, even if one scout is in the vicinity.

Sounds minor, but I can think of multiple instances where 2 allies (with NAS and another with pen-scanning) can use this new feature to keep tabs on ship enemy ship movements.

Report message to a moderator

Report message to a moderator

nmid wrote on Sat, 19 March 2011 14:16

Sounds minor, but I can think of multiple instances where 2 allies (with NAS and another with pen-scanning) can use this new feature to keep tabs on ship enemy ship movements.

It might sound minor, but I think the inability to share targets is a major limitation of the game engine, severely handicapping Alliances and Teams.

Report message to a moderator

m.a@stars wrote on Sun, 20 March 2011 01:36

nmid wrote on Sat, 19 March 2011 14:16 Sounds minor, but I can think of multiple instances where 2 allies (with NAS and another with pen-scanning) can use this new feature to keep tabs on ship enemy ship movements. It might sound minor, but I think the inability to share targets is a major limitation of the game engine, severely handicapping Alliances and Teams.

You misunderstand me.
I do not think it's a minor ability, but a really powerful ability.
I just said, it will change game dynamics, unlike the simpler (relatively) .h file merger.
I gave a rather long-winded example of it as well.

Of-course players will get used to it over time, like chaff and other new "features" discovered in the past.. only this is one of our own making.

ps - I really seem to be using the word "features" a lot, these past few threads :s

Report message to a moderator

m.a@stars wrote on Sun, 20 March 2011 09:06

nmid wrote on Sat, 19 March 2011 14:16 Sounds minor, but I can think of multiple instances where 2 allies (with NAS and another with pen-scanning) can use this new feature to keep tabs on ship enemy ship movements. It might sound minor, but I think the inability to share targets is a major limitation of the game engine, severely handicapping Alliances and Teams.

It comes up everytime the clone builders ask what features should we add?

All or nothing info sharing would be perfect for team games & no-allies games.

Graduated info sharing is much harder but the ideal outcome. I suspect to achieve that properly we'd have to start adding to the user interface - and by extension the .x files - somehow. Its been done before, I see no reason to be shy about doing it the Stars!. Just have to be careful how we do it.

Report message to a moderator

nmid wrote on Sat, 19 March 2011 21:13

You misunderstand me. I do not think it's a minor ability, but a really powerful ability. I just said, it will change game dynamics,

I understood you. But it happens that particular change would be a very welcome enhancement.

Report message to a moderator

m.a@stars wrote on Sun, 20 March 2011 11:31

But it happens that particular change would be a very welcome enhancement.

A welcome enhancement, yes, but since it is a major enhancement it should not be introduced without the agreement of all players or noted in the game setup so the players know in advance it will be there. In addition, it should be available to all players.

Of course, that's just my opinion, but I hope that opinion is shared by the majority of Stars! players.

Report message to a moderator

craebild wrote on Sun, 20 March 2011 11:44

noted in the game setup so the players know in advance it will be there. In addition, it should be available to all players.

Of course!

Report message to a moderator

[Updated on: Sun, 20 March 2011 10:56]

Report message to a moderator

XyliGUN wrote on Sun, 20 March 2011 20:25

OK, here is an update - m files merger is ready. It's not yet been extensivly tested, but so far it works well on 25 turn pairs I've tested it with. Features: 1* Merging planets stats, like concentrations, original/actual values, planet owner, starbase design (you will see the planets that you didn't yet scanned, but your teammate(s) did) 2* Merging known designs (you will see the same designs that your teammate(s) can see including his existing designs and enemy designs known to him) 3* Merging minefields info (you will see the same minefields as your teammate(s)) 4* Merging progress timelines and current scores/rank (you will see your and your teammate progress timeline in your turn, like if PPS were enebaled for your team) 5* Current version dosn't gives you any advances like fleets/wormholes targeting/following discussed above. It has very close feature set to what h files merger have. The main reason of m files merger creation instead of h files merger is actually to make it less complex to use (you don't need to have your teammate h file, and you also don't need to create your own h file to start merging) and hopefully to make it easier to implement server side merging. Usage: StarsTurnMerger.exe game.mX game.mY passwordX where: game.mX - source m file game.mY - target m file passwordX - password from game.mX If somebody wants to see merged turns, you are welcome to send me your m files to merge and the password and I'll send you merged m file. PS: I'll do experiments with fleets/wormholes/battles merging a bit later, but these "features" are under question on whether they are legal.

I would rather continue using your .h file merging offer. It's tough enough to convince people to give their .h files and passwords, even when I tell them you are a Stars VIP


Point 3 and 4 are advantages of .m file over .h file, but I dread to think the effort it will take for actual game files, especially if fleet/wormholes/battles are still not merged (point 5).
The main advantages of fleet and planet merging (point 1 and 2) are well satisfied with the .h file merger.

Nmid.
Happy Beta tester.

Report message to a moderator

craebild wrote on Sun, 20 March 2011 16:14

A welcome enhancement, yes, but since it is a major enhancement it should not be introduced without the agreement of all players or noted in the game setup so the players know in advance it will be there. In addition, it should be available to all players.

A valid solution.
I look forward to using it, as long as everyone knows about this feature, and everyone can use it.

I just wonder how it will be implemented server side. (and when.. I assume it will take a lot of coding changes and effort by Ron to get it working... the .h file merger has still not happened).
That would mean that loads of people would ask for Xyligun to do .m file mergers (for all 5 points), which doesn't seem practical.

Looking forward to a server side solution, that will automatically indicate to players, that the merger option is an option.

Ps - I would suggest that information on who's merging .m files be undisclosed. Makes for more interesting subterfuge,diplomacy and game-play

Report message to a moderator

Report message to a moderator

Report message to a moderator

gible wrote on Mon, 21 March 2011 01:26

Just curious, but... 1) why one-directional merging? 2) What happens when you try m1+m2 and then m2+m1? 3) What happens when you try m1+m2 and then m2+m3? Does m3 end up with info from m1?

Question 1 > I could think of 2 answers, but I'm just guessing.. perhaps it's easier to code or perhaps to keep the password part simple?

Question 2 > From what I understood of .h file merging, M2 gets updated with M1 file. Then when you do M2+M1, M1 will take only new information, while keeping the source information (on M1) as the more genuine source.

Question 3 > Yup.. exactly the problem I am facing, when I don't want to reveal my ally's information, but want to trade information with another party anyway.

With .h file merging, I guess you can still take care of, by keeping an independent copy of just your .h file and .m file data.

Year 2420 - Game.m1, game.h1
Year 2421 - Game.m1, game.h1, game.m2, game.h2
merged h1 and h2.. and got game.h1a, game.h2a
(adding a for clarity sake)
Year 2422 - game.m1, game.h1a, game.m2, game.h2a, game.m3, game.h3
Now if I (P1) want to exchange information with player 3, I will have to keep my game.h1(2421), make a copy in a new folder, open year game.m1(2422) and get an updated game.h1(2422) which will be used to create the updated game.h3a(2422) file.

For getting my own updated file game.h1b(2422), I would use game.h1a(2422) and game.h3(2422) when you merge his data into yours.

Damn messy... and requires both parties to make efforts to keep each other's data secure. I doubt everyone would.

@Xyligun, you would need to confirm all this though

Report message to a moderator

Report message to a moderator

nmid wrote on Sun, 20 March 2011 23:28

I would rather continue using your .h file merging offer. It's tough enough to convince people to give their .h files and passwords, even when I tell them you are a Stars VIP

hmm... irrelevant comment as they have to give your .m file in either case.
A brain-fart.

Quote:

Usage: StarsTurnMerger.exe game.mX game.mY passwordX where: game.mX - source m file game.mY - target m file passwordX - password from game.mX How it works? It reads data from specified source & target m files, merges it and write result into the target m file.

Btw, a question about your .m and .h file merger..
Won't the .m file merger give you only the last turn's scouting information?
When you open a .m file without a .h file, you don't get to see all the past scanned planets.
So I'm guessing when you merge a .m file, one will be merging only the planets seen in the turn.
With fleets/wormholes/battles not being merged, the .m file will currently give you only the PPS option additionally, but lesser planet information as compared to a .h file merger.
Correct?

Report message to a moderator

Report message to a moderator