ScriptUO
Official ScriptUO EasyUO Scripts => Script Debug => Topic started by: Scrripty on September 11, 2009, 08:39:40 AM
-
I have a question with code example. How much of a difference does a few extra lines of code really make? Like in this example:
menu get specials ;primary
IF #menures = 2 && #mana >= !PrimaryMana
{
gosub execPrimary
RETURN
}
menu get specials ;secondary
IF #menures = 3
{
IF #mana >= !SecondaryMana
{
gosub execSecondary
}
RETURN
}
RETURN
The top part of the sub is done with the if built into the first if... basically just combined, and the bottom one is the "old" way I did it. Would it really make all that much difference in a few thousand lines of code if I went through and changed them to the "new" way? I have a LOT of subs that look like this tho, and I could probly condense a LOT like this... Worth it or no? And why if you would... It cuts that first part of the sub down to 6 lines from 10. If the script is processing 10 lines of code per cycle... that's a pretty big net in speed isn't it? Like 40 percent over the course of a large script, and if you don't have any #lpc optimizing done like me... :)
-
It solely depends on the amount of time and processes that the live compiler has to do to get it done. It could make the process easier and in case make the run less cpu dependant, which inpoint would make the script run faster or could load something up or make it take more steps to finish the process incase offsetting the timing and also making the whole process as a whole alot slower.
-
It solely depends on the amount of time and processes that the live compiler has to do to get it done. It could make the process easier and in case make the run less cpu dependant, which inpoint would make the script run faster or could load something up or make it take more steps to finish the process incase offsetting the timing and also making the whole process as a whole alot slower.
Well I'm to the point now where I can FEEL I need some speed. If that makes sense. I know I can optimize a TON of script and take out a LOT of lines. I bet I could cut out about 20 percent of my script by just optimizing with what I've learned. I'm just wondering how much I'll ACTUALLY gain. I have #lpc set to 10 in the script. That's VERY low. I could set it to 14 and get the same benefit right? :)
-
Yes and no depends on the processing being done that you are speeding up. Also how it will handle on a dial-up, DSL, Cable connection. Also if it is just processing lines or if its is waiting for actions. This will make a big difference. But the best way to know is to try it out. ;D
-
I'm just trying to prioritize what I ACTUALLY want to do in my head. :) I think I'll just optimize. With my new menu, I can almost visually see each thing processing now when I set how often the menu updates to really low. It's given me some really good insight into how things are getting processed. Plus it's gotten so big, and there's so much being done, I really have to prioritize WHAT gets done first, and do it based on how important it is that each specific thing is done at what time. It's annoying. :) So I'm considering ways to eek out every bit of script and time I can. Optimizing casting is one way. By FORCING the sub to wait for faster cast recovery to be up and not returning out and coming back... I'm saving some time and cycles there. Not making the script endlessly loop through stuff it's just going to sub out of anyways to come back and cast the same thing... when all it would take is a .50 second wait for the fcr to be up and cast the spell... I guess that's more flow optimizing. But if I take out 20 percent of the script, that's 20 percent more it's going to check subs that might need to cast in theory right? :) Sorry just thinking out loud.
-
If you really want to see where your speed is going just put a timer in. Use a simple display to show the current #sCnt, then have it displayed at various points in your script.
I like it in a menu, but you could put it over your head....
loop
if something A
gosub A
if something B
gosub B
until #false
sub A
event ExMsg #charID 3 0 Sub A begin #sCnt
the rest of Sub A
event ExMsg #charID 3 0 Sub A end #sCnt
return
Granted that adds some cycles to the entire process, but it allows you to see exactly how much time is being spent in each part of the script.
-
I'll have to send the newest version to you in your junk mail Cerv. I've got checks upon checks now. It tells you where it's at, what it's doing, low mana checks for everything... I've been using that to diagnose problems. Also my new menu allows you to "see" it visually if you let it update in near real time. It's fun to watch. When I get all the info I want on the new menu, diagnosing suit problems will be so easy. :)
-
Cool, I'll look forward to using it one day, if EUO ever updates LOL.
I like having a "diag" mode in scripts. Turn it on/off at the beginning and allow you to see timings, or other things going on.
-
Cool, I'll look forward to using it one day, if EUO ever updates LOL.
I like having a "diag" mode in scripts. Turn it on/off at the beginning and allow you to see timings, or other things going on.
That's a good idea, I'm not so far along with it, that I can't add a menu option and make it a diagnostic mode. :) if #menures = #true's all over the place with little bits of info on what's going on at that exact moment? I like it. I'll add that to the "SHOULD HAVE BEEN DONE YESTERDAY" list. :)
-
This all sounds good Twinkle McNugget and i like you thought process. I want to look over some of your diag process to get some ideas for mine :)
-
This all sounds good Twinkle McNugget and i like you thought process. I want to look over some of your diag process to get some ideas for mine :)
If you haven't seen the new menu there's a picture of it here. http://www.scriptuo.com/index.php?topic=2166.msg19670#msg19670 (http://www.scriptuo.com/index.php?topic=2166.msg19670#msg19670)
There's also an old version in that thread somewhere attached to a post. It's got all the old casting errors tho that I've since fixed. Well I'm actually still working on them, but they've pretty much got a fork stuck in them cause they're DONE. :)
-
setinng LPC 100 would effectively be a 10x increase in speed. Dont be affraid to set the LPC higher in certain sections of your code .. just as fast journal scanning.. set LPC 1000 and then set back down after journal scan is done.
In my buffbar scanner (pixel scanning) the LPC is defaulty set to 9999 (bascially max)
As far as you code... Less lines is easier to read thus debug and the newer method needs less {} so thats better... But might I also suggest that you start thinknig about only useing one Return Per sub.. makes code much more resilient in the long run. Eg like below
menu get specials ;primary Or Secondary
set !MenuRes #MenuRes
IF !menures = 2 && #mana >= !PrimaryMana
gosub execPrimary
IF !menures = 3 && #mana >= !SecondaryMana
gosub execSecondary
RETURN
Note: Less that 1/2 the lines used as your original code and i find much easier to read.
-
Yea I know about #lpc, but why does one return make code more resilient? Oh I think I get it... it's just less lines... and less jumping around... more compact and such? :) I have SO much jumping around tho... I should throw my ls sub up so you can see THAT monster. haha I did it. :) I can cut a TON out of that...
;==========================Lightning Strike==================================
sub ls
menu get 13 ;Lightning Strike;Primary:Secondary
IF #menures = #true
{
menu get 14 ; WS Mana Check
IF #menures = #true
{
menu get specials ;ls
IF #menures = 1 && #mana > !LSManaPercentage
{
gosub lsSpecial
RETURN
}
menu get specials ;primary
IF #menures = 2 && #mana >= !PrimaryMana
{
gosub execPrimary
RETURN
}
menu get specials ;secondary
IF #menures = 3
{
IF #mana >= !SecondaryMana
{
gosub execSecondary
}
RETURN
}
RETURN
}
menu get 25 ;Curse Wep
IF #menures = #true && !CRWTimer < #sysTime
gosub CurseWeapon
menu get specials ;ls
IF #menures = 1
{
gosub lsSpecial
RETURN
}
menu get specials ;primary
IF #menures = 2
{
IF #mana >= !PrimaryMana
{
gosub execPrimary
}
RETURN
}
menu get specials ;secondary
IF #menures = 3
{
IF #mana >= !SecondaryMana
{
gosub execSecondary
}
RETURN
}
}
RETURN
;============================================================================
-
I have to agree with EN with the lots-o-returns. This section:
menu get specials ;ls
IF #menures = 1 && #mana > !LSManaPercentage
{
gosub lsSpecial
RETURN
}
menu get specials ;primary
IF #menures = 2 && #mana >= !PrimaryMana
{
gosub execPrimary
RETURN
}
menu get specials ;secondary
IF #menures = 3
{
IF #mana >= !SecondaryMana
{
gosub execSecondary
}
RETURN
}
RETURN
Can be trimmed to:
menu get specials ;ls
IF #menures = 1 && #mana > !LSManaPercentage
gosub lsSpecial
menu get specials ;primary
IF #menures = 2 && #mana >= !PrimaryMana
gosub execPrimary
menu get specials ;secondary
IF #menures = 3 && #mana >= !SecondaryMana
gosub execSecondary
RETURN
That seems just more readable to me and doesn't change execution flow too much.
-
I have to agree with EN with the lots-o-returns. This section:
That seems just more readable to me and doesn't change execution flow too much.
While you were posting that I did this:
Basically cut that sub in half. Sped it up by double then... Should net me a tiny bit of speed when toggling specials... Thanks guys, I'm gonna keep looking. Remember this is my FIRST full fledged script I've EVER done. I've done TONS of little things, a few hundred lines... but this is huge to me. :) I'm at 3000 lines and counting now. Lots of documentation tho. That's what I was saying I could probly cut the script by AT LEAST 20 percent, and if that sub is any indication I could probly go 40 to 50. :)
;==========================Lightning Strike==================================
sub ls
menu get 13 ;Lightning Strike;Primary:Secondary
IF #menures = #true
{
menu get 14 ; WS Mana Check
IF #menures = #true
{
menu get specials ;ls
IF #menures = 1 && #mana > !LSManaPercentage
gosub lsSpecial
menu get specials ;primary
IF #menures = 2 && #mana >= !PrimaryMana
gosub execPrimary
menu get specials ;secondary
IF #menures = 3 && #mana >= !SecondaryMana
gosub execSecondary
RETURN
}
menu get specials ;ls
IF #menures = 1
gosub lsSpecial
menu get specials ;primary
IF #menures = 2 && #mana >= !PrimaryMana
gosub execPrimary
menu get specials ;secondary
IF #menures = 3 && #mana >= !SecondaryMana
gosub execSecondary
}
RETURN
;============================================================================
-
I'm always making tweaks to my scripts as well. You're never too good to try and streamline things. It'll definitely will make it faster since each line takes a set amount of time to execute. So less lines = faster code. Also you'll start noticing that code executes faster toward the end of a script. That's why most of my iterative functions are at the end. Good example of this is the CLAw. Surprising find there....
-
Actually this little edit will net me more than a little speed increase... that LS sub gets called ALL the time in my script. I'm talking almost CONSTANTLY. After anything happens, that sub needs to set the specials active so that should net me more than a little speed... just the SUB is sped up by 50 percent by cutting the lines in half theoretically... so how much would that affect the script as a whole since that sub is called CONSTANTLY? :) Wow, that little edit is huge. Thanks guys.
-
Even more reason to always look at the structure of your code. Especially code that's found in the tightest loops.
-
Even more reason to always look at the structure of your code. Especially code that's found in the tightest loops.
That makes a ton of sense. Why I didn't think of that when I STARTED I have no idea. I'm not liking learning scripting as much as I'd thought, because I *HATE* doing things twice. haha Do you know how many times I've redone and redone that LS sub? It took me AGES to get it where it was, and then to actually make it WORK how I'd envisioned, and now I'm cutting half of it out. Makes me kind of sad... haha
-
If you really want to see where your speed is going just put a timer in. Use a simple display to show the current #sCnt, then have it displayed at various points in your script.
That's not a bad idea. I could use #sysTime and set it at the beginning and end of a sub and get the ACTUAL time it takes in seconds and fractions of a second to complete a sub and REALLY give me some timing info... :) I could work on the worst subs to gain some extra speed. Good idea. I could do that for the casting subs, and see EXACTLY how long each sub takes to cast each spell, and maybe do that over a period of time for each spell and put that info on the menu. Time spent casting EOO per min/hour. :) I fixed your bandages not firing issue too. I hadn't even looked at it in ages. I don't know why Event macro 58 wasn't working... but it's fixed now.
-
But next script or even next sub you write .. imagine how how efficeint its going to be from the get go. you wont need half the edits as you will just write it better the first time around.
And ps your doing fantastic for a first script and people are using it .. what more can you ask..
-
But next script or even next sub you write .. imagine how how efficeint its going to be from the get go. you wont need half the edits as you will just write it better the first time around.
And ps your doing fantastic for a first script and people are using it .. what more can you ask..
Well first "big" script. I've written a TON over the years, but just basic stuff, and never really gotten into doing a big project. I've learned so much about pvm... I think I'll be the board expert. :) The version posted in the Project E thread is OLD. I need to update it. Although I need to have a hit and runner REMOVED before I do. That's why I'm not updating it. I'll pm TrailMyx about it so I can update and let you guys look at it again.