It says February, but that was the date I made those changes internally, to make sure nothing broke. I published our work in February just today. Before that, the last published change was from August.
3 Likes
Since it says Feb 4th … is it possible the month and day got transposed? They perhaps use the Euro system of dating or visa-versa?
1 Like
One thing I found in the version from last year, and it’s not working in this version either, is that I can’t run the “Show full text during game” option in Randomtest on Firefox. I have to use the command-line version for that (which I prefer anyway, since I can save the output to an external file).
Specifically, the page doesn’t display any output; it just stays blank.
1 Like
I thought I read that there was a new code that was introduced: *next_curl_goes_back, yet it is not working for me. Has this not been introduced, or have I typed it incorrectly?
I have no idea what you’re referring to. *next_curl_goes_back is not a real ChoiceScript command.
What problem are you trying to solve? You’re trying to make the next … “curl” … go “back”? What do you mean by “curl”? Go back to what??
I saw a comment that I thought was resolved that showed how transitions of pages that went from right to left could go from left to right, as if flipping a page backwards, such as has been seen from “show stats” to “return to game.” This command, from my understanding would be able to be used by authors for when they have an “undo” option, such as when a player wants to go back a page when they change their mind on a choice, and the author wants to make it look like the player is flipping back a page in their book.
No, that’s not currently a feature of ChoiceScript. (Maybe someone wrote some modification code that could do it?)
1 Like
Hi,
I am making narrative fighting games (such as street fighter 2 gams) using choicescript. So combats use many repetitive routines with *gosubs.
Whatever the number of looplimit i choose random tests interrupt due to repetition of rounds in combas.
With previous versions of xhoicescript it worked fine.
So would you please additionnaly allow to simply disable looplimit ?
Regards.
Can you help me understand your code here? You’re hitting a single line of code more than a million times in a single playthrough? And yet your game actually works, and isn’t stuck in an infinite loop?
Hello,
Exact, some lines such as the display of life and energy of each fighter -a GOSUB routine) is hit tons of tons of times.
Regards.
MSB
A configurable looplimit would be nice, although I agree that hitting a million seems unlikely in 99% of games.
On a semi-related note, @dfabulich are you aware that nested gosub_scene and return pairs will eventually lead to exceeding the JavaScript callstack limit? Due to how “*return” actually just essentially creates a new (old) scene, rather than actually returning.
Reason I mention this is that I can think of cases where games might bust the looplimit, where there is a heavy use of utility routines, but they’re probably more likely to hit that error first, before they hit the looplimit. So if there’s no plan to fix that, then adjusting the looplimit seems less important too.
1 Like
*return doesn’t pop the stack? That seems… suboptimal.
1 Like
So I believe…
I can reproduce with the following:
startup.txt
*create n 0
*scene_list
scene2
*label loop
*if n < 1000
*gosub_scene scene2
*goto loop
*ending
scene2.txt
*set n + 1
*return
Which whilst being a rather atypical example, this should be perfectly fair CS, in my mind.
Browser Errors
Firefox
Chrome
However, one thing I have just noticed now, is that I can only seem to reproduce this in ‘compiled’ games. If you run a local web server, or ‘upload’ your files, it seems to work OK. So maybe the problem is more to do with how the scenes are loaded, rather than how the return logic itself is implemented.
2 Likes
I was not able to reproduce the issue when running locally (or uploading on dashingdon.com). The maze generation (Advanced programming - randomized maze) is fully recursive, and it can get more than 2000-level deep. The engine seems to hold fine.
Does this hold? And note that it would only apply to recursive use of gosub_scene. Recursive gosubs are fine.
Yes, it’s a gosub scene. I didn’t try compiling – if you give me some pointers on how to do it, I’ll be happy to test.
By the way, it’s tricky to do recursion with just gosub, as there is no state associated with each recursion level.
I’ve fixed this “Maximum call stack” issue on the latest ChoiceScript up on Github.
In addition, I’ve added support for *looplimit 0 to disable the looplimit check.
4 Likes
For some closure here @dfabulich @cjw, I couldn’t reproduce with the compiled version either. Thanks for the fix.
By the way, the compiled version feels slower than the source files. It’s handy in being only one file, but it doesn’t seem to help with speed (which is probably NOT a goal of compilation, in this case).
1 Like
That surprises me because that is (was?) precisely the point of compilation. Everything is loaded into memory from the get-go, rather than read from disk on-demand. Heavy usage of gosub_scene, at least, I would have thought would be faster. Though of course it’s going to depend a lot on your device and environment.
Hi @cjw. I stand corrected, compilation seems to be about 10% faster.
I did some tests, using JS getTime().
*script this.stats.start_time = new Date().getTime();
*gosub_scene startup explore (max_r - 2) (max_c - 2) 0 ""
*script this.stats.end_time = new Date().getTime();
explore is my compute-intense recursive map generation. On my initial measurement, on a very large map, it looks like the compiled version is 10% faster (about 3 sec vs 3.3 sec). Similar on smaller maps, with higher variance (1-1.2 sec vs 1.1-1.3 sec). I guess the variance tricked me initially!
Also, to my experience there is a big performance gap if the gosub_scene is on a different file (in my case, it’s the same file). Compilation may have a bigger effect in that case.