Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

More efficient code?

Status
Not open for further replies.

Dragget

Technical User
Jul 29, 2006
3
US
I wrote the following short script to help me in an online game. It is designed to wait for a specific message and harvest a letter (A, B, or C) from that message, then use that to send a response at the proper time. For example: it will wait for the game server to send "Hit in range "A"" and then wait for the a series of As to send a space character. i.e.:
.........BBBBB........CCCCC......A <--- Now it should send the space character. I've posted the script below. The issue I'm having is that, while it works, it's kind of sluggish, and even though the server text is displayed at a reasonably slow rate, the script often is not able to respond until 3 or even 4 of the appropriate letters have been dispayed. Does anyone have any suggestions for speeding this script up? Is there anything I can change to make it more efficient?
Code:
;Operation Overkill II Autofight script         

string HitLtr

proc main
while $CARRIER == 1
 waitfor "Hit range in `"" FOREVER
 rget HitLtr 1
 call Strike
endwhile
endproc
;
proc Strike
switch HitLtr
 case "A"
   waitfor "A"
   endcase
 case "B"
   waitfor "B"
   endcase
 case "C"
   waitfor "C"
   endcase
endswitch
transmit " "
endproc
 
If I'm understanding you right, then I think you might want to add the FOREVER flag to the waitfor commands in your Strike proc. Otherwise, it is possible that the waitfor command would time out before the character the waitfor is looking for arrives. When it fails for you, does the "Hit range in" string appear again before it works "right"?

 
Good point, Knob. I did end up adding the FOREVER parameter to those waitfor commands, and it improved the script somewhat. The reason I wrote it in the first place was because network lag was intermittently occuring, making it difficult for me to judge the pacing accurately when playing without the script.
with the FOREVER paramater added to the remainder of the waitfor commands, I can leave the script running throughout my session and it works...more or less. Still though, it reacts too slow about 10% of the time, which is not much better than what I'm able to manage with my merely human reflexes, and I was amazed that it would be this sluggish.
 
The only other change I can see making is removing the call to the Strike procedure and just moving that code into main, but that shouldn't really make a difference. Can you post your current script?

 
OK, here it is with the "Strike" routine rolled into the main process.
Code:
string HitLtr

proc main
while $CARRIER == 1
 waitfor "Hit range in `"" FOREVER
 rget HitLtr 1
 switch HitLtr
  case "A"
   waitfor "A" FOREVER
   endcase
  case "B"
   waitfor "B" FOREVER
   endcase
  case "C"
   waitfor "C" FOREVER
   endcase
 endswitch
 transmit " "
endwhile
endproc

You're right... that doesn't seem to speed it up any. it's still rather sluggish.
 
Once the "Hit range in" message comes across, is the only thing that is sent afterwards A B and/or C until the script sends the space bar and the next "Hit range in" message appears?

You might also use Procomm's monitor window to make sure nothing else is coming across except the A, B, and C characters that might be throwing a wrench into the works. Here is some information copied from my site that shows how to use it:

Procomm's Monitor Window can be used to view the incoming and outgoing data, in both hex and ASCII format. To activate this window, select the Data | Monitor Window menu item. Resize the Monitor Window so that you can view the entire width of the window, then click back in the Procomm Plus window so that the Monitor Window does not have focus. Incoming text is displayed in red, while text you send is colored blue. The Monitor Window can be handy for viewing incoming escape sequences (to determine if Procomm Plus is responding properly to them) or to verify that the program is sending the data you think it should be.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top