Re: Update Mac menubar fails in standalone
I agree that the documentation is minimal and could use some improvement but a worse case scenario thinker must have anticipated for sure that jumping to production without a proper understanding of the possibilities and limitations of the tool comes with some risks ;-). Regards, Andu Novac Good one :-) The possibilities are greater than I imagined. Metacard has more features than I anticipated, as a transplantee from Hypercard. I knew Hypercard intimately. And did not anticipate such a learning curve. I figured it would have more of everything, and better of everything, but did not expect things to work differently. Actually I like many of the differences. Especially the ones that allow for cross platform programs :-) When I started with Hypercard, one of the first things I did was invest in two big fat books to learn the ins and outs that were missing in the documentation. Unfortunately, we don't have this with Metacard, so we just fumble around with what we don't know till we figure it out. We ask you guys, but I've had many questions go unanswered even here, so fumbling is the only way sometimes. Fumbling takes a lot more time than opening a book and having the answer magically be there. I miss having a resource of the caliber of the Hypertalk 2.2 book. That book covered *almost* everything :-) Shari C -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Ambrosia's approach is to have the software phone home to perform validation of the reg code. I've heard this approach discussed. Many believe it's a serious privacy intrusion, unless you're upfront in letting people know the software does this. I like any idea that helps reduce piracy. People just don't realize they're messing with someone's bread and butter. Even people who sneak out of a restaurant or nightclub not paying, assume that some big company will absorb the cost. But the truth is, the waiter or bartender will pay out of pocket. If they don't, they risk losing their job. In my experience the majority of theft is done by means outside of your control, with the thief making a legitmate purchase with stolen credit card info. There are ways to prevent this. I highly recommend that all shareware authors read the shareware author newsgroups, and devour all info they can from newsgroups, articles by other authors, etc. There are even articles on crack sites, that will help you PREVENT cracks. I've seen no evidence thus far that anyone has found it worth their while to truly crack my reg scheme, and as long as credit card info remains easy for criminals to purchase there is little reason for them to go to that much trouble for smaller apps (major game releases are another story). I'm tightening mine now, as after the current project, I will update some software, and the next big project is an RPG. Very high profile. Happily I can do things with Metacard that will allow for a first class RPG :-) But tightening the registration system is a key factor to success. I've dissected and resected the code about three times in Metacard now. Today, I think I will have it done :-) Shari C -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Allowing anyone with an existing license key to defeat the Starter Kit limits with no restrictions is a recipe for disaster, however, and so is not something we're willing to consider. Regards, Scott Yes I understand this, Scott, I'm sure we all do! Software protection is a major issue. You are simply protecting yours. I guess that's why I'm so frustrated this week. What broke when I turned the stack into a standalone, among other things, was the registration system. And some of the fixes weaken it. I had intended to write a self-healing script that would check to make sure the script hadn't been tampered with or hacked, and then fix it or quit if it had. But apparently it isn't possible with a standard license, from within a standalone. As you can't heal the scripts. I'm presuming this means you can't tamper with the scripts from within the program either. But what about from outside? That's apparently very common. I'm actually planning to hack my own program and see if it can be done. Just for my own peace of mind. Now that I can send programs into the Windows world, that will attract the attention of a lot more of the bad guys. And I want to be prepared. I read many author's groups. And it's pretty disgusting how common cracks are. Some authors lose 50% of their sales when a crack comes out. So I do take care with my registration system. The whole issue of cracks is a much discussed one. And authors are split as to how they handle the issue. Some say not to spend too much time over your protections, to accept that cracks will happen, and blow it off. Others take the opposite tack. I'm a worse case scenario thinker. I take the opposite tack. And it's important to me to tighten the system for the next programs out the door, in anticipation of increased exposure. I'm still learning the ins and outs of Metacard, and I LOVE the program. I'm delighted overall with it. But there is so much missing in the documentation, that you only learn when you try it, it fails, and you spend days trying to determine why. This project has probably taken twice the development time for the learning curve. That's frustrating when you can't get the program out the door, and it affects the money coming in the door. At the very least, the documentation should be very very clear about the standalone limitations, such as not being able to edit a script from within a script, or set the script of object to... or even get word 3 of the script of... that do commands are limited to 10 lines of code... that the LookandFeel may change the way your objects look, as the default setting may be different from your normal setting (don't assume it looks for your computer type and chooses that setting, that was my assumption). Metacard has opened many doors for me. I love the freedom it offers, and the simplicity of xTalk development. I made a good choice with Metacard. I am happy. I just wish the documentation was more thorough. You can't even buy better documentation. You can look at Revolution's and see if it is more helpful, but often, the issues that ball me up, aren't in any docs anywhere, even the archives. And I lose development time. And I get frustrated. Time is money for all of us. I have a fella who doesn't accept the time I devote to software development, as I'd make a lot more money following a more accepted career path. So I'm fighting like hell to bring the software income up to that level. Whatever slows it down, frustrates the hell out of me. So please pardon me, if sometimes I come across a little hard. Shari C -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Recently, Shari wrote: At the very least, the documentation should be very very clear about the standalone limitations, such as not being able to edit a script from within a script, or set the script of object to... or even get word 3 of the script of... Actually, there's no reason why you can't do that last one, as long as your stack isn't password protected (otherwise just set the passkey before getting the script). Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
I agree that the documentation is minimal and could use some improvement but a worse case scenario thinker must have anticipated for sure that jumping to production without a proper understanding of the possibilities and limitations of the tool comes with some risks ;-). Regards, Andu Novac ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Shari wrote: The whole issue of cracks is a much discussed one. And authors are split as to how they handle the issue. Some say not to spend too much time over your protections, to accept that cracks will happen, and blow it off. Others take the opposite tack. I'm a worse case scenario thinker. I take the opposite tack. And it's important to me to tighten the system for the next programs out the door, in anticipation of increased exposure. See: The Plain Truth About Piracy http://www.AmbrosiaSW.com/cgi-bin/ubb/newsdisplay.cgi?action=topicsnumber= 14forum=*The+Ambrosia+Times+NewsletterDaysPrune=25article=52startpoi nt= Ambrosia's approach is to have the software phone home to perform validation of the reg code. Since I'm one of those with good reason to believe more than half my users did not pay for the software, I'm considering something along these lines myself. In my experience the majority of theft is done by means outside of your control, with the thief making a legitmate purchase with stolen credit card info. Once a valid reg code is obtained, it circulates through Hotline, GNUtella, Usenet, and other popular crackbegger haunts, until you come across it and block the code in the next release. This does nothing to prevent the distribution of your code for the current version, but at least frustrates some if you upgrade your product regularly. I've seen no evidence thus far that anyone has found it worth their while to truly crack my reg scheme, and as long as credit card info remains easy for criminals to purchase there is little reason for them to go to that much trouble for smaller apps (major game releases are another story). My own philosophy is to let the big companies provide guidance for effective strategies. Apple, Microsoft, Adobe, and Macromedia products can be unlocked with a simple reg code, with few of their wares phoning home for validation. Customers have an unnecessary privacy concern about software that phones home, and Microsoft's attempt to require it with XP has met with strong disfavor. So I may do it, but not without running it by a few of my favorite customers first. While you and I know that a simple HTTP transaction needn't compromise anyone's privacy, as long as the irrational perception persists it must be taken into acount to encourage legitimate sales. Any anti-piracy scheme that hinders the legitimate user's experience risks backfiring. -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Recently, Shari wrote: Is it possible that you password-protected the stack in the standalone? I think you should be able to do all the above provided the stack is not protected. One embedded stack is encrypted, but not the one that used the handler, or the one the handler was in. I ran into several limitations in the standalone. A standalone puts the program into starter kit mode. I didn't think this was the case, but it does seem to be true. This is unfortunate for folks who need to modify scripts at runtime in anything outside the development environment. Perhaps there is a way you could store your changing code in separate stacks and load the stacks as needed using your standalone. To Scott Raney Company: would it make sense to add a licenseKey property or something similar to permit creation of licensed standalones that can modify scripts? Don't know if this would make MC too accessible to folks who haven't paid for licenses but the option to create editable scripts via a standalone does seem legitimate. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
On Sun, 22 Sep 2002 Scott Rossi [EMAIL PROTECTED] wrote: To Scott Raney Company: would it make sense to add a licenseKey property or something similar to permit creation of licensed standalones that can modify scripts? Don't know if this would make MC too accessible to folks who haven't paid for licenses but the option to create editable scripts via a standalone does seem legitimate. Anyone who really needs this functionality should rest assured that there are methods of getting around these limits. But all require signing contracts and paying additional fees and so are not something you want to do just to simplify your development a little (and in this particular case barely any at all). Allowing anyone with an existing license key to defeat the Starter Kit limits with no restrictions is a recipe for disaster, however, and so is not something we're willing to consider. Regards, Scott Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Is it possible that you password-protected the stack in the standalone? I think you should be able to do all the above provided the stack is not protected. One embedded stack is encrypted, but not the one that used the handler, or the one the handler was in. I ran into several limitations in the standalone. A standalone puts the program into starter kit mode. So presumably you cannot edit a script that is over 10 lines long. If it's already there, it will run. But my script was attempting to edit, or get, part of a script. Also I had code stored in custom properties. get the property of btn x do it This failed also if the code was longer than 10 lines. -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Recently, Shari wrote: The update mac menubar handler I posted here recently fails in a standalone. You cannot do anything in a standalone that tampers with a script. You cannot change a script. You cannot even get a script. You cannot set the script of an object to anything but what it was when saved as a standalone. Is it possible that you password-protected the stack in the standalone? I think you should be able to do all the above provided the stack is not protected. One way to deal with protection is to set the passkey of the stack before accessing scripts. Of course, you can't save anything you do since your stack is part of a standalone. If you're looking to save changes to a stack (ie user prefs, etc) you should keep your data stack separate from the standalone. Again, you can password-protect the data, and as long as you set the passkey appropriately, you should be able to write to the data stack as needed. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Update Mac menubar fails in standalone
Shari wrote: The update mac menubar handler I posted here recently fails in a standalone. You cannot do anything in a standalone that tampers with a script. Standalones are just stacks with embedded starter kits, and so are limited to 10-line scripts. Pre-existing longer scripts are fine, but any changes have to be within the 10-line limit. I think I'd still go with swapping out the default menubar. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
