TorqueScript 2

Scripting questions, discussions, etc
21 posts Page 2 of 3
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Nov 02, 2015 10:57 pm
KorkScript, duh.
MangoFusion
Posts: 50
Joined: Wed Feb 04, 2015 12:00 am
by MangoFusion » Sat Nov 07, 2015 10:06 am
Yo guys, just an update.

While I was going to push stuff out last weekend, I bumped into a little problem with the console interop which put a spanner in the works (i.e. i have to refactor stuff earlier than I thought). My current initial release goal is sometime tomorrow.

@
User avatar
rlranft


Arrays are just types with accessor implemented for []. ATM I just have a simple array of console values type. You could implement a lua table fairly easily.

@
User avatar
chriscalef


All numbers are F64s, and they aren't converted to strings unless neccesary (e.g. for concat operators and string accessors). So there should be less of a problem.
chriscalef
Posts: 381
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Sat Nov 07, 2015 6:17 pm
Ah, that's good to hear, @ MangoFusion! Keep them as floats the whole time, what a thought! :)
MangoFusion
Posts: 50
Joined: Wed Feb 04, 2015 12:00 am
by MangoFusion » Tue Nov 10, 2015 1:59 am
Just another update...

I'm taking the time to address another long-standing the torquescript interop has... namely with strings. Usually Con::getData, Con::getVariable and such return "const char*" pointers, sometimes to temporary strings and sometimes to dynamic strings. The problem however is there are no guarantees placed on if this pointer remains valid, especially if you call another console-related function. This leads to all sorts of weird hacks in various places in the engine in order to account for parameter values being clobbered.

Basically instead of this...

Code: Select all

const char* myStringValue = Con::getVariable("$whatever"); // Do something with myStringValue, assuming it wont ever change (it *might*)
You do something like this...

Code: Select all

ConsoleStringValuePtr value = Con::getVariable("$whatever"); const char* myStringValue = result.c_str(); // myStringValue remains constant as long as value still exists on stack
In some ways this is similar to the String type in T3D (or your classic std::string), though I am aiming to wrap in support for static unallocated strings, as well as a sensible allocator for small strings into this too.
MangoFusion
Posts: 50
Joined: Wed Feb 04, 2015 12:00 am
by MangoFusion » Mon Nov 16, 2015 1:24 pm
Another update...

I've finished refactoring everything to use the new interfaces, just dealing with a few regressions of behaviour.

Hopefully should push something initial to one of my branches some time this week. 8-)
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Nov 16, 2015 4:13 pm
<3
Johxz
Posts: 447
Joined: Sat Feb 07, 2015 11:37 pm
by Johxz » Mon Nov 16, 2015 4:35 pm
Nice ;)
MangoFusion
Posts: 50
Joined: Wed Feb 04, 2015 12:00 am
by MangoFusion » Fri Nov 20, 2015 3:25 pm
Ok guys, time for an initial push!

There are still a few things to implement and change (e.g. no dso support, exec doesn't work properly), but at this stage I'm reasonably happy to release something in an initial alpha state.

The code as it stands is now located in a branch at https://github.com/jamesu/Torque2D/tree/twistscript

While currently it wont actually load T2D due to a problem loading the modules, it will execute basic scripts (such as test.cs). Also the code is currently only fixed for OSX, so don't expect it to build for windows yet.
MangoFusion
Posts: 50
Joined: Wed Feb 04, 2015 12:00 am
by MangoFusion » Tue Nov 24, 2015 1:10 pm
Just an update on this...

After fixing exec and a few opcodes, it can now execute a fair bit into the T2D initialization process (albeit slightly modified to account for the changed array usage). There are however a few issues still preventing it from fully loading, mainly to do with object slots.

I'm currently aiming to get it working so far as to booting everything up before the end of the month - then other stuff such as DSO support can be reimplemented.
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Nov 24, 2015 4:06 pm
Sounding pretty good :D
21 posts Page 2 of 3

Who is online

Users browsing this forum: No registered users and 3 guests