LScript "Wish List"

distrakt

New member
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
 

ArtHowe

New member
Once again, I would like to thank everyone for the continued feedback and let you know that we're still reading them!

Art
 

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
 

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.
 

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.
 

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
 

GregMalick

New member
I ask for:
Non-modal panels in generic Layout LScripts. (or please tell me how to do this) :D

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.
 

Matt

Valiant NewTeKnight
GregMalick said:
As already requested, knowing the X/Y X/Z XYZ Y/Z etc coordinates of the mouse in a viewport is important. ... But at least give LScript that capability to intercept the keys.

Good call, this would allow LScripts to integrate themselves more within the LightWave inteface, one of my gripes with having too many features as add-ons is that it makes LightWave fragmented.
 

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
 

NanoGator

Avatar VAD
I'd like to have what i need to rewrite Skelegon tree. To date, I haven't been able to ask a skelegon its name or change it for that matter.
 

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
 

carllooper

New member
Lightwolf said:
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

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
 

Lightwolf

obfuscated SDK hacker
carllooper said:
Just had a look at Lua. Very interesting. I love that sort of thing.
Me too. I had a look due to DF / Eyeon using it, and the integration is extremely tight. Very cool stuff. They managed to whip out fully fledged scripting support in just one release.
...Now compare that to LScript... ouch.

Cheers,
Mike
 

carllooper

New member
Lightwolf said:
Me too. I had a look due to DF / Eyeon using it, and the integration is extremely tight. Very cool stuff. They managed to whip out fully fledged scripting support in just one release.
...Now compare that to LScript... ouch.

Cheers,
Mike


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

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
 

fortress

New member
ok here is one of my wishes that im sure has been covered

redo the docs and add a ton of samples and examples please.
 
Top Bottom