Spoiler: SHOW
The source and context of the above quote is given in the spoiler, but this is specifically an LTSL query.Despite my best efforts – it seems I’ve written code-poison. I can’t figure out why the algorithm is failing – it constantly gets locked into picking the same two stars in a route, despite being told to ignore any star it’s previously picked.
PLEASE DO NOT DISCUSS JUMP DRIVES IN THIS TOPIC
Thank you.
With that out of the way, I wanted to raise the question on how (global) variables are handled across multiple mods.
(where one mod uses a function from another script, which in turn has used that function from another script.)
Our wonderful Josh has shown us the light on how a function can be programmed within LTSL and re-used ( ).
However, in the specific instance where multiple mods/script files have been implemented with LTSL, how can we avoid the instances of "code-poison" where we know the script we programmed works fine (ie. in vanilla LT), but doesn't work with a specific set of mods?
I know in DOS, I merely turn off {@Echo off}, and place a couple of {pause} statements to debug the code.
To all programmers (Josh included ), what options/opinions do you all have on this?
Note1: I am of the understanding in this example that we are dealing with over a dozen script files that each have created their own reusable code, and I can only surmise that the code might look like this:
Code: Select all
<script10>
<calls function from script8>
<function from script8>
<calls function from script10>
<function from script10>
<calls function from script11>
<function from script11>
<calls function from script3>
P.P.S. I think this falls under code obfuscation, where we cannot see were code is being called by a different script (otherwise it would be a simple case of calling "script3" yada yada).
The idea is that we cannot see why our function in LTSL fails, or keeps resolving the same results, even though we code it differently on each iteration.