LScript "Wish List"
- Thread starter ArtHowe
- Start date
quad stockpiling
Here is an excerpt of comment from a script, supporting the reiterated request:
"We want to be able to script everything that Modeler can do, please."
This is either a documentation issue or a functionality issue, either way...
// |
// | Turns out we cannot, in LScript, create a point and
// | add it to the TEXTURE map. This is tragic! So we rely
// | on having a stockpile of quads already in the map.
// | We can change their UV values, and will. But they
// | have to already exist.
// |
// | So, before running script, you must have bunches
// | of unconnected quads sitting around, all TEXTURE
// | mapped.
// |
--> david
Here is an excerpt of comment from a script, supporting the reiterated request:
"We want to be able to script everything that Modeler can do, please."
This is either a documentation issue or a functionality issue, either way...
// |
// | Turns out we cannot, in LScript, create a point and
// | add it to the TEXTURE map. This is tragic! So we rely
// | on having a stockpile of quads already in the map.
// | We can change their UV values, and will. But they
// | have to already exist.
// |
// | So, before running script, you must have bunches
// | of unconnected quads sitting around, all TEXTURE
// | mapped.
// |
--> david
carllooper
New member
LScript 2 C
Why can't a plugin written in LScript be machine translated into C?
In principle, a plugin written in lscript could be machine translated into one written in C, but the result wouldn't be any more efficient. The speed benefits associated with C have more to do with the greater set of choices that C makes available to the programmer. But once a program is written those choices are no longer available. It is the programmer that produces optimised code through the choices he or she makes. All the language does is provide more or less choices. And relative to LScript, C provides more choices.
So a machine that takes a plugin written in LScript and trys to optimise it through rewriting it in C would have to decide what sort of choices could be made had the plugin been written in C instead of the choices that were made having been written in LScript. And it would have to make the right choices, ie. those that lead to more efficient code rather than less.
In other words the machine would need to possess the same cunning and ingenuity we otherwise associate with programmers.
Carl
Why can't a plugin written in LScript be machine translated into C?
In principle, a plugin written in lscript could be machine translated into one written in C, but the result wouldn't be any more efficient. The speed benefits associated with C have more to do with the greater set of choices that C makes available to the programmer. But once a program is written those choices are no longer available. It is the programmer that produces optimised code through the choices he or she makes. All the language does is provide more or less choices. And relative to LScript, C provides more choices.
So a machine that takes a plugin written in LScript and trys to optimise it through rewriting it in C would have to decide what sort of choices could be made had the plugin been written in C instead of the choices that were made having been written in LScript. And it would have to make the right choices, ie. those that lead to more efficient code rather than less.
In other words the machine would need to possess the same cunning and ingenuity we otherwise associate with programmers.
Carl
GregMalick
New member
This is my understanding.
LScript is an interpreted language, even when you compile it.
The bottom line is that a compiled C plugin runs about 10 times faster than LScript.
If someone could somehow translate it, it would run faster.
I just think there isn't enough interest by programmers to do it.
Those with C plugin skills don't need the translation.
But it's an interesting idea.
just my two cents.
And I'm sure that Art of H2MW will correct me if I'm totally mistaken.
LScript is an interpreted language, even when you compile it.
The bottom line is that a compiled C plugin runs about 10 times faster than LScript.
If someone could somehow translate it, it would run faster.
I just think there isn't enough interest by programmers to do it.
Those with C plugin skills don't need the translation.
But it's an interesting idea.
just my two cents.
And I'm sure that Art of H2MW will correct me if I'm totally mistaken.
spud_q
New member
I'm not sure as I understand why you want LScript to use C. Am I wrong in understanding that Lightwave plug-ins are written in C? Since you have a lot more power and options when using the SDK and you know C, why use LScript. I'm dying to get started writing plug-ins but I use LScript because I don't know C and have no C compiler. Am I wrong about all of this?
GregMalick
New member
I interpreted the discussion to be about having a utility that could translate LScript (which is just text) to C which you could then compile (free C compilers are available). Once you got the LScript working, you use the utility which would make a new source file and when compiled it would run 10 times faster.
Not a bad idea.
Not sure it can be done.
It would definitely have to be a little smart to detect the type of architecture and then use the appropriate structure.
Not a bad idea.
Not sure it can be done.
It would definitely have to be a little smart to detect the type of architecture and then use the appropriate structure.
carllooper
New member
> If someone could somehow translate it, it would run faster.
By way of analogy - one can shoot a video of something and shoot a 35mm film of the same thing. Certainly the 35mm film will exhibit higher resolution than the video. But this does not mean translating the video to film will result in a higher definition image.
On the otherhand, working with video is a lot simpler than working with film.
Carl
By way of analogy - one can shoot a video of something and shoot a 35mm film of the same thing. Certainly the 35mm film will exhibit higher resolution than the video. But this does not mean translating the video to film will result in a higher definition image.
On the otherhand, working with video is a lot simpler than working with film.
Carl
GregMalick
New member
I ask for:
Non-modal panels in generic Layout LScripts. (or please tell me how to do this)
I'm also seeing new plugins (like joytrol and that new painting program) that should be able to join the view port list (at least in layout). These new views could be added at the end of the list and would be locked in place, and have the maximize and other controls (zoom/move/rotate) the normal views have. The LScipt or plugin could then disable view controls that do not make sense for that script/plugin.
As already requested, knowing the X/Y X/Z XYZ Y/Z etc coordinates of the mouse in a viewport is important. Also the mouse press event that occured (Layout & Modeler) i.e. LMB-down, keyDown, keyUp, MMB-up etc. Along the same lines increase the combinations of hot keys. i.e.ctl-shift-a ctl-alt-a etc But at least give LScript that capability to intercept the keys.
Non-modal panels in generic Layout LScripts. (or please tell me how to do this)
I'm also seeing new plugins (like joytrol and that new painting program) that should be able to join the view port list (at least in layout). These new views could be added at the end of the list and would be locked in place, and have the maximize and other controls (zoom/move/rotate) the normal views have. The LScipt or plugin could then disable view controls that do not make sense for that script/plugin.
As already requested, knowing the X/Y X/Z XYZ Y/Z etc coordinates of the mouse in a viewport is important. Also the mouse press event that occured (Layout & Modeler) i.e. LMB-down, keyDown, keyUp, MMB-up etc. Along the same lines increase the combinations of hot keys. i.e.ctl-shift-a ctl-alt-a etc But at least give LScript that capability to intercept the keys.
carllooper
New member
LScript Native Interface
1. What I'd like to see, in addition to the available documentation (speaking of which - the Newtek inks to the pdfs have disappeared) is docs on the LScript Native Interface made public again.
2. I'd like to see development of LScript's native interface. This is not a criticism - the current native interface works extremely well. But it would be good to see some LNI functions that expose Lightwave's C interface, ie. so LScript native extensions can call back into Lightwave's existing functionality (the same as native plugins acting directly through the C interface). In the simplest case this would just mean the LNI passing LScript extensions the GlobalFunc pointer that is given to plugins.
3. I'd like to see an addition to the LNI where function calls into native object agent librarys did not directly reference OAL functions but used the same mechanism that OAL data uses, ie. through a common port. All data refererences from LNI go through an OAL's returndata() and assigndata() callbacks - which allows the OAL itself to runtime modify the names of data. If the LScript engine could route all function calls through a common port as well, it means an OAL could likewise runtime modify function names.
4. Control over how LScript is interpreted. A scriptable preprocessor? For example, I'd like to allow for the embedding of code (in a language other than LScript) within LScript. The LScript engine could runtime replace the embedded code with calls to native functions (which could be passed the embedded code as an argument to those native functions), etc.
5. Inheritance etc.
6. That's all for the time being.
Carl
1. What I'd like to see, in addition to the available documentation (speaking of which - the Newtek inks to the pdfs have disappeared) is docs on the LScript Native Interface made public again.
2. I'd like to see development of LScript's native interface. This is not a criticism - the current native interface works extremely well. But it would be good to see some LNI functions that expose Lightwave's C interface, ie. so LScript native extensions can call back into Lightwave's existing functionality (the same as native plugins acting directly through the C interface). In the simplest case this would just mean the LNI passing LScript extensions the GlobalFunc pointer that is given to plugins.
3. I'd like to see an addition to the LNI where function calls into native object agent librarys did not directly reference OAL functions but used the same mechanism that OAL data uses, ie. through a common port. All data refererences from LNI go through an OAL's returndata() and assigndata() callbacks - which allows the OAL itself to runtime modify the names of data. If the LScript engine could route all function calls through a common port as well, it means an OAL could likewise runtime modify function names.
4. Control over how LScript is interpreted. A scriptable preprocessor? For example, I'd like to allow for the embedding of code (in a language other than LScript) within LScript. The LScript engine could runtime replace the embedded code with calls to native functions (which could be passed the embedded code as an argument to those native functions), etc.
5. Inheritance etc.
6. That's all for the time being.
Carl
Lightwolf
obfuscated SDK hacker
O.k., this may sound like a heresy, but in the long term I'd like to see LScript replaced by something like, for example Lua (www.lua.org) . Not only does it fit well into the environment (DF uses it, as well as tons of games), but you can also get generic books on it.
Cheers,
Mike
Cheers,
Mike
carllooper
New member
Lightwolf said:
Just had a look at Lua. Very interesting. I love that sort of thing. Might be worth having an experiment - imbedding it as a plugin - if only as a test.
I've been experimenting with java bindings for LW.
Carl
carllooper
New member
Lightwolf said:
Lau
Java
C++
I think it's worth looking at all three simultaneously. There will be an underlying specification that one could develop (in relation to all three) that could then be used to implement any one of them. Or all of them!
carllooper
New member
Java Plugins
I embedded the java virtual machine within a Lightwave plugin. I call the plugin "LavaLight". It handles the interface between Lightwave and Java written plugins.
All calls, from java written plugins, into Lightwave are just java wrapped native calls.
Lightwave itself doesn't see the java written plugins. What it sees is a "pilot" (which is just a normal plugin) runtime generated when the java written plugin is installed.
Each java written plugin has it's own corresponding pilot.
The pilot acts as the "front end" for the java written plugin. All calls from Lightwave into the java written plugin are via this pilot.
LavaLight is not available for public consumption. It's an experiment - or "proof of concept" exercise. And it works fine.
Carl
Karmacop said:java bindings for LW? That has me interested
I embedded the java virtual machine within a Lightwave plugin. I call the plugin "LavaLight". It handles the interface between Lightwave and Java written plugins.
All calls, from java written plugins, into Lightwave are just java wrapped native calls.
Lightwave itself doesn't see the java written plugins. What it sees is a "pilot" (which is just a normal plugin) runtime generated when the java written plugin is installed.
Each java written plugin has it's own corresponding pilot.
The pilot acts as the "front end" for the java written plugin. All calls from Lightwave into the java written plugin are via this pilot.
LavaLight is not available for public consumption. It's an experiment - or "proof of concept" exercise. And it works fine.
Carl