Can I use Revolution for this?

David Vaughan drvaughan55 at mac.com
Fri Aug 2 20:49:01 EDT 2002


On Saturday, August 3, 2002, at 11:11 , Rodney Somerstein wrote:

> Dan,
>
snip

> My concern isn't related to the size of external files. Rather, it is 
> the limit of how many objects can be created in a standalone after 
> reading the external data. I'm kind of fuzzy on what can and can't be 
> done in a standalone, but it seems that this might be an issue.
>
>>  >Even a small game is likely to have more than 50 pieces. It seems
>>> that I'm going to bump into the limitations of the standalone
>>> environment as each of these pieces would be an object and the  user
>>> needs to be able to script them to a certain extent. Is this a real
>>> concern, or is there a simple workaround?
>>
snip

>  From my reading of the limitations of the starter kit, which is 
> supposed to be the same as for standalones, I'm not sure that I can 
> create this many objects on the fly. In the starter kit, you can only 
> insert 20 objects into the message path. I don't know if this is a 
> cumulative total or means only 20 at one time. I also don't know if I 
> can check when the user issue a mouseDown to see if there is a 
> graphical object underneath the cursor and then add it to the message 
> path or if it already has to be there in order to detect the mouseClick 
> on that object.
>
snip

>> Take the output from this interactive session with the user, stuff it
>> into a RR container object and then "do" the container...and voila!
>
> Again, due to limitations of standalones, I'm not sure that I can stuff 
> do scripts into that many objects. Also, in the starter kit, do scripts 
> can be only 10 lines long. I'm not sure if I'm limited by this when 
> adding scripts to a dynamically created object. The documentation on 
> standalones is frustratingly non-existent except for some comments here 
> on the mailing list. I'll post another message about that. Hopefully 
> Jeanne will have something to say relating to that situation.
>
Rodney

This is interesting, not only for your exploration of what the 
documentation means but how you plan to write your application. To save 
everyone else rushing to the Dictionary, this is written under the 
scriptLimits function and pertains to Rodney's questions:
====
Limits:
Statements permitted when changing a script (normally 10)
Statements permitted in a do command (normally 10)
Stacks permitted in the stackInUse (normally 50)
Number of objects permitted in the frontScripts and backScripts 
(normally 10).

The first number does not limit scripts that are already written. In 
other words, a Starter Kit [standalone] user can use a stack with 
scripts of any length. however, if that stack attempts to change an 
object's script property, and the script contains more than the 
allowable number of statements, the attempt to set the script causes an 
error.

The above limits apply only when you use the Starter Kit. (Standalone 
applications you create with Revolution also have these limitations, 
since standalones are freely distributable and are not themselves 
licensed.) If you are using a licensed copy of Revolution, these limits 
do not apply and the scriptLimits functions returns empty.
====
I created a standalone which simply opened and displayed its limits. In 
my licensed Rev environment, it returned empty. Run as a standalone, it 
returned 10,10,50,10, so the limits are there all right.

However, are they critical to Rodney's need? I do not believe so, in 
that you can create any number of objects of a given script (this is 
quite different from inserting new front and back scripts). Problems 
will arise where you wish to create user-specific scripts of more than 
ten lines to run with the do command. If this is a limitation, then a 
game language and a parser will be needed, and will have no evident 
limitations.

It just depends...

regards
David

> -Rodney
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the Use-livecode mailing list