PDA

View Full Version : Compiled scripts on 7.5(a)



jagoca
10-19-2003, 01:34 PM
Hi!

A few weeks ago, I released a couple of scripts which were compiled on 7.5c, since they used some of the LScript 2.6 features. However, many users don't want to update to 7.5c, so they can't use them...

It also has the problem of not working under Macs, although some users said me that this could be fixed simply re-compiling under version 7.5(a)

Is this true?

If so, I would be able to recompile to 7.5, simply tweaking a little the code and self-writing some now hardcoded routines, but I prefer being sure of that all work will get any profit!

I think it's a pitty these tools couldn't be used by all the users!

Please, help!

Thanks in advance

#lwrs_web
10-20-2003, 04:14 AM
Compiled scripts have always been a problem. I would suggest not to release as .lsc. I don't even download compiled scripts anymore.

Having the sourcecode gives the users much more freedom.

If you really think your sourcecode is such a big secret, then better write SDK plug-ins.

;-)

jagoca
10-20-2003, 05:41 AM
However, I have long used lots of .lsc and never had problems.

I can't understant why the compiling process procudes all these problems. It should be something as simple as encrypting the source with comments removed or something like that.

I'm learning SDK now, but the level of difficult introduced is awesome! Moreover, I wouldn't be able to release Mac versions of future plugins, since I don't own a mac, nor I'm going to purchase one only for this.

As I said, LScripts are supossed to be fully compatible. My only hope is all this being fixed in LW8. Otherwise, many people's work will be being thrown to the garbage :-O

Bye.

UnCommonGrafx
10-20-2003, 06:49 AM
For those who can't use it, it would behoove them to update their system to work with your script. *.lsc are part of the system and they work for the majority of people.
The SDK route would be optimal but as you said, it's a big mountain to climb.
It's not your place to defend the programmers, anyway. :D

Make great plugs as you see fit. Those who can't, won't; those who can, will enjoy. :cool:

fxnut
10-20-2003, 11:10 AM
Originally posted by jagoca
I can't understant why the compiling process procudes all these problems. It should be something as simple as encrypting the source with comments removed or something like that.
Do some research on how scripting engines work by using "virtual machines" and you'll understand. Compiling turns the script into a custom written assembly language to work with the LScript virtual machine (I'm assuming (hoping) that Lscript does actually use a VM). Hence if changes are made to the basic assembly language between versions of LScript, then problems will obviously occur.

But I think it's also a case of the problem with maintaining the scripting language to cope with updates to the Lightwave SDK. When something changes inside the SDK, it can have knock on effects and large implications for LScript.

I also think that the other problem is that LScript hasn't been written too well on the error checking front. It lets a heck of a lot of dodgy stuff through sometimes, so as these holes get plugged with each new version, scripts that used and abused these holes stop working.

#lwrs_web
10-20-2003, 11:31 AM
Originally posted by fxnut
Do some research on how scripting engines work by using "virtual machines" and you'll understand. Compiling turns the script into a custom written assembly language to work with the LScript virtual machine (I'm assuming (hoping) that Lscript does actually use a VM). Hence if changes are made to the basic assembly language between versions of LScript, then problems will obviously occur.


The LScript runtime system doesn't work this way. Compiling a script converts it into bytecode which is parsed just in time just like a normal script.

The only purpose of compiling LScripts is to hide the sourcecode (and/or to directly include images).

fxnut
10-20-2003, 12:58 PM
Originally posted by #lwrs_web
The LScript runtime system doesn't work this way. Compiling a script converts it into bytecode which is parsed just in time just like a normal script.

Umm... that's exactly what I meant by "custom written assembly language". Byte code is exactly that; a custom assembly language written specifically for a virtual machine created by the programmer.

#lwrs_web
10-20-2003, 08:20 PM
Originally posted by fxnut
Umm... that's exactly what I meant by "custom written assembly language". Byte code is exactly that; a custom assembly language written specifically for a virtual machine created by the programmer.

Ok, but I think the LScript bytecode is more a 1:1 representation of the sourcecode. Converting something to an assembly language usually means to convert a single high level command into several lower level commands.

fxnut
10-21-2003, 02:06 AM
Originally posted by #lwrs_web
Ok, but I think the LScript bytecode is more a 1:1 representation of the sourcecode. Converting something to an assembly language usually means to convert a single high level command into several lower level commands.

Right okay, well I couldn't comment on that, since I'm not privvy to that information. Actually, if LScript is more of a 1:1 representation of the source code then that would explain why it often causes bugs and crashes whenever the SDK is updated. I'd have thought that using a lower level representation would in theory make it less likely to suffer compatibility issues for compiled scripts whenever the SDK is changed, or fundamental changes are made to syntax, etc.

BTW, where did you get your information from regarding the fact that it's a 1:1 representation? Have you talked to Bob?

#lwrs_web
10-21-2003, 06:00 AM
This is from the LScript mailing list:


From - Sat Apr 07 17:17:41 2001
From: Bob Hood <[email protected]>
Delivered-To: mailing list [email protected]

> LScripts are interpreted; C plug-ins are not. Assuming it is written
> correctly, a C plug-in will always run faster than a script. Further,
> it will also consume far less computer memory than a script (again,
> assuming it is written corretly). There's an extra layer of translation
> that takes place for scripts that doesn't exist for C plug-ins.
>
> I liken it to a conversation. If you speak with somebody in your
> native tongue (i.e., a C plug-in to the processor), then you can speak
> very quickly. However, if you must converse with somebody who doesn't
> understand your language, then you must use an interpreter. Using
> an interpreter (i.e., script to LScript to the processor), the
> conversation will take place much more slowly.
>
> Compiling scripts does NOT covert them into the same binary as C plug-ins.
> They are converted into their compiled form (i.e., bytecode), and are then
> encrypted to prevent reverse engineering. You can optionally compress
> them, which adds a further layer of security because I don't use a
> compression algorithm that is well-known. Compiling an LScript means
> that it is secure for distribution, not that it runs or loads any faster
> than would the source form.
>

fxnut
10-21-2003, 07:20 AM
I still can't see how you inferred from that that its more of a 1:1 representation than the more traditional lower level byte code (like the Java VM for example).

#lwrs_web
10-21-2003, 09:16 AM
Another message from Bob Hood.

> The bytecode in the LSC file
> is ready to be run by the interpreter. As such, it is not in a sequence
> that linearly matches the original ASCII script file. Things get
> re-arranged a bit in the "code" segment to make the interpretation go
> fast, and some things are arranged to make the expressions easier for the
> machine to understand.


If it's more or less the same doesn't matter for me.

Compiled scripts are a pain for the developer to maintain accross different LS/LW versions as well as for the users who have problems running them.

I don't release compiled scripts to the public.

If I write a script for a studio I first give them a compiled script to test and when they have payed me they get the source.

jagoca
10-21-2003, 11:00 AM
But what can I do when anybody is going to pay for my scripts?

Doesn't matter if someone uses my code from a tiny app, but there are cases in which finding the right answer took me weeks, since I'm a beginner in all these tasks.

And I don't want people ripping my code, moreover if they are going to charge for that!

fxnut
10-21-2003, 03:47 PM
Originally posted by #lwrs_web

If I write a script for a studio I first give them a compiled script to test and when they have payed me they get the source.
Hmm, that's a good idea.

fxnut
10-21-2003, 03:51 PM
Originally posted by jagoca
But what can I do when anybody is going to pay for my scripts?


Well if it was just a one off job for a client, you could get them to pay you for each version you made work for each new version of LScript.

For my Camera Director script, I'm just gonna make sure I maintain it and provide links for people to download previous versions that work with older LScript implementations. As long as the file IO doesn't change, it shouldn't cause too much hassle for people.

A word of warning though; think carefully before making an Lscript embedded in a scene file. Upgrading to a new version of LScript could mean that you lose the scene file (or have to edit it by hand to get it to work)

jagoca
10-22-2003, 01:50 AM
But what can I do when anybody is going to pay for my scripts?


Excuse my english, I wanted to say "when nobody is going to pay for my scripts..." :(