Home » Stars! 2.6/7 » The Academy » Bugs/Exploits in JRC4
Bugs/Exploits in JRC4 |
Mon, 31 January 2022 13:58 |
|
ricks03 | | | Messages: 229
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/TotalHostReport message to a moderator
|
|
| |
Re: Bugs/Exploits in JRC4 |
Fri, 08 July 2022 05:20 |
|
iztok | | Commander | Messages: 1219
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 |
|
ricks03 | | | Messages: 229
Registered: January 2012 Location: NC | |
|
iztok wrote on Fri, 08 July 2022 05:20Hi!
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/TotalHostReport message to a moderator
|
|
|
Goto Forum:
Current Time: Mon Dec 02 04:49:47 GMT-5 2024
|