View Full Version : Lich SF vs Wizard
Deathravin
05-30-2007, 02:14 PM
Ok, am trying to figure out which one to use... I generally don't like Stormfront because you can't have just one pane up and have it not scroll you down to the bottom every time you look in your backpack... It's petty, but it's not my only problem with it. However, what do I care if I'm scripting, right?
Lich can do certain things in SF that it can't do in Wiz
Lich can do certain things in Wiz that it can't do in SF
I was curious what the differences were with Lich in the different FEs. It's all listed on his site, but it's not in a pro/con list of each FE.
Celephais
05-30-2007, 02:48 PM
I don't know anything about Lich specifically, but the stormfront XML contains some extremely useful information that cannot be gleaned from the WIZ GSL streams. The GSL provides nothing that SFXML doesn't have.
The easiest to explain example of why SF is better is because of the exists tags that come with every link sent. When a monster attacks you in the wizard, all the wizard knows is "a giant rat attacked you" but SF essentially knows "third giant rat attacked you". What with the SF room window telling you that "first giant rat is stunned" you can have your script target "other giant rat", because the first is stunned and second is in RT.
You cannot do that with the wizard. The SF xml also lets you write exploritory code, because you can use the links to identify which items to investigate (and you can even use the link menu responses to give you a method to investigate... although that doesn't always include everything)
Deathravin
05-30-2007, 03:10 PM
Way off topic there for a second... Does Lich know about the rat (stunned, prone), 2nd rat (stunned, prone), 3rd rat (alive and angry)?
Celephais
05-30-2007, 03:15 PM
you type:
Target rat
Sweep rat
Target other rat
fire
... you can do that in both Wizard and SF... the advantage comes from info given to the user. Essentially all objects in GS are given an "exists" key.
Wizard:
Catacombs
You also see a giant rat that is laying down, a giant rat that is stunned,
a giant rat that is laying down.
a giant rat stands up.
SF:
Catacombs
You also see a giant rat(1) that is laying down, a giant rat(2) that is stunned,
a giant rat(3) that is laying down.
a giant rat(3) stands up.
>Sweep third rat
SF will also update you IMMEDIATLY when (2) unstuns, no need to look to be sure.
Celephais
05-30-2007, 03:32 PM
Let me explain a few other advantages these exists keys give you...
You also see an ithizir scout(1), and an ithizir scout(2).
an ithizir scout(1) disarms you!
an ithizir scout(2) picks up your bloodstained death sword!
an ithizir scout(1) goes east.
an ithizir scout(2) goes west.
>west
You also see an ithizir scout(3), an ithizir scout(4), an ithizir scout(2).
{about 7 scouts go in and out}
>kill (2)
You recover your gruesome blade!
That situation would be impossible with the wiz data stream... you wouldn't know the position (other/third/whatever since some are moving in and out) or even which way to follow.
You also see an ithizir scout, and an ithizir scout.
an ithizir scout disarms you!
an ithizir scout picks up your bloodstained death sword!
an ithizir scout goes east.
an ithizir scout goes west.
>west (by chance)
You also see an ithizir scout, an ithizir scout, an ithizir scout.
{about 7 scouts go in and out}
>kill third scout
BZzzzT wrong, the scout is now "other" scout because of the ones moving in and out, you lose.
Hell the exist keys are consistent across players (just not across uh.. existance.. when equipment "logs out" with you, their keys get reclaimed), you could be dead and get looted, and then tell your friend "track down a scout with exists 839420, he's got my sword".
The SF doesn't even have to send "other/third" it can just send the exists key. I never use my mouse, but I program to SF because I want the extra info.
You could write a program that whenever you weigh a box, stores that exist key with the weight, then when you look in your container it could say: "a modwir trunk (12lb), a modwir trunk (17lb), a modwir trunk (38lb)".
Deathravin
05-30-2007, 03:40 PM
You mean with the room window. I think I'd use that more if it would auto-scale to the # of lines of the room... I'm a firm believer in if you're going to do something, do it right. And it just seems like Wizard was done simply, but correctly. Stormfront they did complexly, but it's generally unpolished.
It actually gives you a # after thier name? I've never seen that.
What would be nice in SF is if it said, "You also see a giant rat, a giant rat, a giant rat (target), and a giant rat.
For me if I've already been killing Rat 3 for some time, then it is still a threat, I'm not going to waste too much time disabling the other rats, because 3 attacks / round is much better than 4 / round no matter how you slice it. So I wouldn't change my target from one to another.
With the differences between SF and Wiz in Lich, I mean certain Lick commands, variables, options etc, don't work or don't work well in one or the other.
Celephais
05-30-2007, 03:55 PM
The room window can be hidden and you can still have the data availible to Lich (just have Lich squealch it). I actually don't like it auto-scaling, I set my room window up to be plenty big enough for all rooms (I use a small font) and that way it's not jumping around. And what do you mean by "having to scroll to the bottom when you look in your backpack"... the inventory windows are stupid, I hide those, but even with them on they just sit on the side and potentially flicker... I'm not championing for the FE itself, I'm championing for the data stream it uses...
Technically you can use the wizard with a SF XML stream, but no one's written the converter (I've mentioned this to people who ask about these types of questions before, but I have zero desire to write it)
I know lich has access to the data stream, so it might not be able to see exists now but it's certainly capable of it. The dialog streams (windows) are also incredibly useful at event based info, instead of polling (endurance a recent but awesome addition), the active spell window, exp window (instead of just mind state you can tick off amount absorbed without sending "exp")
You asked for the differences in scripting, I told you the potential difference between the two... although I heard Lich does have some trouble with SF, so if you're not planning on writing scripts then yeah... use the Wiz.
Deathravin
05-30-2007, 05:39 PM
The 'having to scroll down' isn't what it sounds like... My SF is set up so there's a pane on the right for my docked windows, and the pane on the left is minimized. So I have docked things like XP, Attacking, Directions, encumberance, etc on the right pane...
When I 'Look in my Backpack' or 'gloves' or something, it puts the inventory of what is in the backpack in a window at the bottom of the dock, and auto-scrolls to it, making me unable to see all the important data I need at the top of the pane until I physically rescroll myself back up there. Even if the window is minimized instead of closed, it still pops me down to the bottom to reopen the window if i re-look. It's maddening.
Also, if I drag it out of the dock, and change its apperance, it drops its apperance and position every time it's reopened (it reloads any container that isn't your default stow or sheath container btw - so if your backpack is your stow container, it will remember its settings)
This problem is resolved if I simply open my other dock and put my stuff in there, but I'd rather not squeese my story window any more than it already is. Or I just use 'inv all' instead of l in my..., but it scrolls my screen too much.
Well what I'm asking, I think, is what problems does Lich have with SF. I see all the time "Not compatable with SF" or "No compatable with Wiz" in scripts in the repository.
fallenSaint
05-30-2007, 06:17 PM
I personally find any time I use StormFront my characters arent nearly as reactive as they are in Wizard. I can log two characters in one in SF and one in Wiz and run a Travel script for instance and the SF window is always several rooms behind updating and to me that means death when Im actually out hunting. Seems to hold true for some other friends of mine that Multi Acct so not sure how noticeable this is to others or maybe its just because we run Multiple Accts but due to that fact alone I couldnt possibly stomach SF.
Deathravin
05-30-2007, 06:21 PM
I completely agree with that thought. It is downright slow when compared to Wizard. I used to do all my hunting in Wizard just because SF wasn't as responsive.
mgoddess
05-30-2007, 07:05 PM
When I 'Look in my Backpack' or 'gloves' or something, it puts the inventory of what is in the backpack in a window at the bottom of the dock, and auto-scrolls to it, making me unable to see all the important data I need at the top of the pane until I physically rescroll myself back up there. Even if the window is minimized instead of closed, it still pops me down to the bottom to reopen the window if i re-look. It's maddening.
Well what I'm asking, I think, is what problems does Lich have with SF. I see all the time "Not compatable with SF" or "No compatable with Wiz" in scripts in the repository.
The inventory window popping up can be disabled via a SF setting... (I don't have the game up right now, but there should be a checkbox in the SF settings labelled "Display Inventory Boxes". You want that UNchecked.)
I use Lich with SF (and BlackLightning) and I have no problem at all with it. I've ran two instances of SF on the same machine, both running decent-sized scripts with no hassle/lag.
*shrug* I like SF versus the Wizard, because I can do a lot more with SF. But everybody has their own likes & dislikes, so YMMV.
Celephais
05-30-2007, 07:33 PM
You can just turn off inventory windows, or even better move things out of that auto-dock pane... that pane does kind of suck, but if you move everything out of the pane and minimize the pane you're fine.
As for the responsiveness I haven't really noticed any issues with SF responsiveness. The information it sends is a bit more verbose, what with the xml tags, and obviously it has to process all the info for the windows, but I've always experienced real time responsiveness (for a while I had two accounts, and saw no issue hunting w/ both and scripting w/ both at the same time, and I have had three accounts open but I don't think I was doing anything intensive). Sounds like a hardware limitation?
Shaelun
05-30-2007, 10:08 PM
First, in answer to your initial question (meaning this is exclusively in regards to Lich), the differences are supposed to be non-existent. However, I didn't include a full-blown XML parser in Lich, so when used with SF, it doesn't make use of all the information available to it. Just about the only thing I can think of off-hand that works in SF but not in Wiz is auto-updated stamina. Scripts can always access your character's current stamina if you're using SF, but in Wizard that information is impossible to keep updated.
The reality of it is that I've always used the Wizard, I began writing the program with the Wizard in mind, and only after I basically "finished" the Wizard functionality did I then write in SF support. Most of the documentation that says "(only available with Wizard)" or some such is old and outdated: I finished the SF support, but not all of it is bug-free. Other than the stamina thing, I don't think there's anything available in SF that you don't have with the Wizard though (again, only in regards to Lich). It works pretty well with SF, but it's -- dare I say -- "rock-solid" when you're playing with the Wizard. That isn't the case with SF.
In a nutshell, if your concern is only scripting, log in using The Wizard.
Completely disregarding Lich, I think StormFront is the better front-end. As I said, I use the Wizard, but that's just because I've used it for too long to get used to anything else... SF is much more pleasing aesthetically, it offers a slew of auto-updated info not available in the Wizard, and it's even easier for them to expand on existing functionality without client updates to boot. That said, it's ridiculously slow: whoever wrote the thing should have made efficiency more of a priority.
Shaelun
05-30-2007, 10:13 PM
Oh, I just remembered something SF/Lich doesn't have: when you're playing with The Wizard, if you enable the option, Lich will automatically queue commands that would definitely result in a "Type ahead limit" error (type ;ta help if you want the details). That doesn't work in SF.
Celephais
05-31-2007, 12:38 AM
Oh, I just remembered something SF/Lich doesn't have: when you're playing with The Wizard, if you enable the option, Lich will automatically queue commands that would definitely result in a "Type ahead limit" error (type ;ta help if you want the details). That doesn't work in SF.
Is there a reason this doesn't work in SF? Just not written or is it some deficencly of the stream (IE the wizard throttles it explicitly and the actual Simu server on the wizard stream doesn't care), or is it more that since SF can respond without a request, it's harder to actually track real responses?
(I've been working on a queue for SF and it's a little shakey due to SF auto-updates)
Deathravin
05-31-2007, 08:52 PM
Well nobody ever said Simu was interested in doing things right over doing things fast. Simu is the most consistancy inconsistant company I've ever known... but that's nither here nor there. Thanks for the info Shaelun.
Shaelun
06-01-2007, 07:26 PM
Is there a reason this doesn't work in SF? Just not written or is it some deficencly of the stream (IE the wizard throttles it explicitly and the actual Simu server on the wizard stream doesn't care), or is it more that since SF can respond without a request, it's harder to actually track real responses?
(I've been working on a queue for SF and it's a little shakey due to SF auto-updates)
It's because of differences in the stream. It's not perfect, but it's surprisingly effective (I've had it work with 10-20 type ahead lines, but it's too unpredictable beyond 1-3 to be useful). Every time Simutronics sends data, they (without fail) send a GSq update to the Wizard -- this is always directly after a "batch of data" sent to the game client, and Lich uses that information to try and gauge whether the game has responded to a command yet or not. Of course, responses to the user's commands isn't the only thing that triggers the game to send data.
SF isn't like that, and I've been told SF allows an infinite type-ahead limit anyway, so I never bothered checking for a similar "tell-tale sign."
Deathravin
06-01-2007, 08:16 PM
SF doesn't have unlimited type-ahead... I've had travel scripts that I sort of encourage to gain type-aheads by hitting a 'look' (you can just resync in wizard to do the same thing) and it's crapped out on me if I try to get more than 1 or 2 'looks'. I just have a premie account so I get just the 1 ahead line anyway, but maybe with 2 server type-ahead lines it's more infinate.
Celephais
06-01-2007, 09:04 PM
Nah, I've got two type aheads in SF and i certainly hit the limit frequently.
What do you mean by "Stormfront isn't like that"? It seems to be very muchso like that, the SF stream will respond to user commands by, without fail, sending a prompt with an updated timestamp. and like the wizard "responses to user's commands isn't the only thing that triggers the game to send [a prompt]".
Would you be able to swap out your GSq detection with a "<prompt time=..." detector and have the same results in Lich? (I was just complaing about the other stuff sending responses...)
Shaelun
06-01-2007, 09:55 PM
I love inaccurate information. It's so helpful, don't you find? :)
I took a quick look at the only decent-sized SF log I have, and it looks as though it just may be that easy, Celephais. But as you said, SF receives such an enormous amount of info and so constantly, I'm not sure if it would end up being useful.
Celephais
06-02-2007, 05:56 PM
I just went to go relook at my "command queue" code and realized what it was I didn't like about it, it's not the responding to any prompt sent by the game (because if I'm queing up commands the stream is pretty good about bundling it's response to my command with whatever else SF would just send), it's the fact that I end up queuing things I could have just sent. I've been toying with a few ideas but it hasn't really been the highest priority, and I'm curious about your success with the method you choose (or what your method is).
Lets say someone enters (I use ZMud style delimiters... parsing ; into a new command... chr(10) + '<c>' in SF, just chr(10) in Wiz):
east;north;east;north
Method 1:
<send>east
<waitPrompt>
<send>north
<waitPrompt>
<send>east
<waitPrompt>
<send>north
Method 2 (assuming only one type head):
<send>east;north
<waitPrompt>
<send>east
<waitPrompt>
<send>north
Method 3:
<send>east;north
<waitPrompt>
<send>east;north
Or do you have some other method of queuing but actually leveraging the typeaheads they give you. (I just find the responsiveness of Method 1 to be too slow, in wiz or SF it's just like always using the "Move" command in the scripts)
Deathravin
06-03-2007, 10:33 PM
I just tried to make Stormfront die on a movement script - can't happen anymore
For movement scripts in SF, I'd say just dispatch with using "move" at all and just use 'put'
Edit - It looks like there just flat out is no type-ahead line limit in SF. I've done 10 command macros that work flawlessly. On any movement script, I hit 'look' 10 times and it gets to be about 8 commands deep... I made some move scripts with all 'put' instead of 'move' and they just go like bats out of hell and never error.
Shaelun
06-09-2007, 10:18 PM
You're sure that it isn't PsiNet's "MoveAhead" feature doing that, Deathravin? I think it's on by default, but Hell if I know.
Lich defaults to 1 typeahead line, and lets you specify how many your account has. Basically it's just a "spinlock" -- you send a command, it increments the counter. Anytime it receives a "bundle" of info, it decrements the counter. If the counter is larger than whatever you specified your typeahead limit to be, it starts queuing commands and waits until it sees a response to send. So, let's say you type "look" 4 times really fast: it immediately sends the first two, then queues the second two. When it sees a response from the game, it sends the third command. After it sees another response, it sends the fourth.
All of this is disabled by default, but it makes a big difference when you've got multiple scripts trying to interact with the game (not to mention trying to play at the same time).
Celephais
06-10-2007, 02:58 PM
Okay, so Method 2... I've emulated method 3 in regular movement scripts and it's not 100% reliable, method 2 seems to be the way to go.
And Shaelun's probably dead on about the PsiNet buffering for SF, SF itself still has problems with type ahead.
Shaelun
06-10-2007, 05:16 PM
And Shaelun's probably dead on about the PsiNet buffering for SF, SF itself still has problems with type ahead.
I love open-source software -- don't get me wrong -- but since people write FOSS programs for their own fun, they end up writing in so many miscellaneous features that it's hard to tell what program is doing what in the end...
Celephais
06-10-2007, 05:21 PM
I love open-source software -- don't get me wrong -- but since people write FOSS programs for their own fun, they end up writing in so many miscellaneous features that it's hard to tell what program is doing what in the end...
Psinet isn't FOSS... and it's the same case with closed source freeware... probably moreso, because there is rarely a scrutinized feature list.
Huh... I definatly get typeahead issues in SF but... latency is apparently amazing right now... I was able to get it to properly respond to 20 or so looks at once... um... sending 40 caused the game to boot me :P
ah, it's something with look, because I send 10 movement commands and it responds to the first five and then gave me typeahead messages for the other five. Probably based on how long it takes to processes your command (Look being pretty quick when you have room descriptions disabled)
Deathravin
06-11-2007, 06:27 PM
I don't have Psinet... And I don't have Lich at work. All I have on my work laptop is Stormfront (no lich, no psinet, nada). I played at lunch today and used my script that replaced all 'move's in a script with 'put's from landing to solhaven, and it works fine...
It does about 5-10 puts before it starts moving, and keeps up at a blinding pase until it reaches its destination. I have a rogue guild entry script that goes from the east tower, asks for another training group for Lockpick mastery, and runs back to east tower. I clocked it in about 7 seconds from the time I hit enter to the time it's back in east tower.
At home when I use wizard, it still has sorry you can only type 1 command ahead at a time...
Maybe somebody screwed up with they reactivated my account? I doubt it, because I use my friend's sorcerer and it does the same thing. no error, no issue, nothing. As long as there is no RT or I have to change what i'm doing based on in-game text, all scripts and macros I have in SF have no type ahead.
But at the same time, it isn't going uber fast like it does in Wizard. If I do that in wizard, it scrolls me one huge block of directions, where in SF it does it at about 8 commands a second until it his data incoming, where it slows down to 3-5 a second.
Shaelun
06-12-2007, 05:36 PM
Psinet isn't FOSS...
LOL, I know. It was a general statement :)
Celephais
06-12-2007, 06:30 PM
I tested this morning with SF and typeaheads, it certainly does have typeaheads, it just turns out that the scripts are slow enough under good conditions to let you move quite far. Macros on the other hand cannot handle nearly as much (but are far quicker).
If you've got good conditions doing just Put will work, but I would highly recommend alternating put and move in a SF script... otherwise once it's lagging your scripts will just strand you in the middle of nowhere. I noticed a real difference in the early morning vs the later evening too.
Deathravin
06-12-2007, 07:29 PM
That's interesting.
Maybe I'll just have to put in a provision for slow movement... or just:
.RGwehnENT put
%1% out
%1% s
%1% w
etc.... so I can swap between move and put quickly...
Gammit
06-12-2007, 07:39 PM
What's a good way to look up the EXISTS of an item or critter? Is there a script already written that automates the process? Matter of fact, is there a script that automatically puts the parenthetical number after the critter, as in your example? I'd rather not write it if it already exists.
Celephais
06-12-2007, 08:17 PM
What's a good way to look up the EXISTS of an item or critter? Is there a script already written that automates the process? Matter of fact, is there a script that automatically puts the parenthetical number after the critter, as in your example? I'd rather not write it if it already exists.
No idea in lich (one of these days I will try it just so I can help answer questions) but I know lich supports RegEx and here is an example RegEx you would use:
\<a exist="(?<ExistsKey>[\-,0-9]+)" noun="[A-Z,a-z,-,\u0020]+"\>(?<Name>[A-Z,a-z,\u0020,\,\',\-]+)</a\>
Then, again not sure if Lich supports groups in RegEx, replace the name match with Name + "(" + ExistsKey + ")"
Someone else can fill you on the specifics of how to do that in Lich...
Shaelun
06-13-2007, 05:53 PM
No, nobody's written a script like that to my knowledge.
The details are a little tricky. Well... a lot tricky. Lich will let you get at the raw info, it will let you alter that info, it'll let you re-define its own internal functions (but if you crash it, that's your bug, not mine, LOL), etc.. Provided the script isn't running in a restricted "safe" mode, at least. But if your script requests the raw data, it's going to get the raw data -- it won't be cleaned up, and your script is gonna have to wade through all the junk itself. A single method will toggle un-filtered data being received by your script on and off: toggle_status. Turn it on if you wanna capture stuff, then turn it off when you want the data to be cleaned up again. Just don't forget that once you turn it on, everything your script is matching against and effectively everything it sees is radically altered. You need to compensate for that.
You could just have one script that always monitors the raw data and saves a cleaned-up copy into a global variable, then have a separate script just access that variable... but don't expect it to be quick or easy to set all of this up.
One last thing: I haven't done a whole lot of testing or anything, but as far as I know, you can just straight-up replace the noun with its ID#. "att 3133372" or "look at 37827" or whatever. If you want to map the numbers to objects, I'm pretty sure SF keeps that data in a file somewhere in its directory hierarchy.
Celephais
06-13-2007, 06:05 PM
yes you can directly replace the noun with the exists...
att #3133372 will work (You need the pound sign).
I think all he wants is a script that just parses Raw Data, it doesn't need any of the cleaned up stuff, that RegEx i gave was to match RawData, if you replace the matched value with the matched value plus '(' + <ExistsKey> + ')', that would be all you would need to do, I just don't know the Lich syntax for RegEx replacement and RegEx group value extraction.
Shaelun
06-15-2007, 08:32 PM
Well the problem is that I think Lich tosses out the extra XML info, including that number. It could be in the $npcs variable, if you wanna peek at the value in there (echo $npcs.inspect).
When I wrote all the SF stuff, to make life way easier (and avoid new bugs) I designed the program to immediately extract the info, convert it to the same format it would have been in if sent to the Wizard, and then store the value as it would have with Wizard. So to get that ID, you'd have to write an entire script to monitor and continually-update the data... which is really tedious, and a little bit more complicated than standard Wizard-ish scripts. By all means though, have at it if anybody wants to -- I still think that's the best way to learn.
At any rate, you've got the syntax right'n all Celephais. I had totally forgotten about the pound sign too; not gonna get too far without that :)
Gammit
06-21-2007, 06:27 PM
What modifies $npcs? Infomonitor, I suppose? All I get is an empty array when I echo it, whether or not there are npcs present, but infomonitor has also had no luck whatsoever monitoring my spell status, so it seems it's not getting the information it's expecting to get.
Gammit
06-21-2007, 06:38 PM
Nevermind, none of the default scripts reference the variable, so I suppose the Lich is supposed to do it itself? Either way, $npcs stays empty for me.
Shaelun
06-21-2007, 09:07 PM
It's really hard to provide a good "rule of thumb," for what the "core" Lich program does and what the "plugin-esque" script infomonitor does. If the info is contained in a status tag that the game sends to keep the front-end displays updated, the core engine snags it. Everything else is handled by "infomonitor" or some other script.
In this case, the core engine does it. And if it stays empty, it's a bug. If you aren't using the latest version, update and see if it still happens. To have any clue what's wrong, I'd also need to know whether you play with SF or Wizard, and ideally a log of Lich's "echo.lic" script outputting raw data while something is standing in front of you. I really just don't have much time to play anymore, and both the NPC tracking and spell tracking work flawlessly for me. To fix it for your environment, I need a lot more info than that.
The "default" scripts reference the variable through the "checknpcs" command. I know this sounds really snippy, and I apologize for that, but I'm not sure what else to say: read the source -- the only thing most of those commands do is access the appropriate memory addresses and clean up the data Lich stores as it monitors the datastream.
Gammit
06-22-2007, 03:00 PM
Sorry, I neglected to mention the client I used because I guessed you'd remember from my other question. I use StormFront, so all bets are off. Time for me to dig into the source, then.
Gammit
06-22-2007, 03:07 PM
And now that I've played around with Lich's included echo script, Celephais's response makes a lot more sense. That should be pretty easy to implement.
Shaelun
06-24-2007, 03:43 AM
By the by, that empty array in $npcs was indeed a bug. One that's probably several months old, for that matter. Fixed it for the next release (thanks to Divid's testing).
If it'd be helpful for your purposes, don't forget that you can save a log of the raw datastream by typing ;log in-game. I'm not sure what you and Celephais have in mind, but I still can't see how what you want could be "pretty easy." Oh well; whatever the case, good luck with it.
Gammit
06-25-2007, 01:54 AM
With echoes, it'd be easy, but you're right, it's not exactly what we were asking for.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.