When you find any bugs in the game please post them here but do not post exploits!
Loop in saved orders don't work
|
Puzzlemaker Posts: 11
6/7/2017
|
You have to manually set the loop when you load saved orders. This kind of screwed me, it would be nice if this was fixed. Thanks.
|
|
|
0
link
|
|
Vulpex Posts: 390
6/7/2017
|
This is true for when you have a loop with a limited number of loops but yes it's a bit weird. It would make sense that when you load a loop (2) it would start as a loop (0/2), rather than loop (undefined) which is weird.
|
|
|
0
link
|
|
Doctor Dread Administrator Posts: 1478
6/7/2017
|
I cant track which order you are looping to when you load or append the list of orders, Its not attached by the order number on the list. Its seems easy when 90% of the time your loading a list and the loop is going back to the first order, but it isn't. I might be able to put it in red or give you the red warning that you have a loop order that isn't looped to anything
|
|
|
0
link
|
|
Tahujoe Posts: 25
6/8/2017
|
Would it be possible to save that pointer as an index and translate the index back into a pointer on load?
So structurally the order list behaves like a linked list more than an array, yes? Which means loop orders have to point directly to a specific order instead of holding the index value for that order. You're already translating out indeces for the UI elements, though. Are you saving the loop orders as loop orders? Maybe a proxy struct instead, with most of the same values but an index instead of a pointer? That means an extra step on both save and load, but save/load happens asynchronously with the major game tick anyways.
Of course, this would also mean that old saved programs would either still be broken in this way or just not work at all.
Oh, as for the issue I was expecting? I was expecting to have to reassign loop orders to the correct index after deleting or inserting an order before their target order, as if the loop orders were using an index instead of a pointer.
--
I swear I'm not trying to break things.
|
|
|
0
link
|
|
Doctor Dread Administrator Posts: 1478
6/8/2017
|
The best I can do is make the loop order remember the "Order #" from the list also, which is usually #1 but not always. So when you LOAD it not Append it, I can make the assumption that it is pointing to the same number on the list and update the loop order appropriately. However if you APPEND the order list, suddenly that loop back to order #1 could be Order number #26 for all I know and we'll be back to a broken loop order that needs to be updated. Also, maybe people have several loop orders in crazy patterns which I can still make work using the above assumption but on an Append they will all break.
On second thought I think I could actually use the fact that this order is looping back to order #1 from this list and it just got appended to another order list where we started now starter at #12 so I can just "Shift" all those order numbers by 11 and figure out where they were looping to.
Something I can look into
|
|
|
0
link
|