Script Limits and solid IDE evolution!

[Robert Brenstein]

>Second, the problem with the MC licensing scheme is that it was too 
>easy to abuse...
>Here, I fully understand RR's way. You build a chain of buttons 
>never breaking the limit of the 10 script lines but despite that, I 
>dont know anyone who would in their right mind want to use such an 
>IDE. Also, to Scott's demise, allowing compilation of an executable 
>is a nice feature for a demo but it's part of the problem with 
>runaway licenses...

Actually, this was an acceptable way to earn your wings and test the 
MC environment. Chaining 10-lines was not breaking any licenses 
AFAIK. I believe the reasoning was that any serious developer would 
pay rather than struggle all the time, but people who were not 
serious wouldn't pay anyway. Some post in this thread seem to confirm 
that this worked. (But then some complained that they can't truly 
evaluate the product with 10-line limit.)

>No many IDE's have this feature on the other hand!
>  Also, note that other than optimizing the IDE to improve your 
>workflow, I dont see why anyone would want to go through the pain of 
>creating an IDE.
>Most RR and MC users create applications for their clients. None of 
>them want their clients to develop more themselves!

It was not about competing GUI as far as I know. MC allowed for alt 
GUIs (it is Rev that had this restriction). However, if not for the 
script limiting, one unscrupulous programmer could produce a 
standalone that gave full access to the engine in developer mode for 
anyone. Indeed not a desirable situation for anyone seriously 
interested in this product. This is why standalones have always been 
running in the demo mode so do speak. Full features of the engine 
were only available in the development (paid) environment. As a 
result, we had a severly limited or full environment but nothing in 
between. As Scott explained to me at some point, there were some 
markets that he left out for that reason. Now Rev is changing the 
equation by further restricting the 'limited' end, crippling 
capabilities for our products even further. My reading on that is 
that Rev is focusing more on people who work only within dev 
environment rather than producing standalones distributed to others. 
In other words, while MC was meant as a tool for professional 
developers, Rev is mostly after the hobbyst market.

>Following Robert's comments earlier, the removal of a feature or 
>limiting a feature like dynamic scripting (the DO script), is IMOHO 
>a terrible mistake and a SEVERE limit to the IDE's possibilities. Of 
>which this one is almost unique among other IDEs.

Since using 'do' one can relatively easily work around the 'set 
script to' restriction (performance issues aside), we can only expect 
further elimination of 'do' in standalones (do limit set to 0) in a 
near future. It would be a logical followup to fully close that 
loophole. This line of product development really scares me, 
particularly as it is a rather expensive product (I paid for full MC 
license plus renewal) comparing to either RB or CWP. I have my doubts 
about cutting off multiplatform features from cheaper licenses but I 
see this as Rev trying to maximize their income. I have no problems 
if the demo is restricted in terms of dynamic scripting. But the 
engine embedded when producing a standalone from a licensed 
environment could retain current limits. Since the limits are clearly 
kept as parameters, there must be ways to control them accordingly, 
including setting arbitrary values for specific projects (as I 
suggested). I had big and long-term plans for a number of MC-based 
projects, but the recent developments really make me wonder whether I 
bet on the right horse.

Robert Brenstein