Nameless Voice on 4/12/2017 at 20:14
Quote Posted by Yandros
Warning:If you release a mission which utilizes squirrel script, I highly recommend you include squirrel.osm in your ZIP in the root, along with other script modules. The reason is that GoG.com's Thief2 installer puts it into the /doc folder instead for some reason, which doesn't make much sense to me. Some of their users had issues with DCE because of this, and they have asked me to include it in the next update of DCE, so I would recommend you all do the same. I did suggest they modify their installer to put it in the root, or in wherever the script_module_path is pointing to in their darkinst.cfg file, but I don't know if they will do that.
That sounds like a really bad idea.
You are including a version of a NewDark library that may change if there are future versions.
It's not even beyond reason that the version of the library you've included in your FM may not be compatible with future versions, depending on how interrelated the two are. That's not something that you really have to worry about with normal custom scripts (you just wouldn't get bugfixes), but we don't know how the Squirrel osm actually works or if there are special functions for it to use inside the engine itself.
If people have broken installs, then the proper solution is to get them to fix their installs, and/or to get the patcher tools to fix the problem during patching up. Anything else is a hack that might come back to bite you later.
voodoo47 on 4/12/2017 at 21:04
to make the GOG T2 story short, I wasn't quite sure what to do with the osm when putting together the GOG T2 package, so I've moved it away for the time being (not having it active wasn't really a problem at that point). was aware that some future missions may need it, but didn't quite expect that there would be people that will try to run FMs without patching up with TP (which installs all the scripts that exist, squirrel included).
it will be active again in the next update, in the meantime, all the people running manual/default T2 installs should just move it back to the root (and also check all the other scripts, as they may be missing more than one).
Yandros on 5/12/2017 at 02:20
LOL I didn't realize you did the GoG installer for them, Voodoo. They did reply to me last night and said they had passed my suggestion on to their technical folks for consideration, sound like that might end up coming back to you.
voodoo47 on 5/12/2017 at 16:18
installer no, just a few files inside.
Daraan on 6/12/2017 at 15:46
I'm slowly getting a headache. How does the string() work
From the documeentation:
Code:
local str = string();
if ( Engine.ConfigGetRaw("somevar", str) )
print("the config var was: " + str);
#Result: the config var was:
The str variable remains empty even when using something simple like Version.GetGame(str).
if I use str=string("value"). I just get "value" back after the function call, as if the function did nothing.
I somehow fear that string() is broken.
Nameless Voice on 6/12/2017 at 17:02
Post the code that you're trying to use.
Daraan on 6/12/2017 at 18:05
What I want is to get a string config variable (ConfigGetRaw)
But neither
Code:
str=string()
Engine.ConfigGetRaw("resname_base",str)
print(str)
#Result empty
Nor
Code:
str=string()
Version.GetGame(str)
print(str)
#Result empty
Seam to do anything with their str parameter. The return result is 1 (for success).
EDIT: So either I'm doing something terribly wrong or something with string() is really terribly wrong. (or the functions)
---------------------
Some knowledge i (think) figured out:
string is a class here so string("init") is a class instance
"init" get somewhere stored in it.
I can not iterate it find out where or what's the index name.
when used for example with print(string("init")) it invokes some kinda tostring() function. (also hidden)
Any idea how the get the variables in a class.instance?
---
string and int_ref got in their class body
a constructor func
two empty tables __setTable and __getTable
as well as these two functions
__overload_constructor0 and __overload_constructor1
caffeinatedzombeh on 7/12/2017 at 00:06
I was just half way through writing something that contains most of that.
printing anything invokes its tostring or _tostring function (depending on what it is and whether _tostring exists, that's used to override the built in tostring on something)
I would do a foreach on it, but instances of the string class don't seem to let you do that. (I assume you equally already tried that)
It doesn't to me look like you're doing anything wrong if that helps at all. The rather un-squirrel like syntax of all those functions in the name of making it the same as the c++ version it's a wrapper for.
caffeinatedzombeh on 7/12/2017 at 11:07
Having poked at some stuff not in thief, you can't find out what's in a class instance unless the class implements methods for doing that (and that's normal for squirrel rather than specific to that class which is what I wanted to find out).
if the class has a _nexti function in it then you should be able to foreach over the instance I think, you'd not generally do that unless the class was the sort of thing that you'd want to foreach over rather than just doing it because you want to treat it like a table and see what's in it because someone else wrote it and didn't tell you how it works.
So I'm sticking with my unhelpful answer of that I agree the documentation says you should do what you're doing, it seems consistent with the rest of the script interface documentation and as far as I can see that ought to do what you'd expect. :(
Daraan on 7/12/2017 at 11:45
Definitely a big thank you for looking into it as well.
I want to break it down to the two main possibilities I see at the moment:
Either the function results and 'return' of string are not in sync like
Quote:
script("init")->script.slot1
Function(script)->script.slot2
_tostring()->return script.slot1
We could work around that if we knew the name of slot2
But what I fear has the higher possibility.
OR All the string & functions do not invoke their return part. (Maybe some typo deep inside the same function)
Why I think that? All string & functions don't care/throw when you give them a totally wrong data type as parameters, the others specifically want a int/float_ref, vector.