| Author |
Message |
|
Micro
Ambassador
Joined: Wed Apr 20, 2011 1:19 pm Posts: 2559 Location: Oklahoma City, OK 73170 US
|
 Re: Weapon M Scripting Tutorial
If I understand what you are saying, when a string of text is received, the tokens are searched for a match to the string, instead of searching the string for one of several strings?
What information are you using as a token?
_________________ Regards, Micro Website: http://www.microblaster.net TWGS2.20b/TW3.34: telnet://twgs.microblaster.net:2002
ICQ is Dead Jim! Join us on Discord: https://discord.gg/zvEbArscMN
|
| Wed Nov 28, 2012 12:05 am |
|
 |
|
Mongoose
Commander
Joined: Mon Oct 29, 2001 3:00 am Posts: 1096 Location: Tucson, AZ
|
 Re: Weapon M Scripting Tutorial
It's more like, when a string of text is received, the string is searched for matches to hundreds of different tokens at once, all in a single pass. The token definitions are in an XML file that is compiled into Java code by another program I wrote. A snippet: Code: <!-- quick stats are in their own state because they mostly don't contain ANSI and could easily be spoofed --> <RuleGroup> <State name="QUICK_STATS"/> <Rule expr="Sect {SECTOR}" event="quickSector"/> <Rule expr="Turns {THOUSANDS}" event="quickTurns"/> <Rule expr="Creds {THOUSANDS}" event="quickCredits"/> <Rule expr="Figs {THOUSANDS}" event="quickFighters"/> <Rule expr="Shlds {THOUSANDS}" event="quickShields"/> <Rule expr="Hlds {NN_INTEGER}" event="quickHolds"/> <Rule expr="Ore {NN_INTEGER}" event="quickInvOre"/> <Rule expr="Org {NN_INTEGER}" event="quickInvOrg"/> <Rule expr="Equ {NN_INTEGER}" event="quickInvEqu"/> <Rule expr="Col {NN_INTEGER}" event="quickInvCol"/> <Rule expr="Phot {NN_INTEGER}" event="quickPhotons"/> <Rule expr="Armd {NN_INTEGER}" event="quickArmids"/> <Rule expr="Lmpt {NN_INTEGER}" event="quickLimpets"/> <Rule expr="GTorp {NN_INTEGER}" event="quickGenTorps"/> <Rule expr="TWarp {NN_INTEGER}" event="quickTransWarp"/> <Rule expr="Clks {NN_INTEGER}" event="quickCloaks"/> <Rule expr="Beacns {NN_INTEGER}" event="quickBeacons"/> <Rule expr="AtmDt {NN_INTEGER}" event="quickAtomics"/> <Rule expr="Crbo {THOUSANDS}" event="quickCorbomite"/> <Rule expr="EPrb {NN_INTEGER}" event="quickProbes"/> <Rule expr="MDis {NN_INTEGER}" event="quickDisruptors"/> <Rule expr="PsPrb [YN]" event="quickPsyProbe"/> <Rule expr="PlScn [YN]" event="quickPlanetScan"/> <Rule expr="LRS [HDN]" event="quickLongRangeScan"/> <Rule expr="Aln {THOUSANDS}" event="quickAlign"/> <Rule expr="Exp {THOUSANDS}" event="quickXP"/> <Rule expr="Corp {NN_INTEGER}" event="quickCorp"/> <Rule expr="Ship {NN_INTEGER}" event="quickShipNumber"> <JumpState name="CORRECT_GAME"/> </Rule> </RuleGroup> I've been trying to think of a concrete example to illustrate the advantages of the event-driven system. Remember that story about how somebody... I think it was t0yman... ran a SS scanner script that went to every channel and said something to make an enemy corp think one of their members was a traitor? It created such a ruckus that JP added some delay or limit to how often you can switch SS channels. I'm not sure exactly what the limit is, but say it's 10 seconds. Nobody would run a SS sweeper that can only hit one channel every 10 seconds, right? That would take over three days to have a 50% chance of hitting the right channel. But with Weapon M, you could run that kind of sweeper script concurrently with other scripts. The logic of the sweeper script would be like this: every time you get a COMMAND_PROMPT event, if it's been more than 10 seconds since changing channels, try to send the commands to do it. If you get a NetworkLockedException because another script already responded to the COMMAND_PROMPT, no problem; just wait for the next one. If you succeed, ignore COMMAND_PROMPTs for the next 10 seconds. Meanwhile, other scripts will be using those COMMAND_PROMPTs to trade or do whatever. Sick, huh?
_________________ Suddenly you're Busted!
|
| Wed Nov 28, 2012 12:52 am |
|
 |
|
T0yman
Veteran Op
Joined: Sat Dec 29, 2007 5:06 pm Posts: 2059 Location: Oklahoma
|
 Re: Weapon M Scripting Tutorial
It was Helix that had a SS crawler, I wrote one messing around but never used it. 
_________________ T0yman (Permanently Retired since 2012) Proverbs 17:28 <-- Don't know it, most should it would stop a lot of the discussions on here.
|
| Wed Nov 28, 2012 6:38 am |
|
 |
|
Micro
Ambassador
Joined: Wed Apr 20, 2011 1:19 pm Posts: 2559 Location: Oklahoma City, OK 73170 US
|
 Re: Weapon M Scripting Tutorial
I think the WaitFor paradigm has a big problem in this area. Suppose two scripts are running at the same time. Both scripts are waiting for the command prompt. Both scripts would continue at the same time.
Anyone know how does TWX handle this?
_________________ Regards, Micro Website: http://www.microblaster.net TWGS2.20b/TW3.34: telnet://twgs.microblaster.net:2002
ICQ is Dead Jim! Join us on Discord: https://discord.gg/zvEbArscMN
|
| Wed Nov 28, 2012 12:12 pm |
|
 |
|
mob
Boo! inc.
Joined: Sat Oct 09, 2004 2:00 am Posts: 865 Location: USA
|
 Re: Weapon M Scripting Tutorial
Micro wrote: I think the WaitFor paradigm has a big problem in this area. Suppose two scripts are running at the same time. Both scripts are waiting for the command prompt. Both scripts would continue at the same time.
Anyone know how does TWX handle this? I think this really depends on what your scripts are told to do. If one is processing data and the other is entering commands as a reaction then you should be ok. If your running two scripts and they are both waiting on the same text then you might run into a problem but that sounds more like a scripting issue / user problem.
_________________ “The object of war is not to die for your corp but to make the other bastard die for his.”
Boo! inc.
|
| Wed Nov 28, 2012 12:15 pm |
|
 |
|
Micro
Ambassador
Joined: Wed Apr 20, 2011 1:19 pm Posts: 2559 Location: Oklahoma City, OK 73170 US
|
 Re: Weapon M Scripting Tutorial
If the background script only collects data, it wouldn't cause any problems. So you are saying that you can't run two scripts in TWX where both send commands? Take Mongooses example above though. You fire off a background SS Crawler script, and the assume you can run a cashing script. The Cashing script would port and eventually return to the command prompt. At this time, both scripts would try to continue. The SS Crawler is going to send "C" for computer. You better hope the other script doesn't send a "BY"  With the event driven paradigm messages bubble up from the handler with the lowest priority to the one with the highest priority. All one would have to do is set the priority on the background script lower than the priority of the cashing script, and return e.handled when the cashing script processes the command prompt event.
_________________ Regards, Micro Website: http://www.microblaster.net TWGS2.20b/TW3.34: telnet://twgs.microblaster.net:2002
ICQ is Dead Jim! Join us on Discord: https://discord.gg/zvEbArscMN
|
| Wed Nov 28, 2012 12:48 pm |
|
 |
|
mob
Boo! inc.
Joined: Sat Oct 09, 2004 2:00 am Posts: 865 Location: USA
|
 Re: Weapon M Scripting Tutorial
Micro wrote: I think the WaitFor paradigm has a big problem in this area. Suppose two scripts are running at the same time. Both scripts are waiting for the command prompt. Both scripts would continue at the same time.Anyone know how does TWX handle this? Grin... We both know thats not true. Maybe I misunderstood the issue. I read.. Micro wrote: I think the WaitFor paradigm has a big problem in this area. Suppose two scripts are running at the same time. Both scripts are waiting for the command prompt. Both scripts would continue at the same time. Anyone know how does TWX handle this? I guess my point was if a user is running two scripts he/she better know what they do and when. If they are both waiting on the command prompt and both fire off doing different things the outcome could be ##SD##. TWX will fire off whatever the scripts tell it to do.
_________________ “The object of war is not to die for your corp but to make the other bastard die for his.”
Boo! inc.
|
| Wed Nov 28, 2012 1:33 pm |
|
 |
|
Micro
Ambassador
Joined: Wed Apr 20, 2011 1:19 pm Posts: 2559 Location: Oklahoma City, OK 73170 US
|
 Re: Weapon M Scripting Tutorial
The point is that Mongoose's event-driven paradigm would allow background scripts to run at the same time as foreground scripts. Another good example is Zero Turn Mapping (ZTM). Right now you may as well log off for x hours because you can't do anything else. With weapon m's event-driven paradigm, you could still do other stuff while ZTM is running.
I think I have a few ideas that would allow FirstMate to do this as well. I'm also experimenting with distributed ZTM, were two or more teammates could be running ZTM. Each player would be given a block of sectors, and the data would be combined to create a complete map.
_________________ Regards, Micro Website: http://www.microblaster.net TWGS2.20b/TW3.34: telnet://twgs.microblaster.net:2002
ICQ is Dead Jim! Join us on Discord: https://discord.gg/zvEbArscMN
|
| Wed Nov 28, 2012 1:47 pm |
|
 |
|
mob
Boo! inc.
Joined: Sat Oct 09, 2004 2:00 am Posts: 865 Location: USA
|
 Re: Weapon M Scripting Tutorial
 @Micro, I think we are saying the same thing bro. I have written a few scripts with TWX and thought I knew my way around the langauge. This just looks complicated. Im not a programmer though.
_________________ “The object of war is not to die for your corp but to make the other bastard die for his.”
Boo! inc.
|
| Wed Nov 28, 2012 2:15 pm |
|
 |
|
Micro
Ambassador
Joined: Wed Apr 20, 2011 1:19 pm Posts: 2559 Location: Oklahoma City, OK 73170 US
|
 Re: Weapon M Scripting Tutorial
I can't deal with TWX script. Reading it gives me a headache.... lol 
_________________ Regards, Micro Website: http://www.microblaster.net TWGS2.20b/TW3.34: telnet://twgs.microblaster.net:2002
ICQ is Dead Jim! Join us on Discord: https://discord.gg/zvEbArscMN
|
| Wed Nov 28, 2012 4:58 pm |
|
 |
|
Tweety
Boo! inc.
Joined: Fri Jan 04, 2002 3:00 am Posts: 221 Location: Canada
|
 Re: Weapon M Scripting Tutorial
how are you going to effectively do something else while you are running a ztm script? your ztm script is sending commands to the game and waiting for data back. if you pause that and then try to do something else, you are going to make ztming much longer of a task.
You can't, or i would never trade or cash at the same time as ztming. because it simply can't be done. unless you are ztming between a corpie running some turns until he busts.
data collection sure, that I can see because it isn't sending anything back. but i'd hope it would be able to collect the same data that the other script is grabbing. I wouldn't want one script to block out the other script of certain event data collected.
say you have a photon script running for the report sector event trigger. you want that script to fire, but then your sector data tracking script which is monitoring activity for sectors based on the report sector event trigger jumps in and says that its my turn to use this event!. it would be more appropriate if they were to share that event so that they can both use it equally. you wouldn't want one script to not see it.
I think it should be up to the user to make sure that they don't run two conflicting scripts
|
| Wed Nov 28, 2012 6:35 pm |
|
 |
|
Astrochimp
Ensign
Joined: Mon Dec 26, 2011 8:41 am Posts: 210
|
 Re: Weapon M Scripting Tutorial
Micro wrote: The point is that Mongoose's event-driven paradigm would allow background scripts to run at the same time as foreground scripts. Can't we already do that with twx? I mean, of course not with ztm, but that's because trade wars doesn't let you warp around and stuff while querying the computer, right? Micro wrote: Take Mongooses example above though. You fire off a background SS Crawler script, and the assume you can run a cashing script. The Cashing script would port and eventually return to the command prompt. At this time, both scripts would try to continue. The SS Crawler is going to send "C" for computer. You better hope the other script doesn't send a "BY"  Running two scripts at the same time that both are trying to interact with the command prompt makes no sense, unless they are intended to be run concurrently. It doesn't matter at all what scripting paradigm you're using.
_________________ I'm a monkey and I have mad monkey skills for hire. https://codemonkeyfromspace.com
|
| Fri Dec 28, 2012 11:02 pm |
|
 |
|
Astrochimp
Ensign
Joined: Mon Dec 26, 2011 8:41 am Posts: 210
|
 Re: Weapon M Scripting Tutorial
Micro wrote: I think the WaitFor paradigm has a big problem in this area. Suppose two scripts are running at the same time. Both scripts are waiting for the command prompt. Both scripts would continue at the same time.
Anyone know how does TWX handle this? It's not waitfor that has a problem, it's the person running the scripts. 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. Not in any paradigm. This isn't magic, it's science; you have to tell the computer how to handle every situation; it can't read your mind. Micro wrote: With the event driven paradigm messages bubble up from the handler with the lowest priority to the one with the highest priority. All one would have to do is set the priority on the background script lower than the priority of the cashing script, and return e.handled when the cashing script processes the command prompt event. I can't see how assigning priorities to scripts would be much help. Just stop or pause your C script before starting your BY script. When you talk about a command prompt event, even if he has done all the work or used some library to help treat these text strings coming across the wire more as real events that can be 'handled', I still don't see how that would allow running command-interactive scripts concurrently unless they were specifically written to be run concurrently. It might be easier to write such scripts under such a paradigm, but sounds pretty complex and I'm not sure why you'd want to write scripts like that when it's probably a lot easier to just write a bigger script that does it all, without having to worry about concurrency issues (and remember, these are not concurrency issues in the normal sense of multiple threads competing for a computer's resources, this is different; this is like if you and your friend were trying to play the exact same trade wars account at the same time but didn't know the otehr guy was also logged on... the same thing would happen... one guy would wait for command prompt and press C, the other guy might press BY and you're both screwed).
_________________ I'm a monkey and I have mad monkey skills for hire. https://codemonkeyfromspace.com
|
| Sat Dec 29, 2012 4:57 am |
|
 |
|
Astrochimp
Ensign
Joined: Mon Dec 26, 2011 8:41 am Posts: 210
|
 Re: Weapon M Scripting Tutorial
Mongoose wrote: I may eventually give scripts the ability to create custom text events, but it would never be as efficient as the built-in lexer and parser. If it's missing something, I want people to tell me so I can add it. Are you releasing source code?
_________________ I'm a monkey and I have mad monkey skills for hire. https://codemonkeyfromspace.com
|
| Sat Dec 29, 2012 3:12 pm |
|
 |
|
Mongoose
Commander
Joined: Mon Oct 29, 2001 3:00 am Posts: 1096 Location: Tucson, AZ
|
 Re: Weapon M Scripting Tutorial
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. You should read my EDP tutorial. It addresses most of your misconceptions. The source will be released under the BSD license.
_________________ Suddenly you're Busted!
|
| Sat Dec 29, 2012 3:23 pm |
|
 |
|