 |
| kjaerhus |
Posted: Thu May 03, 2007 10:41 pm
Scripts within a window creates triggers outside the window |
 |
Arminas Wizard
Joined: 11 Jul 2002 Posts: 1265 Location: USA
|
Posted: Wed May 09, 2007 7:28 pm |
Ah, I see your point hmm. More thinking here.
|
|
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
 |
Arminas Wizard
Joined: 11 Jul 2002 Posts: 1265 Location: USA
|
Posted: Wed May 09, 2007 7:31 pm |
Waitdo needs a second string list for recursive loops added So... I need a few moments to rewrite it adding that.
|
|
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
 |
kjaerhus Magician

Joined: 18 Dec 2006 Posts: 317 Location: Denmark
|
Posted: Wed May 09, 2007 7:35 pm |
Well, it could work I suppose. I'll have to give it some thought though before I can verify that it would work for the quite more complicated cases I have in my actual setup.
Thanks. |
|
|
|
 |
kjaerhus Magician

Joined: 18 Dec 2006 Posts: 317 Location: Denmark
|
Posted: Wed May 09, 2007 7:40 pm |
Seems I got myself confused there. As long as I cannot block the script from ending I cannot make my infinite loop of course.
|
|
|
|
 |
Arminas Wizard
Joined: 11 Jul 2002 Posts: 1265 Location: USA
|
Posted: Wed May 09, 2007 7:53 pm |
Well, if you create a separate Alarm, and string list for your recursive calls you can turn off the Normal wait alarm while the recursive one is going. I need a little more time to write it all down that I have here. I am at work and have been stealing seconds to play with things.
Basically though what you want is a recursive type system for using Alarms or triggers instead of using the built in loops. |
|
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
 |
Arminas Wizard
Joined: 11 Jul 2002 Posts: 1265 Location: USA
|
Posted: Wed May 09, 2007 8:42 pm |
I've rethought my opinion on this. You were going to have to use triggers to tell the loop that it is done, and you were going to have to set the feedback flag for the thing to move on.
Add the recursive call to the original waitdo queue then in the trigger that tells you that you have done that action call the recursive INSIDE that trigger. When you are done send the feedback for the queue to send you on.
#alias recursive {#if (!@iAmDone) {doSomething;recursive} {waitForFeedback=0}}
#trigger {You have pealed a potato.} {recursive}
#trigger {You do not have a potato to peal.} {iAmDone=1;recursive}
I hope you get the gist.
Edit: Please read the next post. You do not need to use recursive calls at ALL for your loops. |
|
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Last edited by Arminas on Wed May 09, 2007 9:18 pm; edited 1 time in total |
|
|
 |
Arminas Wizard
Joined: 11 Jul 2002 Posts: 1265 Location: USA
|
Posted: Wed May 09, 2007 9:16 pm |
So we have this...
--------------
// Alias: waitDo.
// A simple command queue system.
// There are triggers that captures mud output and sets the waitforfeedback flag but they are not interesting in this context
waitforfeedback=1
#addi commands %-1
#T+ waitA
--------------
// Alarm: *.501 With the ID of waitA
// A simple command queue system.
// There are triggers that captures mud output and sets the waitforfeedback flag but they are not interesting in this context
#if (@waitForFeedback=0) {
#execute %pop( commands)
#if (%numitems( @commands)=0) {#T- waitA} {waitforfeedback=1}
}
--------------
// Alias: pealPotatoes.
// An Alias.
#if (!@iAmDone) {peal potato} {waitForFeedback=0}
--------------
// Alias: Testloop.
// A simple test for the command queue system.
get knife from sack
waitdo {pick up potato}
waitdo {pealPotatoes}
waitdo {get 300 potato}
waitdo {put 300 potato in sack}
--------------
#trigger {You pick up a potato.} {waitforfeedback=0}
#trigger {You remove a shiny knife from your sack.} {waitforfeedback=0}
#trigger {You have pealed a potato.} {pealPotatoes}
#trigger {You do not have a potato to peal.} {iAmDone=1;pealPotatoes}
#trigger {You pick up %d pealed potatoes.} {waitforfeedback=0}
#trigger {You put %d pealed potatoes into a large sack.} {waitforfeedback=0}
Sorry about confusing you. It is what I get for trying to work And trying to code things on here. |
|
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
 |
kjaerhus Magician

Joined: 18 Dec 2006 Posts: 317 Location: Denmark
|
Posted: Wed May 09, 2007 9:25 pm |
Hehe, this thing sure is getting more and more complex and I am not convinced that the blocking problem is even solved yet, but then I am too tired to make any conclusions right now so I think I'll sleep on it.
Maybe you now understand why I want to use #WAIT. I don't really care for the hot air I get from Zugg and others about wait being "evil" - it's functionality that is working in any other programming language. If it's not working it should be on the bug list instead of being ignored with a lame explanation as an excuse. But that's just my opinion...
Anyway I've got my mind working on some other ideas after our little discussion here so if I do not get to get rid of wait yet at least I have some neat new ideas about how to improve other aspects of my scripts. Funny how these forums work - I never got any useful feedback on the main topic, probably because I said the forbidden W word. Well, I might just have to try and figure out how to reproduce it on command and come back with an example, but I am afraid it won't be easy...
Thanks again. |
|
|
|
 |
kjaerhus Magician

Joined: 18 Dec 2006 Posts: 317 Location: Denmark
|
Posted: Wed May 09, 2007 9:28 pm |
Wow, you made another reply while I was writing mine. Well, I'll dig into it tomorrow. My body is telling me I need some sleep...
|
|
|
|
 |
|
|
|