Re: Weird Behavior
rand valentine wrote: I'm using Studio version 2.8.1 on an intel Mac running Leopard (10.5.2). Also running Galaxy and GL2. I'm getting weird behavior that I don't understand. An object is recognized for some things but not others. For example, in the following script, which simply clears a field: ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note -- notes_note END IF ELSE answer The note field is already empty. END IF END mouseUp In running the script, field notes_note is recognized in the IF statement, but I get an error message Chunk: no such object when I run the script, at the line that says put empty into fld notes_note. Anyone know what's up? It seems to happen when I put a field into a group, more than at other times. I remember seeing some discussion of circumstances in which the ask and answer dialogs would alter the execution context, resulting in the symptoms you describe. Whether that's happening here I can't say; I don't recall the specifics. Anyone here know more about the ask/answer context issue, and whether that may be the culprit here? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
re; weird behavior
I'm using Studio version 2.8.1 on an intel Mac running Leopard (10.5.2). Also running Galaxy and GL2. I'm getting weird behavior that I don't understand. An object is recognized for some things but not others. For example, in the following script, which simply clears a field: ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note -- notes_note END IF ELSE answer The note field is already empty. END IF END mouseUp In running the script, field notes_note is recognized in the IF statement, but I get an error message Chunk: no such object when I run the script, at the line that says put empty into fld notes_note. Anyone know what's up? It seems to happen when I put a field into a group, more than at other times. I remember seeing some discussion of circumstances in which the ask and answer dialogs would alter the execution context, resulting in the symptoms you describe. Whether that's happening here I can't say; I don't recall the specifics. Anyone here know more about the ask/answer context issue, and whether that may be the culprit here? -- Yes, if I remove the answer dialogue, then the script runs just fine. How does one get around this bug? rv ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Weird Behavior
Try adding the grp name when in a group ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note of grp theGroupNameGoesHere END IF END mouseUp HTHs Tom McGrath On Feb 24, 2008, at 12:27 PM, rand valentine wrote: I'm using Studio version 2.8.1 on an intel Mac running Leopard (10.5.2). Also running Galaxy and GL2. I'm getting weird behavior that I don't understand. An object is recognized for some things but not others. For example, in the following script, which simply clears a field: ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note -- notes_note END IF ELSE answer The note field is already empty. END IF END mouseUp In running the script, field notes_note is recognized in the IF statement, but I get an error message Chunk: no such object when I run the script, at the line that says put empty into fld notes_note. Anyone know what's up? It seems to happen when I put a field into a group, more than at other times. rand valentine ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: re; weird behavior
rand valentine wrote: I'm using Studio version 2.8.1 on an intel Mac running Leopard (10.5.2). Also running Galaxy and GL2. I'm getting weird behavior that I don't understand. An object is recognized for some things but not others. For example, in the following script, which simply clears a field: ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note -- notes_note END IF ELSE answer The note field is already empty. END IF END mouseUp In running the script, field notes_note is recognized in the IF statement, but I get an error message Chunk: no such object when I run the script, at the line that says put empty into fld notes_note. Anyone know what's up? It seems to happen when I put a field into a group, more than at other times. I remember seeing some discussion of circumstances in which the ask and answer dialogs would alter the execution context, resulting in the symptoms you describe. Whether that's happening here I can't say; I don't recall the specifics. Anyone here know more about the ask/answer context issue, and whether that may be the culprit here? -- Yes, if I remove the answer dialogue, then the script runs just fine. How does one get around this bug? For now: put the defaultStack into tSaveStack answer Really clear? with Cancel OR Yes put it into tVal set the defaultStack to tSaveStack IF tVal is Yes THEN put empty into fld notes_note -- notes_note END IF For all mankind: It's really kinda dumb if we need to save and restore the defaultStack for ask/answer dialogs. Does anyone here know the RQQC# for this issue, and has it been confirmed fixed as of v2.9DP4? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
re: weird behavior
Yes, if I remove the answer dialogue, then the script runs just fine. How does one get around this bug? For now: put the defaultStack into tSaveStack answer Really clear? with Cancel OR Yes put it into tVal set the defaultStack to tSaveStack IF tVal is Yes THEN put empty into fld notes_note -- notes_note END IF For all mankind: It's really kinda dumb if we need to save and restore the defaultStack for ask/answer dialogs. Does anyone here know the RQQC# for this issue, and has it been confirmed fixed as of v2.9DP4? The for now script offered above solves the problem. And also, I notice that things work fine in StackRunner, without saving the defaultStack in the script. Thanks. rv ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
rand valentine wrote: Yes, if I remove the answer dialogue, then the script runs just fine. How does one get around this bug? For now: put the defaultStack into tSaveStack answer Really clear? with Cancel OR Yes put it into tVal set the defaultStack to tSaveStack IF tVal is Yes THEN put empty into fld notes_note -- notes_note END IF For all mankind: It's really kinda dumb if we need to save and restore the defaultStack for ask/answer dialogs. Does anyone here know the RQQC# for this issue, and has it been confirmed fixed as of v2.9DP4? The for now script offered above solves the problem. And also, I notice that things work fine in StackRunner, without saving the defaultStack in the script. Thanks. Good to know. Now we just need to determine if the difference between SR and Rev is the engine or the dialogs. Which version of SR are you running? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Weird Behavior
I've taken to doing Tom's suggestion all the time (adding the group name) and it seems to keep things moving along for me. Mark On Feb 24, 2008, at 9:34 AM, Thomas McGrath III wrote: Try adding the grp name when in a group ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note of grp theGroupNameGoesHere END IF END mouseUp HTHs Tom McGrath On Feb 24, 2008, at 12:27 PM, rand valentine wrote: I'm using Studio version 2.8.1 on an intel Mac running Leopard (10.5.2). Also running Galaxy and GL2. I'm getting weird behavior that I don't understand. An object is recognized for some things but not others. For example, in the following script, which simply clears a field: ON mouseUp IF fld notes_note is not empty THEN answer Really clear? with Cancel OR Yes IF it is Yes THEN put empty into fld notes_note -- notes_note END IF ELSE answer The note field is already empty. END IF END mouseUp In running the script, field notes_note is recognized in the IF statement, but I get an error message Chunk: no such object when I run the script, at the line that says put empty into fld notes_note. Anyone know what's up? It seems to happen when I put a field into a group, more than at other times. rand valentine ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Thanks, Mark ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
On 18 Jul 2004, at 06:54, [EMAIL PROTECTED] wrote: Message: 19 Date: Sun, 18 Jul 2004 02:10:06 +0100 From: Alex Tweedly [EMAIL PROTECTED] Subject: Re: weird behavior To: How to use Revolution [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii snip I saw something like this when I was trying my speedy graphics examples, but thought it was just something I had done wrong. Or rather, was still doing wrong - I kept seeing odd behaviour that I don't understand, and was kind of stuck in trying to complete the project. So I'm really glad you sent this email :-) Looking into it some more, with this hint in mind, I think I have a clearer picture. I think you have a malformed polygon. From the Transcipt dictionary (points entry): A blank line in the points indicates that the previous and next vertexes are not connected by a line--that is, the line, curve, or polygon is broken into two (or more) pieces. If the last line of the points of a polygon is blank, the polygon is not closed. A closed polygon's start point (the first line of its points property) is the same as its end point (the last line of its points property). NB: An open polygon has a blank last line A closed polygon has the last line == first. Your example, like many of mine, had neither of those conditions true. So I guess it is, strictly speaking, malformed - and hence the behaviour could be undefined. I've been unable to see any failure with any example where I had a properly formed polygon according to specification. I still think it can be considered a bug - but at least it can be avoided / worked around. -- Alex. We have to reconsider the term malformed polygon. May be malused polygon opacity property is better in this case. The default setting of the opaque property of the templategraphic is true. If not altered all new polygons are of the closed type. Setting the opaque property to false for using open polygons and to true for closed polygons, do you still consider this as a bug or a work around? Greetings, WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
At 14:51 19/07/2004 +0200, Wouter wrote: On 18 Jul 2004, at 06:54, [EMAIL PROTECTED] wrote: Message: 19 Date: Sun, 18 Jul 2004 02:10:06 +0100 From: Alex Tweedly [EMAIL PROTECTED] big snip [ Transcript dictionary, as paraphrased (accurately, I think) by me ] An open polygon has a blank last line A closed polygon has the last line == first. (might have been marginally more precise to say last point == first) You said: We have to reconsider the term malformed polygon. May be malused polygon opacity property is better in this case. I'm not convinced. The description above requires that a polygon must meet one or other of the two conditions - and many obvious polygons will not satisfy either condition. No need to invoke the opacity of the polygon. Your original example had a non-blank last line containing a point which was not a duplicate of the first point - therefore was neither an open nor a closed polygon. The default setting of the opaque property of the templategraphic is true. If not altered all new polygons are of the closed type. Setting the opaque property to false for using open polygons and to true for closed polygons, do you still consider this as a bug or a work around? Not sure about whether it's a bug or not. As far as I can tell, all polygons which meet the description in the dictionary will be either properly closed or properly open, and all will be drawn as you'd expect - both in opaque and transparent. So I'm sure it's a deficiency to leave the definition of polygon so (needlessly) amenable to describing malformed ones - but not sure whether it's a bug or an opportunity for improvement. The interaction of closed-ness with the opacity setting seems like a bug. If a script supplies a set of points which describe a malformed polygon, then that malformed polygon should be treated consistently, regardless of whether it is opaque or transparent. (Though of course it's better - and perfectly possible - to make it literally impossible to describe a malformed polygon.) But I'm sure it could be better described in the documentation. And I'm sure that provided you know about malformed polygons (which I didn't until this discussion started - thanks) you can easily avoid any problems - so if it's a bug, it's a fairly minor one. Cheers, -- Alex. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
weird behavior Alex Tweedly alex at tweedly.net Mon Jul 19 15:25:14 EDT 2004 -- another big snip I'm not convinced. The description above requires that a polygon must meet one or other of the two conditions - and many obvious polygons will not satisfy either condition. No need to invoke the opacity of the polygon. Your original example had a non-blank last line containing a point which was not a duplicate of the first point - therefore was neither an open nor a closed polygon. This is the difference in looking at things. Is it the engine that should be conform to the description or is it the description that should be conform to the engine? The Transcript Dictionary is a reworked, updated and elaborated version of the metatalk reference. It is a wonderful piece of work, but is it infallible? Anyway, the engine acts in this way. If you call it to draw a polygon and if the opaque property is set, it will consider it as a closed one and will check if point 1 = last point, if not then add that point. Your so called welformed open polygons are in fact closed ones if the opaque property is set.and the engine gets his way. Have a look at the points. Draw a so called open polygon and add 2 returns for welformed-ness sake. Deselect the polygon and reselect it and have a look at the points: the so called open polygon is closed now, the first point is added. The default setting of the opaque property of the templategraphic is true. If not altered all new polygons are of the closed type. Setting the opaque property to false for using open polygons and to true for closed polygons, do you still consider this as a bug or a work around? Not sure about whether it's a bug or not. As far as I can tell, all polygons which meet the description in the dictionary will be either properly closed or properly open, and all will be drawn as you'd expect - both in opaque and transparent. What you call properly open in a welformed polygon is in fact a closed polygon but it last side is not drawn. What I call poperly open is a polygon which last points first point but which can have enclosed regions. So I'm sure it's a deficiency to leave the definition of polygon so (needlessly) amenable to describing malformed ones - but not sure whether it's a bug or an opportunity for improvement. Improvement. :-) The interaction of closed-ness with the opacity setting seems like a bug. If a script supplies a set of points which describe a malformed polygon, then that malformed polygon should be treated consistently, regardless of whether it is opaque or transparent. (Though of course it's better - and perfectly possible - to make it literally impossible to describe a malformed polygon.) I agree that the interaction of closed-ness with the opacity is awkward, but I cannot consider it a real bug. The improvement would be to add another property that governs open- or closed-ness. And use the opacity for the enclosed regions of the polygon to be filled or not. But I'm sure it could be better described in the documentation. And I'm sure that provided you know about malformed polygons (which I didn't until this discussion started - thanks) you can easily avoid any problems - so if it's a bug, it's a fairly minor one. Agreed, it is a minor one. :-) Cheers, -- Alex. Regards, Wouter ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
At 17:05 19/07/2004 +0200, Wouter wrote: I'm not convinced. The description above requires that a polygon must meet one or other of the two conditions - and many obvious polygons will not satisfy either condition. No need to invoke the opacity of the polygon. Your original example had a non-blank last line containing a point which was not a duplicate of the first point - therefore was neither an open nor a closed polygon. This is the difference in looking at things. Is it the engine that should be conform to the description or is it the description that should be conform to the engine? Or should both conform to what it/they *should* do ? The Transcript Dictionary is a reworked, updated and elaborated version of the metatalk reference. It is a wonderful piece of work, but is it infallible? Anyway, the engine acts in this way. If you call it to draw a polygon and if the opaque property is set, it will consider it as a closed one and will check if point 1 = last point, if not then add that point. Not true if you add the polygon in the IDE. You can create a polygon with 3 vertices, leaving it to default to opaque. (click at 100,100 - click at 200,100 - double-click at 200,200) The result is that two edges are drawn (i.e. NOT the third closing edge), there is no additional (duplicate) point not added to the point list. If you give it a fill colour, you will see that it is filled as though the third closing edge were there - but the edge itself is not drawn. (Though the point, and the drawn edge, will be added when you do certain edits to the polygon.) And if you do the same thing in a script, you get the last point duplicated for you. Your so called welformed open polygons are in fact closed ones if the opaque property is set.and the engine gets his way. Have a look at the points. Draw a so called open polygon and add 2 returns for welformed-ness sake. Deselect the polygon and reselect it and have a look at the points: the so called open polygon is closed now, the first point is added. See my counter-example above :-) btw - after creating the polygon, I deselected the polygon, saved the stack, and quit Revolution, then restarted it - all to make sure I was not being misled by the Property Inspector lagging the stack contents. In any case, it is not a requirement that all edges exist on an opaque polygon. You can draw an opaque polygon with blank lines in the middle of the point list. This results in those edges being left undrawn, and the fill behaviour is straightforward (though hard to describe in words). It produces a set of non-contiguous shapes; the series of edges between any two blank lines (or the start-blank line, and blank line-end) produces a filled shape, with an implicit edge being used in the fill but not drawn. Easier seen than described : in the IDE, create a polygon and set the points as follows 50,192 322,192 320,240 260,296 178,296 160,262 116,288 76,260 42,294 (deselect, reselect, note the first point did not get replicated as the last point, and the implicit last edge did not get drawn). Give it a fill colour - you see a nice simple shape. Now insert a blank line after the 3rd point, and again after the 7th, to get 50,192 322,192 320,240 260,296 178,296 160,262 116,288 76,260 42,294 Note : The first point is now duplicated - you may need to switch the Property Inspector to another object and back again to update the points window. (I saved and re-opened the stack at each stage of this, just to be sure I was viewing up-to-date info in Property Inspector). You now have three dis-contiguous filled regions. Each of those three regions has one un-drawn edge needed to close the region for fill purposes. To me, this implies that the engine is capable of filling (i.e. opaque-ing) non-closed regions, and it is an anomaly that it refuses to do so when the blank line happens to be the last one. I agree that the interaction of closed-ness with the opacity is awkward, but I cannot consider it a real bug. The improvement would be to add another property that governs open- or closed-ness. And use the opacity for the enclosed regions of the polygon to be filled or not. I see it as a real bug. If I create a 20-sided opaque polygon, with the first point not being duplicated at the end, that produces a filled shape, with the last edge not drawn. Then I add a blank line at the other side (i.e. between points 10 and 11) of the polygon, and suddenly the last edge becomes drawn. Surely that's a bug ? But I see no need to add a new property - the existence or non-existence of blank lines already provides enough expressive power to describe everything needed. Unfortunately, both the engine and the documentation would need to change. -- Alex. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004 ___
Re: weird behavior
Wouter wrote: I'm not convinced. The description above requires that a polygon must meet one or other of the two conditions - and many obvious polygons will not satisfy either condition. No need to invoke the opacity of the polygon. Your original example had a non-blank last line containing a point which was not a duplicate of the first point - therefore was neither an open nor a closed polygon. This is the difference in looking at things. Is it the engine that should be conform to the description or is it the description that should be conform to the engine? I vote for whichever one gives the developer the greater range of options. -- Richard Gaskin Fourth World Media Corporation ___ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
Recently, Alex Tweedly wrote: I agree that the interaction of closed-ness with the opacity is awkward, but I cannot consider it a real bug. The improvement would be to add another property that governs open- or closed-ness. And use the opacity for the enclosed regions of the polygon to be filled or not. I see it as a real bug. If I create a 20-sided opaque polygon, with the first point not being duplicated at the end, that produces a filled shape, with the last edge not drawn. Then I add a blank line at the other side (i.e. between points 10 and 11) of the polygon, and suddenly the last edge becomes drawn. Surely that's a bug ? This may just be the IDE trying to be helpful (in which case it may be a bug). But in any case, you might try checking points via script/answer to verify point information. FWIW, I do agree that a closed-ness property seems unnecessary (as long as setting points is not broken). In addition to Geoff Canyon's amazing asteroids recreation that employs a single polygon graphic, you might want to take a look at the Tutti3D example available in our media panel. Enter the following in your message box and scroll down to Tutti3D: go url http://www.tactilemedia.com/tmpanel.rev; Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
weird behavior Alex Tweedly alex at tweedly.net Mon Jul 19 19:06:54 EDT 2004 * Previous message: weird behavior * Next message: weird behavior * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] --snip Not true if you add the polygon in the IDE. You can create a polygon with 3 vertices, leaving it to default to opaque. (click at 100,100 - click at 200,100 - double-click at 200,200) The result is that two edges are drawn (i.e. NOT the third closing edge), there is no additional (duplicate) point not added to the point list. If you give it a fill colour, you will see that it is filled as though the third closing edge were there - but the edge itself is not drawn. No not correct, you didn't do the action complete (and please this is no offence). You left out following comment: Draw a so called open polygon and **add 2 returns for welformed-ness sake**. Deselect the polygon and reselect it and have a look at the points: the so called open polygon is closed now, the first point is added. If you draw an open ploygon like that and if you look at the points, then it is what you called a *malformed polygon*. If you add 2 returns to make it a *welformed polygon* and then deselect and reselect you will see the engine adds the starting point. And yes it will be filled, in both cases if there are enclosed regions. (I only looked at the way the engine works) (Though the point, and the drawn edge, will be added when you do certain edits to the polygon.) And if you do the same thing in a script, you get the last point duplicated for you. Your so called welformed open polygons are in fact closed ones if the opaque property is set.and the engine gets his way. Have a look at the points. Draw a so called open polygon and add 2 returns for welformed-ness sake. Deselect the polygon and reselect it and have a look at the points: the so called open polygon is closed now, the first point is added. See my counter-example above :-) btw - after creating the polygon, I deselected the polygon, saved the stack, and quit Revolution, then restarted it - all to make sure I was not being misled by the Property Inspector lagging the stack contents. See above In any case, it is not a requirement that all edges exist on an opaque polygon. You can draw an opaque polygon with blank lines in the middle of the point list. This results in those edges being left undrawn, and the fill behaviour is straightforward (though hard to describe in words). It produces a set of non-contiguous shapes; the series of edges between any two blank lines (or the start-blank line, and blank line-end) produces a filled shape, with an implicit edge being used in the fill but not drawn. Some language problem. it is not a requirement that all edges exist on an opaque polygon the *existence* of en edge From the point of the viewer: if it is not drawn, it does not exist. But from the point of view of the engine, it depends on the order of the points to draw the polygon (or any other form) if an edge exists and if it is visible or not. If a polygon contains a couple of regions, these do not become individual polygons, though it can look like it. I see it as a real bug. If I create a 20-sided opaque polygon, with the first point not being duplicated at the end, that produces a filled shape, with the last edge not drawn. Then I add a blank line at the other side (i.e. between points 10 and 11) of the polygon, and suddenly the last edge becomes drawn. Surely that's a bug ? No. It is the way the engine works with graphics in relation to the opaque property. But I see no need to add a new property - the existence or non-existence of blank lines already provides enough expressive power to describe everything needed. Unfortunately, both the engine and the documentation would need to change. -- Alex. I like this, so many different ways to look at the same object, thing, problem or whatever. I am sorry if what I say is not correct from the point of view of a particular language. But there is something like: if your first programming language was C, you tend to look at any other language from the point of view of the first one you learned. And with assembler this tendency is even worse :-)) For Geoff's famous starbattle: go stack url http://www.inspiredlogic.com/rev/starbattle.rev;; Have fun. Greetings, WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
On Jul 19, 2004, at 1:14 PM, Scott Rossi wrote: In addition to Geoff Canyon's amazing asteroids recreation that employs a single polygon graphic, you might want to take a look at the Tutti3D example available in our media panel. Enter the following in your message box and scroll down to Tutti3D: go url http://www.tactilemedia.com/tmpanel.rev; Scott, the 3D demo, and the media panel itself are very inspiring pieces of work. Thanks for that! -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Asteroids [Was Re: weird behavior]
At 10:14 19/07/2004 -0700, Scott Rossi wrote: In addition to Geoff Canyon's amazing asteroids recreation that employs a single polygon graphic, you might want to take a look at the Tutti3D example available in our media panel. The stack Rotater Manipulator uses a single vector graphic too, to draw a 3d object in the card: Download the stack from: http://www.geocities.com/capellan2000/Rotater_Manipulator_v1a.zip This is an adaptation of the HC stack of Alexander Thomas that you could download from his website: http://www.dr-lex.34sp.com/software/3dstuff.html I've added 3D matrix math to make the transformations faster and included the Live option suggested by Jim Hurley. Use this Live option ONLY with models of a few lines like the cube and some simple shapes like the Fighter and the Tank. Read the Help card (second card) of this stack for useful information. I've invited Alexander Thomas to test RunRev by himself and visit us in the mail list. I'm making tests to provide edition of the points of these 3d graphics. It could be made already, by changing the values by hand, but it'll be more confortable to use sliders or move the points with the mouse on the axis x,y,z. Enjoy! :-)) al = Visit my site: http://www.geocities.com/capellan2000/ Search the mail list: http://mindlube.com/cgi-bin/search-use-rev.cgi __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
Re: weird behavior From: Alex Tweedly Subject: Re: weird behavior Date: Sat, 17 Jul 2004 18:03:36 -0700 At 23:24 17/07/2004 +0200, Wouter wrote: Hi all, Some weird behavior. -- snip I saw something like this when I was trying my speedy graphics examples, but thought it was just something I had done wrong. Or rather, was still doing wrong - I kept seeing odd behaviour that I don't understand, and was kind of stuck in trying to complete the project. So I'm really glad you sent this email :-) Looking into it some more, with this hint in mind, I think I have a clearer picture. I think you have a malformed polygon. From the Transcipt dictionary (points entry): A blank line in the points indicates that the previous and next vertexes are not connected by a line--that is, the line, curve, or polygon is broken into two (or more) pieces. If the last line of the points of a polygon is blank, the polygon is not closed. A closed polygon's start point (the first line of its points property) is the same as its end point (the last line of its points property). NB: An open polygon has a blank last line A closed polygon has the last line == first. Your example, like many of mine, had neither of those conditions true. So I guess it is, strictly speaking, malformed - and hence the behaviour could be undefined. I've been unable to see any failure with any example where I had a properly formed polygon according to specification. I still think it can be considered a bug - but at least it can be avoided / worked around. -- Alex. Hi all responders, I know this is a malformed polygon. But the question remains. Why is rev adding the extra line and metacard does not.? The answer lies in 1 of the properties of the graphic When a graphic is set to polygon, the opaque property is set to false in metacard and to true in revolution. Setting this property to true in metacard makes it add the extra line at the end of the list of points. Setting this property to false in revolution stops it adding a line to the list of points. So it is not really a bug :-) Greetings, WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
Wouter wrote: Hi all, Some weird behavior. If the style of a created graphic is set to polygon and the points of it are set to a list like: --- start of list point1 point2 point3 point4 point5 point6 - end of list then revolution adds another point to the list. it becomes: --- start of list point1 point2 point3 point4 point5 point6 point1 - end of list whereas in metacard no point is added If the style of the graphic is set to curve and then reverted to polygon no point is added no more. Puzzling... What is the Buzilla report number for this? -- Richard Gaskin Fourth World Media Corporation ___ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
At 23:24 17/07/2004 +0200, Wouter wrote: Hi all, Some weird behavior. If the style of a created graphic is set to polygon and the points of it are set to a list like: --- start of list point1 point2 point3 point4 point5 point6 - end of list then revolution adds another point to the list. it becomes: --- start of list point1 point2 point3 point4 point5 point6 point1 - end of list whereas in metacard no point is added If the style of the graphic is set to curve and then reverted to polygon no point is added no more. Puzzling... I saw something like this when I was trying my speedy graphics examples, but thought it was just something I had done wrong. Or rather, was still doing wrong - I kept seeing odd behaviour that I don't understand, and was kind of stuck in trying to complete the project. So I'm really glad you sent this email :-) Looking into it some more, with this hint in mind, I think I have a clearer picture. I think you have a malformed polygon. From the Transcipt dictionary (points entry): A blank line in the points indicates that the previous and next vertexes are not connected by a line--that is, the line, curve, or polygon is broken into two (or more) pieces. If the last line of the points of a polygon is blank, the polygon is not closed. A closed polygon's start point (the first line of its points property) is the same as its end point (the last line of its points property). NB: An open polygon has a blank last line A closed polygon has the last line == first. Your example, like many of mine, had neither of those conditions true. So I guess it is, strictly speaking, malformed - and hence the behaviour could be undefined. I've been unable to see any failure with any example where I had a properly formed polygon according to specification. I still think it can be considered a bug - but at least it can be avoided / worked around. -- Alex. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: weird behavior
Thanks, but that wasn't the problem. It's not running the main install program. If it was, then the installation would proceed as normal. Instead I just get the Windows Installer window for a couple seconds, and then it prompts me to locate some file that doesn't exist anywhere. It's bizarre. Any other ideas? It's almost as if something in the Distribution Builder is corrupting my installation. Chris Sheffield Read Naturally __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
