Yes, that's what I said about your script that would've had the bug of reporting a corporation you no longer belonged to or some photons onboard a ship that can't carry any.  I fail to see how that's relevant.  If you're just being petty and vengeful, which sounds like the case, I'll just ignore your "input" in the future.


Well, the version that didn't use RAWPACKET did exactly that.  Which is again why I posted the script.  If someone could figure a way to use RAWPACKET and *not* cut out the "Sect" in front, we'd be golden.  It's called "collaboration" and/or "brainstorming".  People toss out their ideas, regardless of how good or bad they think they might be, and other people IMPROVE UPON THEM.  You also need to learn the difference between vengeful criticism (I didn't like his opinion, so I'm going to bash him at the first opportunity!  MUAHAHA he made a MISTAKE!  I must point and laugh!) and constructive criticism (Hey, you have a bug there, it puts extra spaces after some of the data; by adding a stripText " " to the data variable, that can be fixed, but it means one more line.).
Focus more on the second type of criticism in the future.  Please and thank you.

Actually I got it to work. It only visits the label on a FALSE statement. The way it was set up in the code you had it visiting on a TRUE. If I flipped it, it worked.

From the documentation:


Using this to make a do while loop was very clever, and I plan to use it in the future.

Doh!  Thank you.  I knew it had to be something simple.  Sorry I misread the docs there, and glad at least one of my buggy, awful ideas will come in handy in the future.   LOL

w00t! I was able to shed one more line... and probably the absolute last one possible. And indeed, it's due to Xen's idea to use branch. Not because it reduced lines like in my while/end statement (because :label/branch is still 2 lines), but because it allowed me to omit initializing a variable. In a way Xen, your lack of scripting experience is probably the reason you suggested it, because I doubt a single TWX scripter has ever even used that command. Fine job!

So... the count now stands at 11 lines. 11!!!

+EP+

Looking forward to seeing your solution. I wish I had more time to play with it

During the course of this challenge, I came up with some pretty radical notions, much like the rest of you. I actually have a pretty radical *10* line routine that arguably meets the requirements, and a notion of how to attempt a 9-liner, but neither would really be practical.

In the end, my most concise approach came by leveraging the layout of a quick stat line, where all but the first and last set of stats are bordered by the little divider characters (#179). It's easy to add a divider at the beginning and end, introducing a consistent block of data: divider, stat name, stat value, divider. Here is the code for the non-branch version:

{There is an updated version on pg. 4 of this thread. Please use that version}

:quickStatSub
send "/"
waitOn #179 & "Turns "
while (CURRENTANSILINE <> #13)
     setVar $block 0
     while ($block <> "")
# This next line reads: from "0¦CURRENTLINE¦¦", get the data
# between the last $block & "¦", and save as the new $block
             getText 0 & #179 & CURRENTLINE & #179 & #179 $block $block & #179 #179
             getWord $block $stat 1
             getWord $block $quickStat[$stat] 2
             stripText $quickStat[$stat] ","
     end
     waitOn ""
end
return

And finally, the same method tweaked to utilize BRANCH, taping out at 11 lines.

{There is an updated version on pg. 4 of this thread. Please use that version}

:quickStatSub
send "/"
waitOn #179 & "Turns "
while (CURRENTANSILINE <> #13)
     :label
     getText 0 & #179 & CURRENTLINE & #179 & #179 $block $block & #179 #179
     getWord $block $stat 1
     getWord $block $quickStat[$stat] 2
     stripText $quickStat[$stat] ","
     branch ($block = "") :label
     waitOn ""
end
return

There are a couple of limitations to a routine this short, and I'll elaborate on them tomorrow. I'd also like to propose a more practical solution for the everyday quickstat routine, which I'll try to post tomorrow as well.

Feel free to critique this approach, and I'd love to hear how another line or two can be shaved

+EP+

Nice work EP. Pretty darn concise code. Though Corp Number and Photons are not intialized --as somone pointed out to me not too long ago-- could that be one of the limitations your alluding too, or, that quickstat isn't initialized itself?

I can get it 3 lines.
Yes 3.

Open Icq
Click on EP
Ask him for a good routine


See easy as pie.

His will be better then mine

Ha! I can do it in 2 since I've already got icq open... =)

gosub :quickie

-------------------

I am still curious if these methods have a practical use, or advantage that I don't understand. As a scripting exercise it proved interesting to see what people came up with. The "branch" command I had seen before, but since the help file seemed to discourage its use, I stayed away from it.

I never use arrays for my quick stats and use descriptive names for the info that is returned, i.e., $ship_figs, $trader_align and so on. I also grab the current sector from this for backward compatibility.

The main reason for maintaining backward compatibility is the intermittent problem of Swath freezing when running some scripts under 2.04 Final (2_worldtrade for instance). I did not have this problem prior to "Final" and it may be something that I have added (or MS added) unrelated to "Final".

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

Heh WS... that is short

Promethius, a quickstat routine is a practical addition or include for lots of scripts. Think of how many scripts you have written that utilize one or more of the values present in the quickstat display. Consider the next time you want to grab your current ship number, do it this way:

include qstat
gosub :qstat~quickStatSub
setVar $creds $qstat~quickStat[SHIP]

The tiny 11 line version has 2 limitations, one real and one trivial. First, the stat names are not uppercase. This means that every time you want to grab a stat, you have to use a a string with the same case as the index... so in the above example to Prom, you'd have to actually grab the ship number like this:

setVar $index "Ship"
setVar $creds $qstat~quickStat[$index]

TWX complains about quoted text as the index, so ["Ship"] won't work. But, TWX treats any unquoted text as uppercase. So if the stat names were uppercase when the values were saved, then you can use unquoted text to retrieve them from the array... [creds] or [CredS], as both are converted to CREDS, thereby matching the array index.

The other, less serious limitation is that Phot and Corp aren't zeroed if they don't exist. No biggie by itself, but if you drop corp, then the quickstat array will reflect your old corp number. Still, I doubt any scripts query Corp number more than once. And I have no idea what happens if you have Photons on board and the sysop disables them... but don't play there again.

As an aside, I couldn't make any stat name and value fall on different lines, not even ship type, so I believe parsing CURRENTLINE is fine, even for ship type. I believe the following code properly addresses all of the above issues, yet remains quite concise, and doesn't leave bulky unnecessary variables in the variable dump to boot.

{There is an updated version on pg. 4 of this thread. Please use that version}
:quickStatSub
setArray $quickStat 0
send "/"
waitOn #179 & "Turns "
while (CURRENTANSILINE <> #13)
     # This line means: Grab the block of text between the next set of dividers
     getText #179 & CURRENTLINE & #179 & #179 $block $block & #179 #179
     while ($block <> "")
               getWord $block $stat 1
               upperCase $stat
               getWord $block $quickStat[$stat] 2
               # This next line finally succeeds on the Ship number/type block
               getWord $block $quickStat[TYPE] 3
               # Optionally, uppercase $quickStat[$stat] and $quickStat[TYPE] here.
               stripText $quickStat[$stat] ","
               getText #179 & CURRENTLINE & #179 & #179 $block $block & #179 #179
     end
     waitOn ""
end
return

I've enjoyed this exercise. I hope everyone learned a trick or two from it... I know I did. I'm interested to hear any further ideas you guys might have on the matter, or how you might improve upon these snippets.

+EP+

Consider, you're in a ship with Photons.. you export or end up in a ship w/o Photons... your script will still 'see' Photons on board.

I have been using a quick stats routine, but not with arrays. I like to be able to easily read my code and know what it is doing and since I am terrible about commenting code, variables that mean something are about the best way.

What I am failing to understand in your code snippet above is the [SHIP] attached to the array. It would appear crash that way - haven't tried it.   Where is it getting its value? Is SHIP a constant of some type? It would appear to have to be setup more like
setVar $creds $qstat~quickStat[$SHIP]

I have to be missing something.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

It's setting the names of the dynamic array's indexes with the names that show up in the quickstat list.  It creates the name AND stores the data.
So if John released some new version of TW that added Quatzits as an item you could have on your ship, and added that to the quickstat listing as "|Quaz 32497|" EP's quickstat would automatically create $quickstat[QUAZ] and fill it with 32497.
The $quickstat[SHIP] EP is referring to is the last data listed on the / screen, the "|Ship 7 MerFre" or whatever.  It'd store 7 to $quickstat[SHIP].  Not $SHIP, SHIP.  Ship isn't a variable or constant, it's the name of an array location.  If you're familiar with other programming contexts, think of dynamic arrays as maps.  The name of the array location is the key to look up the value.  EP's routine creates keys named what the names are on /, and stores the values associated with those keys as the number directly following those names on /.
Edit: If you're NOT familiar with maps, they're quite simple.  They're like an array (though usually implemented as a binary tree, so they automatically sort by key), but instead of just numbers for each thing stored ($arrayname[0], $arrayname[1], $arrayname[2]), they use a key that can be something other than an integer.  In TWX's case, they use strings as keys.  So you'd be using $mapname["Sect"], $mapname["Turns"], $mapname["Creds"], etc.  (Except TWX has a bug and won't work with quotes in there so things need to be uppercase...  So $mapname[SECT], $mapname[TURNS], $mapname[CREDS] instead.  That's the issue EP was referring to.)

Ok, that is something I did not know about. I thought arrays had to be $ship[1], $ship[2] and so on although the number could be replaced with the variable equivalent, such as $count. This clears up how the array would be able to be descriptive and makes sense.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."