Home World Forum
Stars! AutoHost web forums

Jump to Stars! AutoHost


 
 
Home » Stars! 2.6/7 » The Academy » Bugs/Exploits in JRC4
Bugs/Exploits in JRC4 Mon, 31 January 2022 13:58 Go to next message
ricks03 is currently offline ricks03

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

Messages: 220
Registered: January 2012
Location: NC
I'm looking at this list:
https://wiki.starsautohost.org/wiki/Known_Bugs

in the context of JRC4 (because no one should be playing at any other level). I think some entries are incorrect for JRC4. If anyone has any insights on that accuracy?

North/South Minefield Immunity
NOT Fixed in JRC4
There is an unusual bug in which there are no minefield hit checks done do a fleet traveling exactly due north or due south. Though the checks are carried out if there is even 1ly of east/west movement. This could allow a player to travel through a minefield at warp 10 with a 0% chance of hitting a mine. Most players would consider deliberate use of this bug to be "cheating".[1]
^ I can not reproduce this in JRC4. Ships moving N/S hit standard mines and explode.

East/West Speed Bump Minefield Immunity
(Sort of) Fixed in JRC4
A similar bug to the one above, but this time affecting only speed bump fields for fleet traveling due East or West.
^I cannot reproduce this in JRC4, so I don't know what "(sort of)" means. Ships traveling E/W through speed bumps hit them.

[freepop] Hack
Using a memory editing utility it is possible to create colonists out of thin air, limited only by a players freighter capacity, with the help of a memory editor. This abuses a lack of a viability check for loading colonist from an uninhabited planet, usually you cannot load more colonists than you drop down in a turn, but a memory editor can be used to trick the user interface into believing that you had dropped down millions of colonists, and the host doesn't double check these figures. Use of this in a multiplayer game would be considered by most players to be a totally inexcusable cheating offence.
^ I don't have a way of changing this i memory. But that memory change would have to be reproduced in the .X file, and I can hack the .x file for incorrect values, and yet can't reproduce it

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.
^ I can't reproduce this. At least, looking at the queue block for the new colony, there's no production queue orders. And a clear order doesn't create a change queue block when the queue appears empty.


If any of these are still broken, I'd love to develop a fix for them, but I can't reproduce the above in JRC4. I have learned, in testing Stsrs! orders, that there be a difference in issuing an order, and then tweaking that order immediately thereafter (which modifies the original order in the .x file), vs. issuing an order, then making an unrelated change, then changing the first order. In the latter case, the queue shows each separate change. In the former case, you can end up with only one order.


If you can help me find steps to reproduce them, that would be helpful. Or even a turn file (.M or .X) that will help reproduce the problem.

Thanks for any insights.









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

Report message to a moderator

Re: Bugs/Exploits in JRC4 Sun, 24 April 2022 10:03 Go to previous messageGo to next message
magic9mushroom is currently offline magic9mushroom

 
Commander

Messages: 1360
Registered: May 2008
ricks03 wrote on Tue, 01 February 2022 05:58
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.
^ I can't reproduce this. At least, looking at the queue block for the new colony, there's no production queue orders. And a clear order doesn't create a change queue block when the queue appears empty.

This is definitely dead letter. I posted about it here - the colonies do, in fact, contribute to research.

Report message to a moderator

Re: Bugs/Exploits in JRC4 Fri, 08 July 2022 05:20 Go to previous messageGo to next message
iztok is currently offline iztok

 
Commander

Messages: 1197
Registered: April 2003
Location: Slovenia, Europe
Hi!

> This is definitely dead letter. I posted about it here - the colonies do, in fact, contribute to research.
I can confirm this. In my (many) tests with AR I could not reproduce this "bug".

Quote:
[freepop] Hack
Using a memory editing utility it is possible to create colonists out of thin air, limited only by a players freighter capacity, with the help of a memory editor. This abuses a lack of a viability check for loading colonist from an uninhabited planet, usually you cannot load more colonists than you drop down in a turn, but a memory editor can be used to trick the user interface into believing that you had dropped down millions of colonists, and the host doesn't double check these figures. Use of this in a multiplayer game would be considered by most players to be a totally inexcusable cheating offence.
^ I don't have a way of changing this i memory. But that memory change would have to be reproduced in the .X file, and I can hack the .x file for incorrect values, and yet can't reproduce it


Can I suggest several tests?
1. Load min amount of pop, then change it in .X file with hex editor, but stay within the freighter capacity.
2. Load min amount of pop, in the next turn change the amount of pop on the freighter.
3. Un-load min amount of pop, then change it in .X file with hex editor, but stay within the freighter capacity.

Maybe there are additional tests with existing M files for consistency?

BR, Iztok



Report message to a moderator

Re: Bugs/Exploits in JRC4 Sun, 10 July 2022 16:50 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: 220
Registered: January 2012
Location: NC
iztok wrote on Fri, 08 July 2022 05:20
Hi!


Quote:
[freepop] Hack
Using a memory editing utility it is possible to create colonists out of thin air, limited only by a players freighter capacity, with the help of a memory editor. This abuses a lack of a viability check for loading colonist from an uninhabited planet, usually you cannot load more colonists than you drop down in a turn, but a memory editor can be used to trick the user interface into believing that you had dropped down millions of colonists, and the host doesn't double check these figures. Use of this in a multiplayer game would be considered by most players to be a totally inexcusable cheating offence.
^ I don't have a way of changing this i memory. But that memory change would have to be reproduced in the .X file, and I can hack the .x file for incorrect values, and yet can't reproduce it


Can I suggest several tests?
1. Load min amount of pop, then change it in .X file with hex editor, but stay within the freighter capacity.
2. Load min amount of pop, in the next turn change the amount of pop on the freighter.
3. Un-load min amount of pop, then change it in .X file with hex editor, but stay within the freighter capacity.

Maybe there are additional tests with existing M files for consistency?

BR, Iztok

You can't just edit a .x file with a hex editor, as .x files are encrypted. That's why the original hack was making the change in memory. As I said in my original comment, I HAVE hacked the .x file (that being modifying values in the .x file by decrypting, making changes, and reencrypting) to try to reproduce, and cannot.

That's why I was looking for assistance in reproducing the original problem.




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

Report message to a moderator

Previous Topic: Guts of calculating cargo when fleets split.
Next Topic: MT parts details
Goto Forum:
  


Current Time: Mon Aug 08 22:47:20 EDT 2022