Home World Forum
Stars! AutoHost web forums

Jump to Stars! AutoHost


 
 
Home » Stars! Clones, Extensions, Modding » Stars! Extensions » X-file-sanitizer
X-file-sanitizer Fri, 04 March 2016 01:44 Go to next message
platon79 is currently offline platon79

 
Chief Warrant Officer 3

Messages: 185
Registered: February 2004
Location: Norway
Well, since my galaxyviewer/galaxyanimator-tools did not spark much of an interest, I decided to try to make some sense of the x-files, to see if I could make an X-file-sanitizer.
The first version is in the repository at https://github.com/stars-4x/starsapi and has to be checked out.
So far it does not do too much, it reads an x-file, and checks for the following 2 things:
-If a new ship design has been added that has type colonization module and count 0.
-If a direct north/south movement is detected with warp > 4 and "there is a planet at both waypoints" is false.
For the latter, it builds the complete waypoint tree using both the old waypoints from the m-file and all the x-file-changes, i have tested it with deleting/adding/changing a lot of waypoints and it seems to work.
But if someone has an extensive library of turns that also contains x-files, I would be delighted if they can test the tool on a lot of x-files, and report any errors that should occur.
XFileReader should exit with error code 1 if file was not properly sanitized or another error occured, and error code 0 if everything was ok. It will also print sanitazion errors to System.err
You may make suggestions to which bugs that should be the focus for later improvements. If the tool gets good enough, maybe Ron can even incorporate it to the fileupload-process Very Happy

Report message to a moderator

Re: X-file-sanitizer Fri, 04 March 2016 19:19 Go to previous messageGo to next message
m.a@stars is currently offline m.a@stars

 
Commander

Messages: 2765
Registered: October 2004
Location: Third star to the left
Cool! Cool

Any of the Known_Bugs and not fixed in JRC4 would be neat to stomp.

I'd start with the "Cheap Starbase", the "Mineral Upload" and the "Space Dock Armor slot Buffer Overflow". Rolling Eyes

The "AR Starter Colony" and the "freepop Hack" bugs could be other nice ones to fix. Work at computer

The "racefile corruption" when changing the race name is another nasty and probably easy one. Confused

Then there's the "fleet targeting" bug family:
- The pursuer overshoot. Shocked
- The "fleets chasing fleets chasing fleets" stuck bug. Whip
- The "guaranteed intercept" freeze... Wall Bash

There was another nastie when the owner of a SB can manipulate who attacks who in a multisided battle. 2 Guns



So many Stars, so few Missiles!

In space no one can hear you scheme! Deal

Report message to a moderator

Re: X-file-sanitizer Sat, 26 March 2016 17:21 Go to previous messageGo to next message
platon79 is currently offline platon79

 
Chief Warrant Officer 3

Messages: 185
Registered: February 2004
Location: Norway
Finally got some time to look at this tool again.
I have now added the "Space Dock Armor slot Buffer Overflow" as that was not so hard.
I have also now tried the tool with some more real-life scenarios from my own game that I am playing in. Regarding the minefield movement bug, I found out that my first attempt at the waypoint tree was too simple, as I hadn't done any splitting and merging in my simple testbed. So I had to decipher the split and merge blocks too. Then one of my turns produced an error anyway. I don't usually skip turns, but this was a turn where everyone had skipped due to an error. I tried building the waypoint tree with only the last turns blocks, but got an error anyway. I figured out it was possibly due to a deleting of a design, deleting a few ships in the process, as this of course made new fleet numbers available for later splits. I therefore incorporated to try to take DesignChangeBlock with fleet deletions into account. And got the error anyway..
Finally, after quite an amount of time, I found out that the x-file had a timestamp from before the m-file, so I had actually started doing things before the skip.. Razz (The fleet that produced an error had exploded in a minefield in the last turn, but had an AddWaypointBlock in the x-file..)
Conclusion 1: I think it works now, but would very much like that other players also run this tool on their games to check for any errors in the waypoint building system. Let me know if you need a runnable jar-file.
Conclusion 2: Of 78 analyzed turns, I was surprised to find that 10 of these actually produced the "Vertical movement detected for fleet #X" error message.
I thought that this error would not be that frequent for unintentional moves, but when I myself has done it 10 out of 78 turns, it might be more frequent than expected. Of course, I'm playing an SD player, with a lot of ships moving around to lay minefields at new locations etc. The question is if the suggested rule elsewhere in the forum of not allowing direct movement in vertical direction, unless both waypoints are planets, should still apply, or if another rule would be better? I noticed that one of the movements that I got an error on was where I was moving from planet A to B but the time took 2 or more years. Should it perhaps be allowed to make a vertical movement to a planet if another planet is found by extrapolating backwards from the fleet?

Report message to a moderator

Re: X-file-sanitizer Tue, 29 March 2016 22:01 Go to previous messageGo to next message
m.a@stars is currently offline m.a@stars

 
Commander

Messages: 2765
Registered: October 2004
Location: Third star to the left
platon79 wrote on Sat, 26 March 2016 22:21
this was a turn where everyone had skipped due to an error.

Weird. Was the whole file erroneous, or was there some parts that could be salvaged? Confused


Quote:
Of 78 analyzed turns, I was surprised to find that 10 of these actually produced the "Vertical movement detected for fleet #X" error message.

Sounds like a lot. The fleets actually intersected minefields?


Quote:
The question is if the suggested rule elsewhere in the forum of not allowing direct movement in vertical direction, unless both waypoints are planets, should still apply, or if another rule would be better?

It should be possible to rejigger the destination waypoints just one ly away from pure vertical for all trips not ending at a planet. And chalk it up to "mine avoidance" autopilots... Rolling Eyes



So many Stars, so few Missiles!

In space no one can hear you scheme! Deal

Report message to a moderator

Re: X-file-sanitizer Mon, 04 April 2016 01:40 Go to previous messageGo to next message
platon79 is currently offline platon79

 
Chief Warrant Officer 3

Messages: 185
Registered: February 2004
Location: Norway
m.a@stars wrote on Tue, 29 March 2016 22:01

Weird. Was the whole file erroneous, or was there some parts that could be salvaged? Confused

I'm pretty sure this is what happened:
We got a new turn. I completed or at least started on the x-file.
The host changed gen-schedule, and as an unexpected result, the game genned prematurely.
I downloaded the new turn.
The game was set back a year from backup.
I copied the downloaded turn to a subdirectory in case I wanted to look at it later.
This folder then had an m-file containing 2 years, and an x-file from the "middle", that really was not valid Wink
m.a@stars wrote on Tue, 29 March 2016 22:01

Sounds like a lot. The fleets actually intersected minefields?

No I'll admit that the fleets did not intersect minefields, except my own ones.
I have to admit that I had always thought that the restrict vertical movement rule should be a general rule.
After all, we don't always see all minefields. It cannot be a valid strategy to place a fleet directly above or below a planet if you don't see the minefield, but want to play safe?
And if I position a fleet directly above or below an enemy planet with no visible minefields, and my tool was running on the server side and also checking for unspotted minefields, it could also be used to actually find the radius/perimeter of an enemy minefield by submitting multiple turns with vertical movement and see which ones produced an error.
Hmmm, so what should the rule then be? That it only triggers on visible minefields, and that unspotted minefields are still not covered by the tool?

Report message to a moderator

Re: X-file-sanitizer Mon, 04 April 2016 23:49 Go to previous messageGo to next message
m.a@stars is currently offline m.a@stars

 
Commander

Messages: 2765
Registered: October 2004
Location: Third star to the left
platon79 wrote on Mon, 04 April 2016 07:40
what should the rule then be? That it only triggers on visible minefields, and that unspotted minefields are still not covered by the tool?

Just rejigger the destination waypoints one ly away from pure vertical if they target deep space or the center of a foreign minefield?

It should always be possible without increasing trip time or fuel usage. Teleport

Chalk it up to universal frames of reference harmlessly wobbling when at warp speed. Twisted Evil



So many Stars, so few Missiles!

In space no one can hear you scheme! Deal

Report message to a moderator

Re: X-file-sanitizer Wed, 22 April 2020 02:45 Go to previous message
ricks03 is currently offline ricks03

 
Officer Cadet 1st Year
Creator of TotalHost and Stars! utilities
Created TotalHost and Stars! utilities

Messages: 222
Registered: January 2012
Location: NC
I believe the standard minefield X axis, speedbump y axis bugs were fixed in jrc4.

So don't waste time fixing it (as I did).

Same thing for the AR Starter Colony bug: https://starsautohost.org/sahforum2/index.php?t=msg&goto =63820&rid=1532&srch=AR+Starter+Colony#msg_63820


[Updated on: Thu, 23 April 2020 18:53]




https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHost

Report message to a moderator

Previous Topic: Stars! disassembly and history of 2.6jrc4
Next Topic: AR Starter Colony bug fixed JRC4 (??)
Goto Forum:
  


Current Time: Thu Mar 28 05:00:45 EDT 2024