Open jpcompton opened 4 years ago
(.sck and .sao in zip) rotten.zip
(I've confirmed that the format limits us to 99 messages and solved my own problem with multi-line strings and kept the project under 99 unique messages. However, a compiler warn about breaching this limit would be very useful.)
...but maybe the issue is more complicated! Adventshark's pdxiv comes up with a proof-of-concept with hundreds of (successfully) printed messages.
https://intfiction.org/t/scottkit-producing-misplaced-out-of-order-strings/45507/13
The most optimal way to handle this whole limitation, in my opinion, would be a two-fold approach:
The first part of the approach would be to only allow "even" print commands use up to 99 messages. The second part of the approach would be to give "even" print statements precedence in the messages list. For example, in the following "occurrence":
occur
print "odd message 1"
print "even message 1"
print "odd message 2"
print "even message 2"
The messages list would be populated with the entries in the following order, to make sure that "even" messages have a higher chance of being within the first 99 message entries:
"even message 1"
"even message 2"
"odd message 1"
"odd message 2"
@pdxiv I am not following this at all. Why should even-numbered messages get priority? How would the writer even be expected to know which messages are even numbered and which are odd numbered?
Even-numbered messages should get priority, because it would reduce the chance of them addressing a message with an index higher than 99. Odd-numbered print commands don't have this limitation, because of how they are encoded (150*command 1 + command 2
, 150*command 3 + command 4
).
Sadly, the author of a game can't be expected to know this beforehand, unless they have more intimate knowledge of how the Scott Adams engine encodes data. The way I see it, the ScottKit language is a sort of "assembly language" for the engine, and perhaps that could be a moral justification. An author could perhaps be made aware of how the messages work, via suitable error messages for when the situation arises.
My apologies if I'm completely off on this one.
Ah, I see. Yes, that makes sense. I will think on this.
Sorry for the slow responses to these recently filed issues, BTW. I have a lot on at the moment, but I do intend to get to this and the other issues.
I'm running into a problem where certain printed strings are appearing out-of-order and with substitutions of other strings from elsewhere in the code (generally from the first block of strings, used in the
occur when !flag 1
section of the game.)The output shown is:
But I would expect, based on my code:
and
This behavior is identical in scottkit -p and in scottfree.
Apologies for the critical path to replicate being a bit cumbersome...