Can I use Revolution for this?

Rodney Somerstein rodneys at io.com
Sat Aug 3 08:30:01 EDT 2002


Troy discussed the limits from the documentation as follows:

>====
>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...
>

It looks like I misunderstood the frontScripts/backScripts issue a 
bit. I see that I can simply create one object of each kind that I 
need and then the game designers should be able to specify how many 
of each they want in their games. These objects will automatically be 
in the message paths.

Due to the limits on changing scripts and do commands, I will 
probably have to implement a custom scripting language for the 
system. While I would have created some handlers for common tasks, 
this will require me to do much more work as the developer than I 
would have had to otherwise. There are certain things that the 
designers will not be able to easily do within the starter kit 
limits, but I see that they probably can be worked around.


Dan comments on these limits as well:

>Wow. This is a bit surprising. I can see the rationale for the new
>script-size limitation and I suppose the do command sort of would be
>a back-door way around that limit if it weren't imposed. But it
>*will* artificially (and I think unnecessarily) limit some kinds of
>applications which won't be able to be built using the product. I
>suppose there are justifications for this kind of thing but it always
>makes me wonder about the priorities of the publishers of the
>software. It too often seems -- and I'm not making this judgement
>here about Revolution, so don't go jumping on me! -- that some
>publishers are more worried about protecting themselves against the
>extreme unlikelihood that someone would essentially use their product
>to create a competitor than they are about the ultimate usability of
>the tool.

I think that you have hit the nail on the head, so to speak. While 
you are trying to be polite and not judge Revolution on this, it 
seems that they are limiting things for just the reasons that you 
state.

Again, the question is, why should I have to go through this? By 
paying for the license, I should be able to create a stack to do 
pretty much whatever I want without having to jump through such 
hoops. At the very least, all of these limits should be doubled for 
standalones produced from a licensed copy of Revolution. That too is 
arbitrary, but would still protect Run Rev from their evident fear of 
my producing a competing product. It also rewards me for purchasing 
the product from them by lifting some of the limits imposed on 
standalones produced without giving them some income (i.e., only 
using the starter kit.)

Of course, if these limits are actually imposed by MetaCard, I don't 
know if there is any easy way around this for them. However, they 
could still push to have all of these limits increased. It would make 
the product more applicable to a wider range of developers. If 
HyperCard were cross-platform and still produced, I wouldn't have to 
deal with these issues.

It is interesting that there have been no comments from anyone at 
RunRev. I suspect they are all on vacation right now.

-Rodney



More information about the use-livecode mailing list