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 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'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

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


Current Time: Fri Mar 29 05:30:59 EDT 2024