View unanswered posts | View active topics It is currently Fri Mar 29, 2024 5:53 am



Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4  Next
 Weapon M Scripting Tutorial 
Author Message
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Mongoose wrote:

You can now. But it's not magic, it's science. :wink:
.


I don't really get it... you still have to decide which script is going to handle the event, don't you? A state machine has to be deterministic...

I understand that with this event-driven stuff you do have more control over which script handles an event, but the person running the script still has to decide which script will handle a given event.


Sat Dec 29, 2012 3:28 pm
Profile ICQ
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Mongoose wrote:
Astrochimp wrote:
If you want to do two things at once, you have to write a script that does it. You can't run a script that is meant strictly for port pair trading, then run some other script that interacts with the command prompt on top of that and expect them to work magically together without a problem.


You can now. But it's not magic, it's science. :wink:

You should read my EDP tutorial.


I guess I'd need to run through an example. I understand event-driven programming, but I still don't see how the two running scripts are going to know how to handle the events, unless the person running the script intervenes. The first script to catch the event will handle it, and the other script will not. But the reason the other script is running is because it's supposed to handle those events. So why be running it at all? Why not just stop the script instead of lowering the priority? Isn't it the same result?


Sat Dec 29, 2012 3:39 pm
Profile ICQ
Veteran Op

Joined: Tue Nov 28, 2006 4:04 pm
Posts: 5025
Unread post Re: Weapon M Scripting Tutorial
Astrochimp wrote:
Mongoose wrote:

You can now. But it's not magic, it's science. :wink:
.


I don't really get it... you still have to decide which script is going to handle the event, don't you? A state machine has to be deterministic...

I understand that with this event-driven stuff you do have more control over which script handles an event, but the person running the script still has to decide which script will handle a given event.


I agree with you. What if I want to buy down a port and the helper decides to megarob the port instead.
Or what if I want to upgrade a cit and the helper decides to detonate the planet instead. I can see all sorts of issues with this.


Sat Dec 29, 2012 3:41 pm
Profile
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Big D wrote:

I agree with you. What if I want to buy down a port and the helper decides to megarob the port instead.
Or what if I want to upgrade a cit and the helper decides to detonate the planet instead. I can see all sorts of issues with this.


Yeah, well as far as I can gather, he's saying that when you run a script to buy down the port, you set its priority higher than all the other scripts you have running. But that just means the port buydown will handle any conflicting events. As far as I can tell, non-conflicting events will still be processed by all scripts, which makes no sense to me, because a script is expecting certain sequences of events. If an event in script A is skipped because it's handled by script B, then script A is now in an inconsistent state.


Sat Dec 29, 2012 3:50 pm
Profile ICQ
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Astrochimp wrote:
Mongoose wrote:
Astrochimp wrote:
If you want to do two things at once, you have to write a script that does it. You can't run a script that is meant strictly for port pair trading, then run some other script that interacts with the command prompt on top of that and expect them to work magically together without a problem.


You can now. But it's not magic, it's science. :wink:

You should read my EDP tutorial.


I guess I'd need to run through an example. I understand event-driven programming, but I still don't see how the two running scripts are going to know how to handle the events, unless the person running the script intervenes. The first script to catch the event will handle it, and the other script will not. But the reason the other script is running is because it's supposed to handle those events. So why be running it at all? Why not just stop the script instead of lowering the priority? Isn't it the same result?


Okay Mongoose, I read your event-driven blurb twice, but I already have the education for all this; I'm a software developer. I still don't see how you'll prevent scripts from conflicting with each other. You're just handling the conflicts more gracefully.

I do see that there are advantages, but it's not going to prevent situations like the ones Micro was talking about. If you keep many scripts running, there are going to be problems unless the scripts were written to take into account the running of the other scripts and know exactly what the other scripts are trying to do.


Sat Dec 29, 2012 4:06 pm
Profile ICQ
Commander
User avatar

Joined: Mon Oct 29, 2001 3:00 am
Posts: 1096
Location: Tucson, AZ
Unread post Re: Weapon M Scripting Tutorial
Say two scripts are listening for the COMMAND_PROMPT event. Both of them will handle it, but the order in which they handle it will be random. If both scripts try to send a command in response to the same event, the first one will succeed and the second one will fail. Whenever a handler finds itself unable to write to the network, in most cases it should just return and try again the next time the event comes around.

As a concrete example, say you're running a world SSM script and a who-is-online updater. When the updater handles a command prompt, it may attempt to send a '#' depending on how long it's been since the last update. Most of the time, it won't send anything and the SSM script will be able to act on the prompt. If the updater sends something, the SSM script won't be able to act; it will simply wait for the next prompt. On the other hand, if the updater wants to act but the SSM script got the event first, the updater will have to wait. But another COMMAND_PROMPT will soon follow, and both scripts will have an equal chance to do their thing. And neither script has to be aware of the other.

As for scripts that perform a sequence of events... consider a charge script. You obviously don't want some other script to respond to one of the command prompts along the way. So the charge script would explicitly lock the network, send the burst, and unlock the network when it sees the last event it expected from the burst.

It may sound complicated, but it's actually quite elegant.

_________________
Suddenly you're Busted!


Sat Dec 29, 2012 4:19 pm
Profile WWW
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Mongoose wrote:
Say two scripts are listening for the COMMAND_PROMPT event. Both of them will handle it, but the order in which they handle it will be random. If both scripts try to send a command in response to the same event, the first one will succeed and the second one will fail. Whenever a handler finds itself unable to write to the network, in most cases it should just return and try again the next time the event comes around.

As a concrete example, say you're running a world SSM script and a who-is-online updater. When the updater handles a command prompt, it may attempt to send a '#' depending on how long it's been since the last update. Most of the time, it won't send anything and the SSM script will be able to act on the prompt. If the updater sends something, the SSM script won't be able to act; it will simply wait for the next prompt. On the other hand, if the updater wants to act but the SSM script got the event first, the updater will have to wait. But another COMMAND_PROMPT will soon follow, and both scripts will have an equal chance to do their thing. And neither script has to be aware of the other.

As for scripts that perform a sequence of events... consider a charge script. You obviously don't want some other script to respond to one of the command prompts along the way. So the charge script would explicitly lock the network, send the burst, and unlock the network when it sees the last event it expected from the burst.

It may sound complicated, but it's actually quite elegant.


I get all this, but a who-is-online script is very simple and already works fine in twx with other scripts running; your example only works because it's simple enough that there is no real conflict. The who-is-online can safely miss some events, but more complicated scripts cannot.

I'm not the one saying it sounds too complicated. Like I said, there are advantages. But running complex scripts concurrently is still not going to work. Sure, the conflicts are handled more gracefully, but the lower priority scripts still miss events. If you don't mind them missing their events (as with who-is-online), then you can keep them running; otherwise, might as well stop them anyway before running the conflicting higher-priority script, since the lower priorities are going to hang anyway. Unless the higher-priority is just a short script, in which case you're really just pausing the other scripts while waiting for the new one to finish. I suppose that's helpful to some extent, but not to the extent that you can just run any scripts you want. Still have to decide, do I want to SST or do I want to do a ZTM? Do I want to be doing a dock-kill right now, or do I want to port-pair-trade? Gotta choose one or the other, not both.


Sat Dec 29, 2012 4:29 pm
Profile ICQ
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Here's my example.

There is a script running at medium priority: Port buydown

User wants to start a citkill. Let's say it's not a very smart citkill script, and that a requirement of the script is that it must be started from citadel prompt.

So user starts up citkill at highest priority. Next time the the citadel prompt event is encountered, citkill takes over and port buydown stops.

User decides at some point to stop citkill, so port buydown starts handling events again. But when user stopped citkill, he stopped it at the sector command prompt, and port buydown is still waiting for the citadel prompt.

This is just a simple example... not serious, user just enters citadel manually and on goes the buydown. But hopefully you can see how it could get much more complicated.


Last edited by Astrochimp on Sat Dec 29, 2012 5:01 pm, edited 1 time in total.



Sat Dec 29, 2012 4:55 pm
Profile ICQ
Commander
User avatar

Joined: Mon Oct 29, 2001 3:00 am
Posts: 1096
Location: Tucson, AZ
Unread post Re: Weapon M Scripting Tutorial
No script ever "misses" an event. It may not be able to respond to an event if another script has already done so, but it will always receive it.

Astrochimp wrote:
Still have to decide, do I want to SST or do I want to do a ZTM?


I don't know why you would ever want to, but yes, you could SST and ZTM at the same time! A typical ZTM script would use the CIM and lock the network for the duration, but if you wrote one that accessed the computer from the command prompt, you could run it at the same time as a cashing script. It would be pointless, but it would work. Even Big D's contrived examples would work. It would be silly to run buydown and megarob scripts at the same time, but if you did, they would work. By which I mean, if both scripts are properly written (which I've made easy to do), it is guaranteed that only one input would be sent to any prompt. The competition between the scripts would result in one of them doing what it wants part of the time, and the other doing what it wants part of the time. Their interaction might not make sense (e.g., you'd end up with an exhausted port that might not have enough credits on it to megarob), but at no time would anything happen that neither script commanded to happen. You would not be sent randomly careening across the universe, as so often happens when TWX scripts compete.

_________________
Suddenly you're Busted!


Sat Dec 29, 2012 4:59 pm
Profile WWW
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Mongoose wrote:
No script ever "misses" an event. It may not be able to respond to an event if another script has already done so, but it will always receive it.


I don't see how that matters... it can't respond to the event. I guess I should have said it misses its chance to handle the event.


Sat Dec 29, 2012 5:04 pm
Profile ICQ
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Mongoose wrote:
By which I mean, if both scripts are properly written (which I've made easy to do), it is guaranteed that only one input would be sent to any prompt. The competition between the scripts would result in one of them doing what it wants part of the time, and the other doing what it wants part of the time. Their interaction might not make sense (e.g., you'd end up with an exhausted port that might not have enough credits on it to megarob), but at no time would anything happen that neither script commanded to happen. You would not be sent randomly careening across the universe, as so often happens when TWX scripts compete.


Ummm... ookay I think I understand you now. Herein lies the rub:
Mongoose wrote:
if both scripts are properly written


I agree, if both scripts are written properly, taking into account all these issues, then yes, it will work. And it`s probably a lot easier to do it than with twx. But it`s still going to be very difficult. Most scripts will not be "properly written".


Sat Dec 29, 2012 5:10 pm
Profile ICQ
Commander
User avatar

Joined: Mon Oct 29, 2001 3:00 am
Posts: 1096
Location: Tucson, AZ
Unread post Re: Weapon M Scripting Tutorial
First of all, there's no priority system other than that one script may lock the network. So say the citkill script gets first shot at a citadel prompt and locks the network. The buydown script is now stuck until the citkill script releases the lock. You're correct about what would happen if the citkill script ended at the command prompt. A well-behaved script should return to the prompt where it started, if it makes sense to do so. But if it doesn't, or if the user kills it, the important thing is that nothing is broken. Other scripts can still resume right where they left off, and they need not coordinate with each other to do so.

Consider what would happen if you ran buydown and citkill at the same time in TWX. If you're lucky, one or both of them would probably end up hung on waitfor race conditions. If you're unlucky, a race condition might have you bwarping to a random sector. This is the kind of thing Weapon M is designed to avoid.

_________________
Suddenly you're Busted!


Sat Dec 29, 2012 5:19 pm
Profile WWW
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Yup, I get you. I did already agree: conflicts are handled more gracefully. Still doesn't mean you can run scripts willy nilly and expect them to interact the way you want them to, especially if the person running the scripts doesn't understad the internals of the scripts (and most people don't).

Anyway... I'm eager to try it out now.


Sat Dec 29, 2012 5:23 pm
Profile ICQ
Commander
User avatar

Joined: Mon Oct 29, 2001 3:00 am
Posts: 1096
Location: Tucson, AZ
Unread post Re: Weapon M Scripting Tutorial
Astrochimp wrote:
Most scripts will not be "properly written".


There is really only one way for a script to screw up, and that's by sending a burst without locking the network. A badly-behaved script could lock the network and never give other scripts a chance to do anything, or it could exit at a different prompt than the one it started at, but these things wouldn't really cause any harm.

_________________
Suddenly you're Busted!


Sat Dec 29, 2012 5:28 pm
Profile WWW
Ensign
User avatar

Joined: Mon Dec 26, 2011 8:41 am
Posts: 206
Unread post Re: Weapon M Scripting Tutorial
Mongoose wrote:

There is really only one way for a script to screw up, and that's by sending a burst without locking the network. A badly-behaved script could lock the network and never give other scripts a chance to do anything, or it could exit at a different prompt than the one it started at, but these things wouldn't really cause any harm.


Oh, I see, the script writer must lock the network explicitly, I get it. But this is not really about event-driven programming, it's about locking resources.


Sat Dec 29, 2012 5:33 pm
Profile ICQ
Display posts from previous:  Sort by  
Reply to topic   [ 48 posts ]  Go to page Previous  1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware.