# KSP: any insight into this mysterious bug?



## Fredeke (Dec 8, 2019)

Hi
After some code rewrite that didn't significantly alter the overall structure, a bug appeared that just blows my mind.

The precompiler precompiles without error (finally ), but then Kontakt (5.7) refuses to apply the script because this generated line:

```
set_control_par_str(get_ui_id($mn_tk6_select),$CONTROL_PAR_TEXT,!_track_name[20*99*$act_page+(20*$act_drone)+19])
```
returns this error: _"$mn_tk6_select" was not declared or is not allowed here_.

Needless to say, when parsing the generated ICB, I can see that control is actually declared. And as for it not being allowed "here", well... It's just in a UI callback.

But it gets weirder: When I deleted the whole portion of script generating that callback (it was a macro iterating other macros, generating a bunch of callbacks, for a bunch of buttons), the bug migrated to a seemingly random but similar line, regarding another ui control, this time not in a callback but in a function (so what exactly is that "here" where perfectly normal commands are not allowed anymore?). I repeated the operation of deleting one problematic section after another, and the error keeps moving seemingly randomly from one set_control_par command to another - each time related to a completely different ui control - of any kind, apparently - and in no apparent order - and without apparent relation... not apparent to me anyway.

Btw, the parts generating errors are not the ones I rewrote since the script worked. I know SublimeKSP sometimes "displaces" errors while doing its magic, but this time I really don't know where to look for the cause.

It may be worth mentioning that, while the SKSP script is still compact enough, the generated KSP is thousands of lines long. I rely a lot on iterating macros, because I see no way around that: I need to change the content of some menus on the fly, and since Kontakt doesn't do that, I need to emulate my own menus using a lot of buttons (don't I?). So there are hundreds of ui controls in my instrument, even though most are hidden most of the time.

Besides so many controls, the script also deals with a dozen of hundreds-to-thousands-elements arrays. They act as a "databasesque" configuration for the instrument. (See the last argument of the command hereabove)

So, first and obvious question:
Is Kontakt's script interpreter known to break down under such a load?
Or is it just my brain, breaking down under the unexpectedly growing complexity of this undertaking?

Then:
Experienced KSP coders, what do you think?
Ever been confronted to a similar issue?

I hate to admit I may have bitten more than I can chew in terms of complexity. But I still hope a simple hint could help me get unstuck.

[UPDATE: I just deleted all set_control_par commands, and now other (completely innocent-looking) occurences of those controls are generating errors because they're allegedly not declared - when they clearly are. But it doesn't say anything about them being "not allowed here"... So this narrows it down a bit I guess?]


----------



## EvilDragon (Dec 8, 2019)

This is gonna be hard to figure out without the actual full script being posted... It could simply be a typo somewhere...


----------



## Fredeke (Dec 8, 2019)

Yeah... I won't inflict that on you.

Just been messing around for the last hour and will continue to do so for as long as it takes I guess.


----------



## P.N. (Dec 8, 2019)

This happens in 5.7 only?
Does it work in other versions? The reason i'm asking this is because, in my experience, 5.7 was notorious for having some unpredictable bugs.


----------



## Fredeke (Dec 8, 2019)

It's the kind of issue I've run into when using ui or variable prefixes ($,@,~,% etc.) when I shouldn't (according to the SublimeKSP doc), or not using them when I should (according to empiric trial and error), or that kind of shinanigans. But usually I got that quite quickly. Here, I don't see it.


----------



## Fredeke (Dec 8, 2019)

P.N. said:


> This happens in 5.7 only?
> Does it work in other versions? The reason i'm asking this is because, in my experience, 5.7 was notorious for having some unpredictable bugs.


Waw. In such case, I should upgrade before wasting more time.
Anybody else thinks it could be 5.7's fault instead of mine?

I can't test it right now because the only other version I've got lying around is 5.2, which lacks key features I need here (like real arithmetic). I've been meaning to upgrade to 6 soon, but was hoping to still dev this one for 5.

PS: I like your avatar. Did you change it?


----------



## P.N. (Dec 8, 2019)

Send me the code then, so i can steal it. I mean, test it.


----------



## Fredeke (Dec 8, 2019)

P.N. said:


> Send me the code then, so i can steal it. I mean, test it.


Seriously??? If you mean that, I sure would.

Even though you're kidding about it, I wouldn't mind you stealing a few of my ideas (would you find them worthy), after all you've helped me for the past year.

Let me prepare a zip, and I'll PM you soon.

@EvilDragon: As soon as I find an opportunity, I hope I can repay you too


----------



## P.N. (Dec 8, 2019)

Yeah, i'm not gonna steal it. :D

I'm just gonna paste it in 5.8 and 6 to see if Kontakt eats it.
I mean, that's all i can do...

You can send me the compiled code, with compacted variables. That shouldn't matter.

PS: No, same avatar.


----------



## Fredeke (Dec 8, 2019)

P.N. said:


> You can send me the compiled code, with compacted variables. That shouldn't matter.


Right. Simple enough. Doing that now.


----------



## Fredeke (Dec 8, 2019)

Ok, just to let everyone know: @P.N. and I determined version 5.7 was at fault. Version 5.8 accepts the exact same script without the slightest error. I guess this settles that, and "all" I've got to do is upgrade.

Thanks.


----------



## EvilDragon (Dec 8, 2019)

Could it be you used arrays larger than 32768? This only works properly in 5.8+


----------



## Fredeke (Dec 9, 2019)

EvilDragon said:


> Could it be you used arrays larger than 32768? This only works properly in 5.8+


That could very well be it!
I overlooked that limitation, and indeed some of my multidim' arrays can grow beyond it.

Out of curiosity: From your phrasing, I get that this is not an official limitation of 5.7 (which would yield a clear and relevant error message), but rather a bug in handling huge arrays?


----------



## Lindon (Dec 9, 2019)

Fredeke said:


> (snip)
> 
> Out of curiosity: From your phrasing, I get that this is not an official limitation of 5.7 (which would yield a clear and relevant error message), but rather a bug in handling huge arrays?



Nope, thats been a documented limitation in Kontakt right up to 5.8


----------



## Fredeke (Dec 9, 2019)

Lindon said:


> Nope, thats been a documented limitation in Kontakt right up to 5.8


Right. I thought I read something like that. I should have remembered.


----------



## EvilDragon (Dec 9, 2019)

Array size limitation grew with time. Initially I think it was just 1024 or so entries (in Kontakt 2), in Kontakt 3.5 this limit was increased to 2048, in Kontakt 4.0 it was increased to 32768 and it stayed this way until 5.8, when they increased it to 1 million finally.


----------



## Fredeke (Dec 9, 2019)

EvilDragon said:


> until 5.8, when they increased it to 1 million finally.


I think I can live with that limitation.


----------



## Fredeke (Dec 9, 2019)

Ok now I have *another *problem, and there's a chance it belongs in this thread:

Kontakt 5.8 (working with the demo for now) displays this error message for seemingly random lines: _parser stack overflow_.

What triggers it is the size of arrays: past a certain size, I get that. But no array exceeds (or even approaches) 1 million elements. [UPDATE: it seems it always happens on a line involving an array, but sometimes it's just, like, the 2nd element of a 10-element array]

What does the error mean exactly? I mean: does it mean there are too many variables, or that the script is too long, or... what? (Should I try K6.2? Is there an already sufficient market for K6 instruments?)

(I haven't even really started coding the instrument's engine. I'm only dealing with the interface for now. If the script is already too much for Kontakt, maybe I should just drop the project and accept it's not suitable for Kontakt? Does that happen to people often?)


----------



## d.healey (Dec 9, 2019)

Fredeke said:


> Does that happen to people often?


Newbies often have such id10t errors 

But seriously just post your entire UI code. I find the most common cause with these kind of issues is the developer over complicating their work in an effort to make it easier to maintain and be more reusable. It sounds counter intuative but I find myself doing it often. Sometimes the simplest verbose code is better than the more complicated but leaner version.


----------



## EvilDragon (Dec 9, 2019)

Your init callback might be too long. How many lines is it?


----------



## Lindon (Dec 9, 2019)

time for if 1=1 in the init...


----------



## Fredeke (Dec 9, 2019)

@EvilDragon: The generated ICB is 2256 lines long. However, it doesn't get longer when I increase array sizes past the buggy limit.

@d.healey: Yes I allowed for bigger arrays than I actually need in order to make this engine re-usable. I could of course bring the specs down without much loss. However, not knowing the cause of this bug worries me, because I'm afraid it comes back later, at a point where I can't just discard a feature and keep moving on.

I also feel like the code is overcomplicated. However every time I complicate things, before doing so, I think "like really hard" to make sure there's no simpler way. I don't know, maybe I still overlooked possibilities.

@Lindon: *if 1=1*: Could you please elaborate? I used to know but I forgot what it is. I often comment out parts of the code to see how it goes, and I suppose if 1=1 is a similar technique?


----------



## d.healey (Dec 9, 2019)

Fredeke said:


> As for the code ... here it is. First the SublimeKSP code:


I don't see it.


----------



## EvilDragon (Dec 9, 2019)

With 2250 lines in ICB there's no need for 1=1 workaround. It must be something else triggering parser stack overflow then.


----------



## P.N. (Dec 9, 2019)

Yes, i don't know the limit (and i've never seen the stack overflow error, because i'm good at predicting errors... :D), but i got something with almost 3000 ICB lines right now on a project. No issues here.

@Fredeke
Consider loading external arrays in the ICB, if possible for your project. (i'm not sure it will help with parser stack errors, but it simplifies the code a lot anyway).

If you jump over to 6.2, take a look at the ui_panel control and load_performance_view() command. I still haven't had a chance to try those myself, but judging by their description alone, they should make the UI building process a lot easier.


----------



## Fredeke (Dec 10, 2019)

d.healey said:


> I don't see it.


Yeah, sorry. I should have deleted that line. In fact the code was too long for a VI post. It got refused even after I tried some trimming.


P.N. said:


> @Fredeke
> Consider loading external arrays in the ICB, if possible for your project. (i'm not sure it will help with parser stack errors, but it simplifies the code a lot anyway).


Are you suggesting load_array() ? So I would need a temp. script to save the array first as well?
Yes, I suppose I can do that.


P.N. said:


> If you jump over to 6.2, take a look at the ui_panel control and load_performance_view() command. I still haven't had a chance to try those myself, but judging by their description alone, they should make the UI building process a lot easier.


God, you're so right. Every day I resist the temptation to do that, because I want the instrument as retro compatible as possible, but it's a real pain and the code needs to be sooooooo long just to achieve so little!

If you guys can convince me that I'm wrong, I won't need much push before I finally decide to upgrade


----------



## P.N. (Dec 10, 2019)

Fredeke said:


> Are you suggesting load_array() ? So I would need a temp. script to save the array first as well?
> Yes, I suppose I can do that.



Yeah, i mean, if you got a lot of static data, specially string arrays which don't support initializers... :(
You just keep that data inside the resource container and it's less stuff cluttering the script.

But this is on a case-by-case basis. Of course, it depends on your application.

You can create the scripts externally, no need to use a secondary script to generate them, although it's easier sometimes... again, it depends.


----------



## Fredeke (Dec 10, 2019)

P.N. said:


> Yeah, i mean, if you got a lot of static data, specially string arrays which don't support initializers... :(
> You just keep that data inside the resource container and it's less stuff cluttering the script.


It sounds like a very good idea. Of course when I want to change the config, I'd need to re-generate them, but that's a minor hassle.


P.N. said:


> specially string arrays which don't support initializers... :(


Would you educate me as to what initializers are ?

Btw, I don't suppose real arrays are saveable yet ? I guess I could do without them, it would just be more rewrite :-/ 
(Or just offload integers and strings, and keep reals in-script... But that would be awkward)



P.N. said:


> You can create the scripts externally, no need to use a secondary script to generate them


Once again, I'm not sure what you mean.


----------



## P.N. (Dec 10, 2019)

Fredeke said:


> Would you educate me as to what initializers are ?



Constants, variables and arrays can be initialized, aka declared and assigned a value in one line.

declare $x := 1

Strings (both variables and arrays) do not support this.
You need to declare and assign on separate lines.

declare @1
@1 := "string".

Maybe sKSP allows for string initialization (i'd need to check), but after compiling, the generated code will still create all those extra lines.
If you have, let's say... 200 controls (each with control help and automation names), that's 800 lines of code just in string declaration and assignment.

This the the worst case scenario (well, also consider preset names, or sounds, or anything else in a large scale where you'd need a lot of string data).




Fredeke said:


> Btw, I don't suppose real arrays are saveable yet ? I guess I could do without them, it would just be more rewrite :-/
> (Or just offload integers and strings, and keep reals in-script... But that would be awkward)



Good question. I'm not sure if real arrays can be saved. It's not that awkward saving integers and then re-converting them in the script. I actually did that not long ago (because i wanted to keep integer and float data in the same array).




Fredeke said:


> Once again, I'm not sure what you mean.



If you want to create and array, you can use a simple text editor like notepad++.
There are some rules for making the nka compatible with Kontakt, though.

For example, the first line must include the array name, and the last line must be left empty.
Some attention must be taken in order to keep the line breaks compatible too, i think.

Honestly, i don't remember all the rules... i just write them down and they normally work.
Maybe tweak the EOL conversion if it doesn't seem to be working correctly. (if it's set to LF (Unix), try CR LF (Windows)).
Normally one of those works.


----------



## Fredeke (Dec 10, 2019)

P.N. said:


> Constants, variables and arrays can be initialized, aka declared and assigned a value in one line.


I get it. It's less of an issue in the case of a large string array (like I use here), because I couldn't condense all content in one line anyway. (And yes, hundreds of lines of declaration - you're just twisting the knife in my wound )



P.N. said:


> Good question. I'm not sure if real arrays can be saved. It's not that awkward saving integers and then re-converting them in the script. I actually did that not long ago (because i wanted to keep integer and float data in the same array).


Sure, there are several ways around that. In this case, since all the reals I use span from -24.00 to +24.00 (yes, it's just semitones.cents), I could just multiply everything by 100 and use integers. Reals seemed a simpler choice at some point, but if they become a complication, I could dispense with them easily.



P.N. said:


> If you want to create and array, you can use a simple text editor like notepad++.


Ah, yes. You're talking about manually writing an nka in a text editor. I never opened one as text to see what it was made of (I did that with the PHP equivalent, and it was so compacted, I wouldn't dare to edit it by hand). But if it is Human friendly enough, then yes that would be an excellent solution. Probably more convenient than a KSP script actually !

I had another idea, but probably won't implement it because your suggestion seems better: since I never need the whole content of the arrays at once, but only load one preset at a time, I could PGS its declaration to another script, and then just pass the values I need, when I need them. The master script would ask for an index through PGS, and the config script would return a value the same way.

But if your solution solves the stack overflow issue, then it's just better.

Ok, I've got some work to do...


----------



## P.N. (Dec 10, 2019)

Fredeke said:


> Ah, yes. You're talking about manually writing an nka in a text editor. I never opened one as text to see what it was made of (I did that with the PHP equivalent, and it was so compacted, I wouldn't dare to edit it by hand). But if it is Human friendly enough, then yes that would be an excellent solution. Probably more convenient than a KSP script actually !



You could try this example. Quick and dirty (don't mind the all caps names).



Spoiler: CODE





```
on init
    make_perfview
    
    declare $counter
    declare $async_id := -1
    
    declare ui_button $NEXT_LINE
    declare ui_button $LOAD
    
    declare ui_label $TEXT (4, 1)
    
    declare const $BUFFER_SIZE := 4
    declare !buffer[$BUFFER_SIZE]
end on

function displayText
    set_text($TEXT, !buffer[$counter])
end function

on ui_control($LOAD)
    $counter := 0
    $async_id := load_array(!buffer, 0)
end on

on ui_control($NEXT_LINE)
    inc($counter)
    
    if($counter >= $BUFFER_SIZE)
        $counter := 0
    end if
    
    call displayText
end on

on async_complete
    if($async_id= $NI_ASYNC_ID)
        $async_id := -1
        
        call displayText
        $LOAD := 0
    end if
end on
```




And use the attached nka to test it. It was created manually.
When in doubt, use Notepad ++, check the lines, the EOL and it should work without too many issues.



Fredeke said:


> I had another idea, but probably won't implement it because your suggestion seems better: since I never need the whole content of the arrays at once, but only load one preset at a time, I could PGS its declaration to another script, and then just pass the values I need, when I need them. The master script would ask for an index through PGS, and the config script would return a value.



Yes, you can pass string data with PGS too, i think i posted that as an example somewhere on this forum.
But... yeah, it's overcomplicating a bit, i think.


----------



## Fredeke (Dec 10, 2019)

P.N. said:


> And use the attached nka to test it. It was created manually.
> When in doubt, use Notepad ++, check the lines, the EOL and it should work without too many issues.


I get it. It's super simple!

Now, all I need to be careful about is to keep all NKAs line-synced. Because element X of one array needs to correspond to element X of other arrays. Since professional text editors show line numbers, that shouldn't be too difficult.
Would you happen to know of a text editor that can show different files in different columns, and scroll them all in sync, per chance? I guess I could code that myself, but that would become a rather long detour... Oh wait, maybe I should investigate using a spreadsheet editor and then renaming .csv files into .nka


----------



## P.N. (Dec 10, 2019)

Fredeke said:


> Would you happen to know of a text editor that can show different files in different columns, and scroll them all in sync, per chance?



No, but if your script allows for the creation of arrays that follow a logical element sequence, than you don't need to worry too much about it, i think...



Fredeke said:


> I guess I could code that myself, but that would become a rather long detour... Oh wait, maybe I should investigate using a spreadsheet editor and then renaming .csv files into .nka



I wonder what you're doing over there.


----------



## Fredeke (Dec 10, 2019)

P.N. said:


> I wonder what you're doing over there.


I store presets in arrays. Since presets have more than one parameter, there's one array per parameter. First I tried defining a preset's content as a struct, and then declaring an array of structs, but it caused endless problems so now it's just a bunch of loose arrays.

Anyway, I think I'll just convert my presets script (which is already an import) into an nka-generating script. In this case, it's still the simplest way.

Thanks for all your help.


----------



## EvilDragon (Dec 10, 2019)

P.N. said:


> Maybe sKSP allows for string initialization (i'd need to check)



It does, both for strings and string arrays.


----------



## Lindon (Dec 10, 2019)

Fredeke said:


> @Lindon: *if 1=1*: Could you please elaborate? I used to know but I forgot what it is. I often comment out parts of the code to see how it goes, and I suppose if 1=1 is a similar technique?



Well you dont seem to need it in this case but just in case you do at some future point...

so the KSP parser will barf when there are too many lines of code in the INIT call back...a way around this is to place some of your code inside an if statement (which the parser doesnt mind - really go figure that out..) 

So you end up with this sort of thing in your init 

if (1=1)
(some declaration code etc in here)
end if


But as I say it would seem that is not your problem right now. - sounds like its really a design issue.....


----------



## Fredeke (Dec 10, 2019)

Lindon said:


> Well you dont seem to need it in this case but just in case you do at some future point...
> 
> so the KSP parser will barf when there are too many lines of code in the INIT call back...a way around this is to place some of your code inside an if statement (which the parser doesnt mind - really go figure that out..)
> 
> ...


So you're saying placing parts of the script inside _if (1=1)_ statements probably makes it create more but smaller stacks internally?


----------



## Patrik Herman (Dec 10, 2019)

Fredeke said:


> So you're saying placing parts of the script inside _if (1=1)_ statements probably makes it create more but smaller stacks internally?


Check this link out:








Kontakt Scripting (KSP) :: Troubleshooting :: parser stack overflow error (workaround)


If working on big Kontakt projects with large code segments inside the on init you may get confronted with the "parser stack overflow" error. This ...




blog.yummybeats.com


----------



## Fredeke (Dec 10, 2019)

Patrik Herman said:


> Check this link out:
> 
> 
> 
> ...


Very clear, thanks !!!

So I tried splicing the ICB into if (1=1) statements _that are shorter than 900 lines_ (which I didn't do before). And... It made a difference: Now there's no more stack overflow, but the first bug (the one I wrote about in the opening of this thread) is back! The way I got rid of that bug the first time was by upgrading from K5.7 to 5.8, so... I guess I'll try 6.2?

Fortunately, these issues only arise when I increase arrays sizes past my present needs - but by just a tad!
So, threading so close to a breaking point still worries me.

Note that my ICB doesn't get near the 11000 lines limit. But the whole script is now 13000 lines and still needs to get much bigger. Should that worry me as well?

One more question: does anyone know if Kontakt's parser scales its capabilities to the computer's capabilities? Because I'm working in a virtual machine. I find that more comfortable, as long as I don't need to output actual sound (and for now I'm just working on the UI). I don't suppose this could be the cause to my problems?
(Note that the virtual machine has 16Gb of virtual RAM. But of course it is still slow compared to actual hardware.)


----------



## EvilDragon (Dec 10, 2019)

Fredeke said:


> does anyone know if Kontakt's parser scales its capabilities to the computer's capabilities?



I don't think it does. Parser stack is likely a fixed size. 16 GB of virtual RAM is still plenty, but it is of no consequence when we don't know how big KSP parser stack is.

I would really like to check the script out, you must be doing something weird in there...


----------



## Fredeke (Dec 11, 2019)

EvilDragon said:


> I would really like to check the script out, you must be doing something weird in there...


I too feel like that, because length and complexity have got out of hand. I'll PM you a zip.


----------



## Fredeke (Dec 11, 2019)

Like @P.N. , @EvilDragon advises me to load external NKAs. That's what I'm going to do.

Thank you all.


----------



## Fredeke (Jan 9, 2020)

Ok, after a pause to let my brain cool off, I'm tackling this again.

I've been following advices, but I can't manage to read NKAs right.

Here's the bit of my code dealing with that:

```
on persistence_changed
  if (NKA_SAVE = 0)
    load_array (_drone_pitch, 2)
    load_array (_drone_type, 2)
    load_array (_drone_defTk, 2)
    load_array (_track_gp, 2)
    load_array_str (_track_name, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_track_name.nka")
    load_array_str (_drone_name, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_drone_name.nka")
    load_array_str (_drone_group, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_drone_group.nka")
    print (num_elements (!_drone_name))
    for $i := 0 to num_elements (!_drone_name) -1
      print ($i & ":  " & !_drone_name [$i])
    end for
  end if
  iterate_macro (clear_mixer_tracks) := 1 to 6         // not
  call update_source                                                   // really
  call toggle_panels                                                      // relevant
end on

on ui_control ($bt_save)
  save_array (_drone_pitch, 1)
  save_array (_drone_type, 1)
  save_array (_drone_defTk, 1)
  save_array (_track_gp, 1)
  save_array_str (_track_name, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_track_name.nka")
  save_array_str (_drone_name, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_drone_name.nka")
  save_array_str (_drone_group, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_drone_group.nka")
  print (num_elements (!_drone_name))
  for $i := 0 to num_elements (!_drone_name) -1
    print ($i & ":  " & !_drone_name [$i])
  end for
end on
```

The idea is to save the arrays that were already populated in KSP to NKAs, then comment out the populating part (to releive the parser, which was running its stack too close to the limit), leaving only array declarations, and load the content from the NKAs instead.

Only, when I load the string NKAs, they appear to be just full of zeroes or empty strings. Er... Like they didn't load and are still as just declared.

According to the debugger, the arrays' content is right before saving, but it's not after loading. The content of the files looks fine in a text editor, so the error must happen at loading. It is the same regardless of type, string or integer.

Can you see anything wrong with the code ?


----------



## P.N. (Jan 9, 2020)

You should check the async status and update from there.


----------



## Fredeke (Jan 9, 2020)

Mmh... I'm such a noob. I did know that but I forgot. (probably let my brain cool off too much)

The doc says load_array is synchronous when used in the ICB (though we should mind persistence issues). So I tried that because it was simpler, and I only need to load them once at instrument launch anyway.

It half worked: now some arrays load, others still don't.

I know it looks like the problematic arrays are persistent, but they're not. In fact, it's more like string arrays get loaded, but not integer arrays. Puzzling...

I don't suppose all those arrays being declared as multi-dimensional in sKSP has anything to do with this?


----------



## EvilDragon (Jan 9, 2020)

If you're loading from ICB, you need to first read_persistent_var on all those arrays, then load_array.

I haven't yet stumbled upon a case where this didn't work.


----------



## Fredeke (Jan 9, 2020)

EvilDragon said:


> If you're loading from ICB, you need to first read_persistent_var on all those arrays, then load_array.
> 
> I haven't yet stumbled upon a case where this didn't work.


I've followed your advice for the sake of trying everything, but since none of these arrays are persistent, it didn't solve anything.

Then I figured I should use mode 1 instead of mode 2 for load_array: surely it would never work trying to load from the wrong place! But even after correcting this, integer arrays still don't load.


----------



## EvilDragon (Jan 9, 2020)

If you use mode 1 then you cannot load from Resources folder.


----------



## Fredeke (Jan 9, 2020)

I want to load from the Data folder, located alongside the Resources folder and resources container (see the path for string arrays, which now load perfectly).

That's mode 1, right?

Mode 2 would load from inside the .nkr container file... Right?

This is a tad confusing, I must admit.


----------



## EvilDragon (Jan 9, 2020)

Yeah if you're loading from Data folder _outside_ of Resources folder, then you should use mode 1 everywhere.


----------



## Fredeke (Jan 9, 2020)

EvilDragon said:


> Yeah if you're loading from Data folder _outside_ of Resources folder, then you should use mode 1 everywhere.


I'd like this line:
_ load_array (_drone_pitch, 1)_

to load from an nka located just alongside this other one:
_ load_array_str (_drone_name, get_folder ($GET_FOLDER_PATCH_DIR) & "/Data/_drone_name.nka")_

Is there anything wrong in these two lines, that would make them try to load from different folders?


----------



## EvilDragon (Jan 9, 2020)

You might as well use load_array_str() for all those arrays then?

You can always check if your load command is correct by doing it from a button's UI callback, then checking $NI_ASYNC_EXIT_STATUS in async_complete callback.


----------



## Fredeke (Jan 9, 2020)

EvilDragon said:


> You might as well use load_array_str() for all those arrays then?


You mean load everything as string arrays, and then copy the relevant ones into integer arrays, with a conversion inside a loop? Sure, that would get me out of the woods fast, but... I don't see a string_to_int() command in the doc... am I not looking hard enough?



EvilDragon said:


> You can always check if your load command is correct by doing it from a button's UI callback, then checking $NI_ASYNC_EXIT_STATUS in async_complete callback.


This takes a little more programming... I'll let you know how this turns out if your first trick doesn't work.


----------



## EvilDragon (Jan 9, 2020)

load_array_str() does NOT mean it's only used for loading string arrays. You can load any NKA with that command. "_str" means it takes a string as argument, the path from which you want the NKA to load.


----------



## Fredeke (Jan 10, 2020)

EvilDragon said:


> load_array_str() does NOT mean it's only used for loading string arrays. You can load any NKA with that command. "_str" means it takes a string as argument, the path from which you want the NKA to load.


That's great news (in addition to making more sense) !
It should solve the issue.


----------



## McSound (Jan 14, 2020)

I had just the same issue. The solution was easy. There're can only be 996 lines In the on init callback. If your code is bigger then do the next trick:

on init
996 lines
if 1=1
next 996 lines
end if
if 1=1
other next 996 lines
end if
end on


----------



## EvilDragon (Jan 14, 2020)

It depends on what you're doing in your init callback. You can have more than 996 lines in there (I've written larger ones).

Anyways 1=1 is a crutch and you should figure out better ways of initializing your UI widget properties if you're stumbling upon this sort of thing.


----------

