And also is it true that once a scene is called, it will keep running in the background until you restart the game?
I’m still trying to feel out the system and how the IDE behaves in certain situations at this point. Working out what works and what don’t to see the extent of what you can and can’t do. Haven’t had a plan for any serious writing as of yet, but I do have an interest for testing out the language.
So, I’ve written about a 1200 to 1300 lines worth of code in one scene that controls an inventory system’s behavior and interface (memory slots, designations, etc) and some functional profiles to feed it which acts as items with effects.
Before I write any further and hit some foreseeable roadblocks though, I was wondering whether there’s an actual limit to how many lines of code you can fit into one scene. Also why does it usually takes two to three times to properly refresh the variables by restarting when arithmetic operations are involved? Why does randomtest keeps repeating that one looped choice even though it’s supposed to avoid picking the same ones when the setting is ticked? Why are *(goto) ref commands (in it’s syntax) even flagged as a bad label?
Why does it feel like the statscreen is a vacuum class/script when compared to actual scenes?
I mean, I can kinda hazard a guess to last one but I’m fairly sure I’m not the only that notices how the statscreen only visually update variable states when the mainscreen is updated. Or how the ^rand command still runs when switching between the two screens.
I’m no ‘real’ coder, so take everything I say with a grain of salt.
For as far as I’m aware there is no hard limit to how many lines of code can fit into a scene. The only issue you might get is that the scene might take longer to load. It shouldn’t be much of an issue if you (be warned, this is a rough estimate) stay below the 100,000-1,000,000 lines of code per scene.
An actual coder might be able to answer this better, but I think only the choicescript_stats.txt and startup.txt are loaded permanently, since those are the two scenes that track what variables you set in the game.
Because it ran into a looping choice within the same test run of the game. Randomtest only tries to avoid picking the same options between different iterations of running the game. If you run into a looping choice option that’s a coding error, not a randomtest error.
The syntax is goto_ref. If you forget the _ in any syntax or variable name ChoiceScript won’t recognize it and result in an error.
Because it runs parallel to the scenes, but the two don’t interact aside from exchanging values of variables. Which happens when the game hits a page_break, choice option, or a finish or other transition between scenes.
There’s a workaround to this. Set the rand command a screen before you actually check it, and it will work as intended.
I hope this answers at least some of your questions.
I’m fairly sure that I won’t be going past 30,000 lines per scene at the very most but that’s still nice to know. But, say that I’m running the scene full of subroutines. Would those subroutines only load its chunk of the code through the use of *gosub_scene commands or would the entirety of it all load all at once for standby when one subroutine is called?
Fairly sure that it’s still *gotoref but my inquiry was probably a little too vague, so it’s referring to something like this:
Where function_fetcher still finds the intended label I want it to find, but quicktest still flags it as if it’s a bad label. Probably it doesn’t account for the ref syntax { } around it?
Why are they exchanging values of variables? Doesn’t the engine usually governs any changes to the variables and the scenes would directly refer to them for their uses, instead of with another scene?
I’m aware of that solution. But it’s kinda odd why it happens in the first place.
