PricklyPea wrote on Sat, 04 March 2006 20:33

Simplest way to cheat is to play 2 players in a single game.

Can be as well detected unless cheater submit from two computers. Cheater has to play 2 races quite good, that takes time. Also result of 200% power can no way be compared with effect of having 2% fleet cost.

Report message to a moderator

Kotk wrote on Sat, 04 March 2006 15:51

PricklyPea wrote on Sat, 04 March 2006 20:33 Simplest way to cheat is to play 2 players in a single game. Can be as well detected unless cheater submit from two computers. Cheater has to play 2 races quite good, that takes time. Also result of 200% power can no way be compared with effect of having 2% fleet cost.

well with 2 races that are built to complement each other, you would have an advantage in RW points too.

Report message to a moderator

Kotk wrote on Sat, 04 March 2006 18:41

PricklyPea wrote on Sat, 04 March 2006 15:47 I can't imagine somebody wanting to cheat would go to the trouble of using a more complex and sophisticated method. The existing ways to cheat are not so numerous and not so profitable. Skill makes more difference than cheating there. Lets see what can be done by modifying the x# files? As i understand hacking "split fleet" and/or "manual transfer" there are infinite minerals and infinite fuel cheats. By editing "modify design" and/or "set queue" records there old "fixed" cheap orbital and cheap ship cheats can be made back. One can target fleets he does not see (by ID) so probably with clever hack of "waypoints" one can track down everything that comes sneaking his way. Then ... eyeball "race record" about opponent in CA m# file. For rest of PRT-s its only icon and name ... to CA goes full info about race and its research progress there?

The detail isn's nearly that great; some info gets sent, but by no means all. Well, most of the race info is sent, but the majority is filled with placeholder data.

Quote:

I have not tested if one can for example do cheap bases cheat simply by using JRC3 in JRC4-hosted game ... but rest of these are hacking only cheats and very powerful.

AFAIK the cheap bases trick still works in JRC4 without the need to hack the X file.

Quote:

So ... thats what i only think is bad there. Probably lot more. Do we want to write something that checks and alerts about all these and probably other cheats?

"we" (?) - or at least I ;P - have already have been working on just that. There are stumbling blocks unfortunately in working out what is *supposed* to occur with some orders in the X file. (=> my earlier post regarding this in this thread).

Report message to a moderator

wumpus wrote on Thu, 02 March 2006 20:15

wumpus wrote on Sun, 26 February 2006 21:25 ETA would probably be a couple of weeks, mind you - I'm still entirely too busy with real life I've let it loose on the #stars! denizens for some semi-limited beta testing; it looks resilient and stable enough at first glance though, so hopefully I'll publicise the URL on Sunday evening or so

Start-of-thread post updated accordingly Enjoy.

Report message to a moderator

wumpus wrote on Sat, 04 March 2006 23:46

AFAIK the cheap bases trick still works in JRC4 without the need to hack the X file.

Yep, just tested, fully functional! Sorry, i had impression it was fixed in JRC4.

Quote:

"we" (?) - or at least I ;P - have already have been working on just that. There are stumbling blocks unfortunately in working out what is *supposed* to occur with some orders in the X file. (=> my earlier post regarding this in this thread).

Yes i read it... maybe dune down your accuracy. Check if transfered was lot more than there was (say 50 units more). Splitting oddities are 1 unit here and there.
Actually it was slightly unclear how far you are with it, if you want any aid or no. Maybe you want someone to produce test cheat files or something?

Hmm... did some tests ... 2 of 3 tried hack cheats (not related to minerals or modifying half built designs) worked.

Report message to a moderator

wumpus wrote on Sat, 04 March 2006 23:46

The detail isn's nearly that great; some info gets sent, but by no means all. Well, most of the race info is sent, but the majority is filled with placeholder data.

What placeholder data? I see CA gets full thing. Seems to be copy of the record in HST file.

Probably we can make tool that showels rest of it beside habs into 3% growth humanoid record taken at turn 0? Then it will be placeholder data. Otherwise CA knows too lot.

Report message to a moderator

Kotk wrote on Sun, 05 March 2006 04:32

Yes i read it... maybe dune down your accuracy. Check if transfered was lot more than there was (say 50 units more). Splitting oddities are 1 unit here and there.

This isn't as easy as all that, since the small (1-2kT) errors at one point can blow out quite a bit if you have a succession of orders concerning the same fleet.

Quote:

Hmm... did some tests ... 2 of 3 tried hack cheats (not related to minerals or modifying half built designs) worked.

Hmm, depends what you're trying/doing Maybe send me a private message or (even better) email (das.wumpus@gmail.com) and I'll let you know if I've already covered it and/or it's easy to do. The main areas I've covered are some movement tricks and some obviously dodgy cargo transfer tricks.

Report message to a moderator

Kotk wrote on Sun, 05 March 2006 05:16

wumpus wrote on Sat, 04 March 2006 23:46 The detail isn's nearly that great; some info gets sent, but by no means all. Well, most of the race info is sent, but the majority is filled with placeholder data. What placeholder data? I see CA gets full thing. Seems to be copy of the record in HST file. Probably we can make tool that showels rest of it beside habs into 3% growth humanoid record taken at turn 0? Then it will be placeholder data. Otherwise CA knows too lot.

The "usual" case seems to be that the CA gets only the hab data, as it should be (well, ok, one can argue that they shouldn't get even that, but it's 'always' been that way - and observable in the normal stars! GUI without fiddling with the files). The other info in the race record gets filled with a bunch of nonsense (eg 0% growth).

Having said that: I do seem to remember having seen examples such as you describe - IE, where the CA's M file contained much more information on the other races. I don't think I currently have any examples of this, though, and it's not at all clear what might cause it (possibly the stars! version used to gen? I've been using jrc4 for a fair while now).

Hmm

Report message to a moderator

wumpus wrote on Sun, 05 March 2006 09:57

Having said that: I do seem to remember having seen examples such as you describe - IE, where the CA's M file contained much more information on the other races. I don't think I currently have any examples of this, though, and it's not at all clear what might cause it (possibly the stars! version used to gen? I've been using jrc4 for a fair while now).

Oh i now see it... my fault. The M file where i observe it is some battlesim. I do use that battlesim rarely and do not test CA never (so i did not submit with CA) there is CAs m info for over 200 turns in it. Probably the turn info that i looked into was genned ages ago when i still used JRC3. I also observe placeholder now what you describe. PRT HE, LRTs none, growth 0% etc. Worthless.

Report message to a moderator

wumpus wrote on Sun, 05 March 2006 08:39

This isn't as easy as all that, since the small (1-2kT) errors at one point can blow out quite a bit if you have a succession of orders concerning the same fleet. <snip> The main areas I've covered are some movement tricks and some obviously dodgy cargo transfer tricks.

As far as I understand it, the "cargo" cheat means minerals/pop appear from nowhere, i.e: there's no way they could be there based on what was previously there, right?

So, one possible way to tackle it would be:

- For every fleet (or group of fleets in the same coordinates, or even planets under them) which carries cargo, check if their pop/minerals have changed from what was stated in the m file.
- For those with changes, check all possible sources in the same coordinates (including packets, salvage, and foreign fleets/planets for minerals, and own ones for pop) and see if the totals tally.

The whole point being that if there were, say, 1000 kT of Iron in a fleet at (1234,2314) and nil in all other fleets/planets/packets/salvage at the same place/time, no matter how they split/join or interact, there's no legit way the Iron total can change for these coordinates, unless you delete a fleet design, of course, but that's not (yet) a cheat. This would even cover the "uploading minerals to bombers" cheat.

Perhaps there's practical difficulties to this approach, or more sophisticated cheats on the matter that I'm not aware of, but, if that's the case, please enlighten me.

Report message to a moderator

m.a@stars wrote on Mon, 06 March 2006 13:54

- For every fleet (or group of fleets in the same coordinates, or even planets under them) which carries cargo, check if their pop/minerals have changed from what was stated in the m file.

Opponent fleets or planets cargo is not present in m file unless you got robber baron or pick pocket. The result of transfers is not in x file. There are commands like A transfers something to B and so on. Problem is that some transfers are not checked if they were possible and are silently carried out by turn generator. Thieves may spread away from that particular spot with waypoint 1 transfer orders ... so when turn is genned its too late to figure who of them cheated and where. Only way is to check each particular transfer for its possibility when its done.

m.a@stars wrote on Mon, 06 March 2006 18:41

You should see some of my JoaT turns.

I have seen SD player quit from large game because he said that each time his turn was way over 10k big it hit some size limit somewhere. Unclear if it was his browser, ISP or AH. AH displayed his turns but later considered corrupt and nothing was processed. Found himself a more lazy replacement.

[Mod edit: fixed quote]

[Updated on: Tue, 07 March 2006 17:01] by Moderator

Report message to a moderator

Kotk wrote on Mon, 06 March 2006 17:50

m.a@stars wrote on Mon, 06 March 2006 13:54 - For every fleet (or group of fleets in the same coordinates, or even planets under them) which carries cargo, check if their pop/minerals have changed from what was stated in the m file. Opponent fleets or planets cargo is not present in m file unless you got robber baron or pick pocket.

I was afraid of that.

Quote:

Only way is to check each particular transfer for its possibility when its done.

So, the turn-sanitizer needs to check mineral/pop availability from the m file of every player who had anything at the same coordinates where a transfer order was given?

Total sum before and after would still need to be the same. So, it would seem more work, yes, but not essentially harder work.

Report message to a moderator

Report message to a moderator

I've just been playing with your BattleSim - it's great .

One little problem for me though - I'm wanting to do some battle tests for a duel I'm in where I'm playing AR with RS and without NRSE, so none of the races quite fit that (Race 16 comes closest, but that's a WM).

I know it's not possible to cover every case with 16 races, so I'd like to second the request below:

Micha wrote on Mon, 27 February 2006 21:50

So my *ahum* request would be: could you make an online utility that allows you to just upload any .hst file and fix it to the right tech levels? At first global techs, but per race would even be better of course.

Then I could design a .hst with an approximation of the correct races (at least as far as PRT/IFE/NRSE/RS goes, the rest doesn't matter so much, except I'm not sure if BET and CE affect costs for targetting), and not go through the tedious business of setting the techs.

Of course, a custom .hst file would not have the MT parts, and getting those is even _more_ tedious (I'm assuming that the starting file has those, rather than you catching them in the generation).

Report message to a moderator

Report message to a moderator

Report message to a moderator