Home » Stars! 2.6/7 » The Bar » Possible new utility for creating testbeds
| | | | |
Re: Possible new utility for creating testbeds |
Wed, 25 February 2009 19:37 |
|
PaulCr | | Chief Warrant Officer 3 Stars! V.I.P
| Messages: 187
Registered: February 2007 Location: An Island that kinda look... | |
|
m.a@stars wrote on Thu, 26 February 2009 00:18 |
PaulCr wrote on Wed, 25 February 2009 23:01 | It would be possible to have to utility post a message to a webserver giving details of the game that has been edited and the player number doing the editing and only saving the file after that as taken place.
|
And even that could be foiled.
|
It could, If I was to try I'd probably modify the hosts file to change the server address it going to to go to 127.0.0.1 instead, but that could be foiled by using an SSL certificate on the server which the app checks.
m.a@stars wrote on Thu, 26 February 2009 00:18 |
Quote: | The only real secure way I can come up with would be to have a webserver to do the actual editing and for it to keep a log which is publicly available.
|
What if there's more than one webserver?
|
The app would only send the files to a single server, and even if they were redirected elsewhere the server it's redirected to won't be able to change them since it won't have the decryption code to do so anyway. I was thinking of the app sending the xy, m and x file to stars.atlantissoftware.co.uk along with a file containing details of what it wants doing, the server does the changes and sends the modified version and then updates a page on the server that people can look adding a line along the lines of ChupaCabras (Player 1) in the Game Glacier 2 (GameID 123456), Year No 2492 used the production queue editor on 26 Feb 2009 at 00:30
m.a@stars wrote on Thu, 26 February 2009 00:18 |
Only a robust x-file sanitizer protecting the game server itself guarantees fairness.
|
Autohost presumably can't run a .net app, I guess Mono might allow it too but I've never actually tried it, I've not even used Linux for nearly 10 years. Even if Mono could run it it would be quite an hassle for Ron to install it and modify his pages to use my app to do the checking.
Report message to a moderator
|
|
|
Re: Possible new utility for creating testbeds |
Wed, 25 February 2009 19:44 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
PaulCr wrote on Thu, 26 February 2009 01:37 |
It could, If I was to try I'd probably modify the hosts file to change the server address it going to to go to 127.0.0.1 instead, but that could be foiled by using an SSL certificate on the server which the app checks.
|
No place like 127.0.0.1 !
Quote: | The app would only send the files to a single server, and even if they were redirected elsewhere the server it's redirected to won't be able to change them since it won't have the decryption code to do so anyway. I was thinking of the app sending the xy, m and x file to stars.atlantissoftware.co.uk along with a file containing details of what it wants doing, the server does the changes and sends the modified version and then updates a page on the server that people can look adding a line along the lines of ChupaCabras (Player 1) in the Game Glacier 2 (GameID 123456), Year No 2492 used the production queue editor on 26 Feb 2009 at 00:30
|
Essentially, turning that second server into an integral part of the initial game server.
Quote: | Autohost presumably can't run a .net app, I guess Mono might allow it too but I've never actually tried it, I've not even used Linux for nearly 10 years. Even if Mono could run it it would be quite an hassle for Ron to install it and modify his pages to use my app to do the checking.
|
First, get the x-file sanitizer working. There'll be time (and plenty volunteers) for porting it to Linux/Unix afterwards.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: Possible new utility for creating testbeds |
Thu, 26 February 2009 12:35 |
|
PaulCr | | Chief Warrant Officer 3 Stars! V.I.P
| Messages: 187
Registered: February 2007 Location: An Island that kinda look... | |
|
[email | m.a@stars[/email] wrote on Thu, 26 February 2009 00:07]gible wrote on Wed, 25 February 2009 22:41 | we'd just have to trust Paul .
|
Or even better, trust the x-file sanitizer.
Make no mistake, this could be an arms race. It's been a long long time since the ante was upped in tools. Excel is still the main caliber being used. But the game itself needs a good jolt to avoid stagnation, so if we can keep the worst cheats at bay, I'd say go for it. Experiment. Come up with mm tommy-guns. Bring Kandinsky and Dali to Universe Creation. Make this old beast the #1 strategy game again, bar none.
|
I've just thrown together a test x file checker and put it on the website at http://stars.atlantissoftware.co.uk/StarsSupremacyHost.zip
The DLL has settings to allow or disallow each check for each individual player, the sample exe that comes with it though uses the default of disallowing them to every player. At the moment I'm only processing the x file, not the hst, there are 2 checks in the DLL that check any new designs created, they are
Allow22OrMoreSuperlatinumInASlot
AllowTenthStarbaseSlotToBeUsed
The first stops you building a spacedock with more than 21 Superlatinum, it should also work against an edited exe that changes ship or starbase hull configurations as well
The second stops a player from creating a design in the 10th starbase slot, it only needs setting for the final player to avoid the turn gen bug but the host might like to give everyone the same limitation, I expect most games would probably leave it off.
The checker uses the final design you enter to perform the check, ie if you create a dock with 24 superlatinum but then edit to reduce it to 21, even though both still appear in the x file, when the x file is processed the edited design replaces the first before the check takes place so you don't end up getting spurious error messages.
The DLL return an empty string if OK or an error message to display to the user, it is up to whatever calls the dll to decide what to do with the x file.
I'm going to need game files in which cheating takes place to add any more checks to the dll.
[Updated on: Thu, 26 February 2009 12:40] Report message to a moderator
|
|
| | | | | | |
Re: Possible new utility for creating testbeds |
Fri, 27 February 2009 06:02 |
|
PaulCr | | Chief Warrant Officer 3 Stars! V.I.P
| Messages: 187
Registered: February 2007 Location: An Island that kinda look... | |
|
[email | m.a@stars[/email] wrote on Fri, 27 February 2009 10:36]PaulCr wrote on Thu, 26 February 2009 23:49 | if you make a change and change it back it is still considered as the starbase being modified
|
Shouldn't that be allowed?
|
The problem is that stars puts all the changes in the x file even when there is no net change, the app loads the hst file dragging out all the designs and then processes the x file replacing each design as it meets them and marking any it replaces as dirty, this means the last design in the x file is always used but it is marked as replacing the original even if it hasn't changed.
That is probably the way stars does it although it won't need the dirty flag, it probably does the same thing with production queues which is why I doubt my build starbase the same year will work. It's certainly the way I've done it in this which I've started coding with the eventual aim of being a turn generator, hence the app name, it automatically means that my create starbase first year won't even work in my own generator since the planet won't be colonised when it tries to change the production queue so it just gets thrown away.
To allow it not to complain when you replace the base with the same design it will need to keep a copy of all 160 bases and then check every single slot in them for a change after the x file has finished loading, it could be done if it turns out to be a problems and that might even allow the base to have stuff removed to build it quicker without penalty since that actually leads to a loss of resources and minerals but an easier way to handle it would be to rip all the design changes to the partially completed base and present the modified x file back to the user.
[email | m.a@stars[/email] wrote on Fri, 27 February 2009 10:36]
Quote: | The 3 I've come across have now been added, I'll need files and an explanation of the bug for any others that need fixing since I don't fancy spending hours trying to replicate the bugs in the must know section, especially when most of the fixable ones might have already been fixed.
|
There's still a couple that should not be hard to simulate/fix:
Mineral Upload:
Stars! allows you to upload minerals to any fleet in orbit that does not belong to you. You can even do this if that fleet does not have a cargo hold. This causes the minerals to "disappear".
People have abused this bug to deny the salvage of a battle from their enemy by uploading the minerals from the surface to the enemies warfleet/bombers.
AR Starter Colonies:
Starter colonies for AR races will not contribute excess resources to research, unless the build queue is cleared first (using the clear button) or the hull design changed / upgraded. This is due to the "build Starter Colony" order invisibly blocks the end of the queue despite the fact that it has already been completed.
And even this one:
WP0 pop reload ignored
If:
1. a waypoint zero unload by hand of any of your population over an uninhabited planet is performed
2. a waypoint zero dropdown command of "Colonize" is given to a fleet with a colonizer module present over that planet
3. the population is reloaded by hand
Then: the reload order will be ignored and not saved with your turn. ALL pop will die (even the colonist that you did not unload) and the planet will remain uninhabited. A possible solution is to split the fleet into multiple fleets with cargo space and merge them back. If there is only one ship you'll have to redo your turn. (link to the thread in the Academy)
|
Mineral upload should be doable but I thought that wasn't possible anymore, I guess I'll have to try it, I'm sure I actually tried to do that when I first read about it but couldn't. The other 2 shouldn't be disallowed, possibly a warning could be given but I don't see why the X file should be rejected.
When testing AR I've never cleared the queue on new colonies and they have contributed to research so are you sure that still occurs?
...
[Updated on: Fri, 27 February 2009 06:10] Report message to a moderator
|
|
|
Re: Possible new utility for creating testbeds |
Fri, 27 February 2009 08:02 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
PaulCr wrote on Fri, 27 February 2009 12:02 | The problem is that stars puts all the changes in the x file even when there is no net change
|
Ouch. Perhaps you could just keep track of the changes applied to partially completed starbases, and reject any additions that weren't matched (or even superseded) by previous deletions.
Or even keep track of any design changes directed at the same design, merge them into just one change to be applied, and compare that to the original design.
Quote: | Mineral upload should be doable but I thought that wasn't possible anymore, I guess I'll have to try it, I'm sure I actually tried to do that when I first read about it but couldn't.
|
I seem to recall a vague memory of it still being possible. Worth a try, if that's the case.
Quote: | The other 2 shouldn't be disallowed, possibly a warning could be given but I don't see why the X file should be rejected.
|
Not rejected, but perhaps a silent fix would be better than a warning, at least if the x file makes it clear which was the player's intention.
Quote: | When testing AR I've never cleared the queue on new colonies and they have contributed to research so are you sure that still occurs?
|
Not sure. Another thing to be tested when/if I have some free time.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| |
Re: Possible new utility for creating testbeds |
Fri, 27 February 2009 19:45 |
|
PaulCr | | Chief Warrant Officer 3 Stars! V.I.P
| Messages: 187
Registered: February 2007 Location: An Island that kinda look... | |
|
mlaub wrote on Sat, 28 February 2009 00:23 | Well, I have grabbed the last patch to SHC, loaded glacier2 up successfully on both (created the hst file and all the mfiles).
All the ships I want for simming a battle show up (both sides).
But any attempt to get the next turn to gen results in a crash. Crash happens with or without h and x files.
I am obviously missing a step... Ideas?
-Matt
|
I've been using it successfully with Glacier 2, the only time I've had it crash was when I replaced one of the races with an AR, because of his ISB cloaking, a planet of his was in my h file without a starbase and if you have an AR without a starbase then stars will complain, think it was a divide by 0 error or something. If you've replaced one of the races with an AR then try giving it another PRT.
In the next version, due over the weekend, I'l be checking for AR planets without starbases and adding one if there isn't already one there.
If thats not the problem I can't think of anything else, I'd ask you to send the files but I'm in the game so you'd better not, if you send the xml config file I could look at that and see if that might give an idea of the possible problem.
Report message to a moderator
|
|
| | |
Re: Possible new utility for creating testbeds |
Fri, 17 April 2009 12:30 |
|
PaulCr | | Chief Warrant Officer 3 Stars! V.I.P
| Messages: 187
Registered: February 2007 Location: An Island that kinda look... | |
|
After about 2 months of no updates I've finally got round to fixing 2 of the biggest issues that annoy me when using it so V0.08 is now out. The first is the 50mg per enemy ship starting fuel which has now been changed to use the base hull fuel capacity meaning fleets should no longer need to limp towards their target. The second is that enemy fleets at planets where still being identified as being in space which caused issues when trying to gate them and with starbase refuelling, they are now properly identified as being in orbit of the planet.
I was actually surprised at how quick both of those were to fix once I actually decided to five it a go, if I'd realised they would only take about about an hour then I'd have done them ages ago. I'm also quite surprised at how little difference checking each fleet against each planet location makes to the generation times, certainly for Glacier 2 that I'm in there seemed no noticable difference, I was actually convinced that it couldn't have been done until I checked the enemy M files.
Report message to a moderator
|
|
| | |
Re: Possible new utility for creating testbeds |
Wed, 07 July 2010 18:17 |
|
|
PaulCr wrote on Fri, 17 April 2009 18:30 | After about 2 months of no updates I've finally got round to fixing 2 of the biggest issues that annoy me when using it so V0.08 is now out.
|
Hi Paul, could you, please, repost the link where to download it from?
Report message to a moderator
|
|
| |
Goto Forum:
Current Time: Thu May 16 12:30:02 EDT 2024
|