Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - lydaan

Pages: [1]
1
I, like probably many, was very confused and intimidated by NameSpace management for a long time. I recently started managing sub-variable integrity manually, and the relevance of namespaces finally became clear.

Instead of passing variables %0-%n to a static %sub_variable, and then deleting them at the exit of the sub, EUO already has tools to manage this for you. By declaring a local namespace for the sub and clearing it and recalling the previous namespace, all that legwork is handled for you (for the majority of scenarios).

My question has to do with push/pop and I'm looking for confirmation or correction on what I understand to be limitations. I am not an expert, but I believe I have the logic of namespace worked out.

Quote
*FYI*: For the context of this thread I will assume that any Sub will populate a sub-local namespace, and as such I will purposefully conflate "namespace," with "sub." I want to frame namespace management in the context of sub-local variable management so that namespaces novices like myself can more easily interpret a namespace use case.

This will likely be most people's first experience/need for NameSpace Management. The NameSpace function has more usages than sub-variable management, but grasping this specific usage will translate to understanding when other uses are necessary.

*Properly defining "many," without making assumptions (every sub will populate a sub-local namespace) quickly degrades into a recursive argument nightmare.

For those unfamiliar with NameSpace Push and Pop:
;---------------------------------------------------------------
NameSpace Push saves the current namespace as a temporary variable. Probably something like (pseudo-code) #pushed_nsname|type. All of a namespace's defined child !variables are stored within their parent namespace address, regardless of whether it was "pushed," or not.

NameSpace Pop sets the name space to the LAST "pushed," namespace AND can only be called once per push/pop (EUO seems to clear #pushed_nsname|type when pop is called).

If NameSpace Push is called multiple times before the cursor parses a NameSpace Pop, EUO will overwrite #pushed_nsname|type every time, destroying NameSpace Pop integrity.

As long as a sub maintains a 1:1 relationship, as in the called sub will only be called directly and does not call other subs, Push/Pop works fine.

Example of 1:1:
Code: easyuo
  1. ;current namespace = default namespace = local std
  2. body:
  3. ...
  4. gosub one_to_one
  5. ...
  6. goto body
  7.  
  8. sub one_to_one ;Sub One_To_One will only ever be called directly and never calls other subs.
  9.    namespace push ;Saves the current (local std) namespace, including
  10.                   ;   any defined !variables for recall with pop.
  11.    namespace local one_to_one ;Changes the current (local std) namespace to "local one_to_one."
  12.    ;Sub One_To_One Body.
  13.    ;Do Sub One_To_One things setting local !variables and referencing local !variables
  14.    ;   as well as setting script %variables to be passed to the script,
  15.    ;   and referencing script %variables previously defined.
  16.    ...
  17.    namespace clear ;Deletes all !variables for the current (local one_to_one) namespace.
  18.    namespace pop ;Changes the current (local one_to_one) namespace
  19.                  ;   back to the last_pushed (local std) namespace
  20.                  ;   and restores the stored !variables for it.
  21. return

But as soon as any directly called sub calls an/other sub(s), or a sub can be called directly and/or by an/other sub(s), or both/all (1:many || many:1 || many:many), push/pop integrity breaks down, and namespace integrity must be maintained manually. Luckily EUO also has #system_variables to handle this: #nsname and #nstype.
   *Note: There is more nuance to defining "many," but in the context of this thread,
              where I assume that all subs will populate a sub-local namespace,
              it is safe to assume my definitions above are correct.

My solution for this conundrum, for when I develop a new subroutine, is to assume that all subs will populate a sub-local namespace and have a many:many call relationship and manually store and delete #nsname and #nstype, and edit this out if I want to. Conversely I could assume this is not the case and add this in after the fact, but that doesn't change the solution.

Example solution for all relationship states (1:1 || 1:many || many:1 || many:many):
Code: easyuo
  1. sub many_to_many
  2.    set %many_to_many_nsname #nsname ;store the current #nsname and #nsntype
  3.    set %many_to_many_nstype #nstype ;before populating another namespace
  4.    namespace local many_to_many ;or whatever the sub is named
  5.    ;Do sub many_to_many things
  6.    ...
  7.    namespace clear
  8.    namespace %many_to_many_nstype %many_to_many_nsname
  9.    deletevar %many_to_many_nsname
  10.    deletevar %many_to_many_nstype
  11. return

This solution works the same as push/pop, except with several advantages:
   1. You don't have to know the final state of a sub's namespace relationship (n:n).
   2. It frees up push/pop for specified use elsewhere in your script/subs, if you prefer.
   3. You may ignore the current state of push/pop in publicly published subs.
   4. Each current namespace is permanently stored until all calls are returned.

The only disadvantage I can think of is that it costs 3 more lines/parse processes per potential push/pop, but that is immediately nullified when a potential push/pop push is overwritten.

Back to my original question, am I over-thinking this or is this a relevant solution?
In simpler terms, "Am I doing this right?" Or is there a better way?

Thanks for your time.

2
I was discussing some things about finditem with Gaderian in another thread and thought I'd move the discussion to it's own thread.

Original thread where the conversation started:
http://www.scriptuo.com/index.php?action=post2;start=0;board=30

Quote
last post from Gaderian for some context
Quote
I use the 'for #findindex 1 #findcnt' all the time, but it doesn't work in the example I showed above, because #findcnt gets reset with each 'finditem' statement (when looking for the tools), and I had to keep track of how far through the list I was.

The ignoreitem method doesn't work when trying to see if I have enough tinker tools to craft more tinker tools to fill the bod; additionally this won't work when the item stacks.

Also when you issue the 'finditem TYPE Index location' method, #findcnt returns 1 each time because you said you wanted to search for only 1. (I expected it to give me back the same #FindCnt value as if I had looked for the whole list, but that was incorrect.)

So using a number value for the Index into the list behaves very differently from the other methods.

In another thread here, TrailMyx states that everyone gets the items back in the same order (suppose you stand in range of the same NPC's with me, we both get the same order of NPC's). I haven't tried to prove or disprove that, but take his word for it. It makes sense because the Index parameter allows subsequent execution of the 'finditem TYPE LOCATION' to actually iterate through the list. If this return was variable on each call, then the Index parameter would not really work.

Interesting nuances in the language that we can take advantage of in scripts...

;--------------------------------------------------------

Few things here. A big one is that you're conflating EUO system functions(finditem) and #return variables with script-local user-defined functions and variables. You can define just about anything you can think of, function or variable, as long as you define it and address it correctly for your intended use.

For those who may be unfamiliar, finditem is an EUO system function. When you call finditem, it returns an array of data that you may reference until you call finditem again. For each subsequent finditem call, EUO will delete all previously held data at each memory/array address, and then populate a new array.

Quote
... #findcnt gets reset with each 'finditem' [call] ... and I had to keep track of [a previous finditem_return index position] ...

Correct. This is why, if you need to reference the data again, after future finditem calls, or the worst case scenario, against THE NEXT or LAST finditem call, the best/only (if next or last) practice is to store the relevant data in a user-defined array for later reference. This can easily be done in EUO by using the append concatenator . (#dot).

In this particular case you may be able to get away with just doing a finditem call and then just using the first thing found before calling finditem again, but if you're wanting to reference values like #findiindex or #findcnt against the current data set, you will need to store all relevant data points in a referenceable manner if your flow requires another finditem call before that data is irrelevant. You're already doing half of this. Just take one more step and you've solved it.

If what TM was saying is correct (I would assume it is) then #findindex is more descriptive than I had previously assumed, but only when a finditem is called using the exact search_for parameter in the exact #charpos and/or container (and probably expecting the searched items having not been moved between searches, as it's likely a server propagation hierarchy). Only in that one special case could you consider #findindex to be descriptive for anything other than defining a position in the current finditem_result array.

#findindex holds no special relevance outside of the fact that for every #findindex = n, when and only when used in conjunction with any #findresult, it points to a specific position in the current finditem_return (and the extremely rare usage above).

#findcnt also holds no relevant information outside of the amount of indices that were returned when finditem was last called making it easier to parse the array. it's just a count-value that is system function defined, and cannot be defined with set.

Example of #findindex irrelevance:
Code: [Select]
for #findindex 1 5
   set %test . #findindex test . #findindex
;will produce identical results as
for %i 1 5
   set %test . %i test.%i
;both will produce a 1x5 array of %test1-5 = test1-5
You can easily test this by opening a fresh EUO tab, with no previous finditem calls, and running this:
Code: [Select]
for #findindex 1 5
   set %test . #findindex test . #findindex
for %i 1 5
   display %test . %i
halt

now #findindex relevance and #findcnt ir/relevance. This is a usable test/example:
Code: [Select]
finditem * c_ , #charid
for #findindex 1 #findcnt
   display Item #findid found at Index Position #findindex ,
        + ,$in the current finditem_result array$that has a total of
        + #findcnt unique indices.
;will produce identical results as
set %just_a_count #findcnt
for %i 1 %just_a_count
{
   set #findindex %i
   display Item #findid found at Index Position %i ,
        + ,$in the current finditem_result array$that has a total of
        + %just_a_count unique indices.
}
;this previous example also shows why we should be thankful we can shove #findindex in a for() call as parameter 1
;and finally, same with this one, and also why we should all be thankful for #findcnt as well as
;being able to shove it into the upper-bound parameter of our for() calls
;this also sets up a user-defined array, so you can reference the
;current finditem_results array permanently.
for %i 1 1000000
{
   set #findindex %i
   if #findid <> yc
      set %just_a_moniker . %i #findid
   if #findid = yc 2
      set %literally_just_a_count %i - 1
      set %i 1000000
}
set %from_1_to 1
for %any_old_numer %from_1_to %literally_just_a_count
   display Item %just_a_moniker . %any_old_numer found at Index Position %any_old_numer
        + ,$in the current finditem_result array$that has a total of
        + %literally_just_a_count unique indices.
halt

So when I:
Code: [Select]
finditem %sbod_types c_ , #backpackid
set %sbod_cnt #findcnt
for #findindex 1 %sbod_cnt
  ​set %sbodid . #findindex #findid
I create a user-defined 1xN array (IDxIndex|Indices) indexed to the data found in the finditem_result array that is permanently referenceable within the script until I manually delete it, overwrite it, or stop the script.

The sbodID array:
Code: [Select]
%sbodid1 = ;a unique #ObjectID found at index position 1 of the the previous finditem_sbods_results array
%sbodid2 = ;a unique #ObjectID found at index position 2 of the the previous finditem_sbods_results array
...
%sbodid . %sbod_cnt = ;a unique #ObjectID found at index position #findcnt of the the previous finditem_sbods_results array

A reference and pseudo-use-case for each index:
Code: [Select]
for %i 1 %sbod_cnt ;note, you could use %sbod_index in place of %i if that helps you,
{                  ;but what you name the counter is entirely irrelevant.
                   ;only the current count is relevant.
                   ;the second parameter 1, will always start the count at 1
                   ;and will continue to perform all actions below for each %sbodid . %i
                   ;until it has completed all actions below for %sbod . %sbod_cnt

   event property %sbodid . %i
   ;do sbod things
   ...
}

As a sort of aside, but on topic to the previous example use case, it would be best practice to delete all previous entries freeing the designated memory addresses, just the same as EOU does when you call finditem. The biggest concern is not really the memory usage (although that should always be a concern, even when it is minimal), but rather that the sbod count might be variable if/when you're calling this user-defined function/sub multiple times in the same script.

My recommended example:
Code: [Select]
;check for if %sbod_cnt is defined = #true. This will only pass after the first time through.
;alternatively you could use if %sbod_cnt > 0 if for some weird reason
;you are defining it in parallel somewhere else in the script.

if %sbod_cnt <> n/a 2
   for %i 1 %sbod_cnt
      deletevar %sbodid . %i
;someone will probably comment about deletevar. "set %variable  " does not delete the address. only the value.

;you don't need to delete %sbod_cnt as it will be overwritten before it is referenced again.
finditem %sbod_types c_ , #backpackid
set %sbod_cnt #findcnt
for #findindex 1 %sbod_cnt
  ​set %sbodid . #findindex #findid

I hope this helped to simplify arrays.

Quote
The ignoreitem method doesn't work when trying to see if I have enough tinker tools to craft more tinker tools to fill the bod

This is literally one of it's usages. you just have to ignoreitem by ID. But this doesn't solve the issue of crafting another tinker tool before this one runs out. But that's a conversation for another thread.

Test code:
Code: [Select]
;clear your backpack of Tinkering Tool Kits.
;put one in your backpack then press play:
finditem %tinkerToolTypes c_ , #backpackid
ignoreitem #findid
set %ignoredTool #findid ;set this so you can clean up the ignoreitem command later
pause

;now put as many tinker tools as you like in your backpack and press play again
finditem %tinkerToolTypes c_ , #backpackid
for #findindex 1 #findcnt
{
   if %ignoreditem = #findid 3
      set %ignoreitem = #false
      display Welp, ignoreitem doesn't work :(
      halt
}
if %ignoreitem <> #false
   display finditem found #findcnt Tinkering Tool Kits, but did not find the one that was ignored.
pause

;now if you still don't think it works we'll un-ignore that ID
ignore item %ignoreitem
finditem %tinkerToolTypes c_ , #backpackid
display finditem now found #findcnt Tinker Tool Kits in your backpack!
halt

there are other ways to do this as well, but this is the simplest. not necessarily the best option, but it is simple.

Quote
additionally this won't work when the item stacks

i don't know what else would be important to ignore except the items you normally keep in your backpack and a tinkerer's tool so you can craft more tinkerer's tools when needed. could you provide an example?

Quote
finditem TYPE Index location

I am unsure of what exactly you are expressing here. If this is still relevant, please post an example.


3
Scripting Chat / OSI tester Needed. Mining with Fire Beetle. ~5 minutes.
« on: September 17, 2021, 06:47:20 PM »
I was wondering if someone with an OSI account with a miner and a fire beetle could try a little bit of test code for me? I was sort of asking about this a few years ago when I was working on my miner for my FS, and I am still curious. The whole test will take roughly 5 minutes if you have a miner and fire beetle ready to go. Let me know if there are any issues with script execution.

Test code:
Code: [Select]
;just copy this code, grab a shovel and your fire beetle
;and head to the nearest cave.
;hit the dirt once, and if you pull up some ore, press play
set #lpc 100
set %oretypes TVJ_EWJ_DWJ_GWJ

finditem OHP * g
set %fireBeetleID #findid

set %shovel #lobjectid
set %mtile #ltargettile
set %mkind #ltargetkind
set %mx #ltargetx
set %my #ltargety
set %mz #ltargetz

finditem %oretypes * c_ , #backpackid
 if #findcnt > 0 6
   set #lobjectid #findid
   event macro 17
   set #ltargetid %fireBeetleID
   set #ltargetkind 1
   target
   event macro 22

wait 30
   
loop:
   set #lobjectid %shovel
   event macro 17
   set #ltargettile %mtile
   set #ltargetkind %mkind
   set #ltargetx %mx
   set #ltargety %my
   set #ltargetz %mz
   while #targcurs <> 1
      gosub scan journal
   event macro 22
   finditem %oretypes * c_ , #backpackid
   if #findcnt > 0 6
      set #lobjectid #findid
      event macro 17
      set #ltargetid %fireBeetleID
      set #ltargetkind 1
      while #targcurs <> 1
         gosub scanjournal
      event macro 22
   repeat
      gosub scanjournal
      finditem %oretypes * c_ , #backpackid
   until #findcnt > 0 || you_loosen in #journal
goto loop

sub scanjournal
   scanjournal #jindex
   if you_must in #journal 2
      display Test failed! you cannot dig>smelt>dig>smelt>... on OSI
      halt
   if there_is_no in #journal 2
      display Success! you can dig>smelt>dig>smelt>... on OSI
      halt
return

4
Script Snippets / Lydaan's Snippets
« on: March 04, 2016, 05:42:46 AM »
My first snippet! :D Everyone's favorite, Event Property!

After much much reading and many hours working with event property, I finally came up with a way to evaluate event property to make sure that it is current for the item in question. Enjoy, and criticize freely! This should only stall if you use it incorrectly.

Works fine as a stand-alone sub, and updated it to handle single line as well as multi-line properties.

*edit: stripped this down to it's smallest form. it will hang if called with an invalid [Parameter_1] or if you die, etc. If you need help with adapting the wait conditions, let me know.

Description and parameters:
Code: [Select]
;=======================================================
;       -=| Lydaan's GetProperty Sub |=-
; --- For when event property is your only option ---
;     Ensures #property is current for the item
;     in question while taking the minimal amount
;     of time. No extra wait needed.
;-------------------------------------------------------
; %1 = id of item to get property of, must not be null
;=======================================================
Examples calls:
Code: [Select]
...
goSub getProperty %thisThing
finditem %theseThings * c
for #findindex 1 #findcnt
{
   goSub getProperty #findID
   ...
}
goSub getProperty ABCDEFG
...

Sub:
Code: [Select]
sub getProperty
   set %gp_lpcReturn #lpc
   set #lpc 100
   event property n/a   ;sets #property = $
   while #property <> $ ;waits for #property = $ before moving on
      wait 
   event property %1
   while #property = $  ;waits for #property to update with the passed [Parameter_1]
      wait
   set #lpc %gp_lpcReturn
return

*edit: shaved a couple lines with repeat instead of while - Changed the name, fixed typos, added examples.

*edit: stripped it down to it's simplest form while still setting #lpc = 100. It also now works for single line as well as multi-line properties.

I will post it again as a semi-standalone with sub conCheck and sub login once I get all the subs worked out for Sub ClientAction.

5
Scripting Chat / BOD/BOB sorter
« on: February 11, 2016, 07:17:47 PM »
I've been chatting with Ghost about BOD/BOB (Bulk Order ___) sorting, and I figured it's time for a thread.

I've got my sorter working the way i want it, but it is too simplistic for what Ghost wants, or OSI requires. I had a lot of fun building my sort switch, and am interested in building a bigger/more complex one for others to use.

Since I know nothing about OSI, I'm going to need some help to set this up. I'd prefer to lay all the cards on the table so I can look at it from the top down and bottom up.

Chatting with Ghost, and reading threads for some of the other BOD sorters, it sounds like the basic needs include:

  • Sorting by color
  • Sorting by reward type
  • Maybe sorting expensive BODs (BODs that cost a lot of resources and give crap rewards)
  • Sorting LBODs into their respective BOBs
  • Support for multiple BOBs for each sort category
  • Sorting filled SBODs into Turn-in/save for LBOD

If I haven't covered anything, or you want additional support, please let me know. At this point, the more complex the better... I'm up for a logic challenge!

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

Update: Untested (at all) BOB Handler

Code: [Select]
;---------------------------------------------------------
;   Name: BOD Sorter and BOB handler
;   Author: Lydaan
;   Tested: Never
;   Purpose: Sort your buttload of BODs
;   Copyright: Feb 11, 2016
;---------------------------------------------------------

includes:

Code: [Select]
; sub BOBhandler
; Counts BODs in books for un/loading
; Handles BOBs to drop BODs from and sort to
; Parameters
;    %1 load or unload
;    %2 Color
;    %3 BOB category ID list (un/filled unsorted, reward category)
;---------------------------------------------------------

I haven't tested this at all, but the logic should work... just need to clean it up.

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

For OSI, do I need to differentiate between 10 & 15 SBODs for rewards? I'm assuming LBOD 10 & 15 rewards are the same, or do I also need to differentiate those?

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

I finally got my ASH +60, so going to let the iron BODs pile up while I play with my new plate suit. This should give me a large enough data set to start working on the sorter.

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

working on BODs again, maybe stuff in 1-2 weeks

6
Scripting Chat / #contblah issues [SOLVED] - PEBKAC
« on: February 03, 2016, 11:17:48 AM »
having a hard time with #contthings... everything was working fine until I realized the "save diskette icon" wasn't working and my last week of edits disappeared.  :'(

In my miner, after crafting a shovel, the crafting gump isn't dissapearing (this issue is due to #lpc stuff that I need to work out), but it seems that when my miner recalls, it pushes the craftgump behind something, and #contthings do not work on it.

Just wondering if anyone knows of a priority of different gumps and which one is currently on top, or had similar issues?

*edit*

Yay learning!

The propblem was 100% PEBCAK

paraphrase:

Code: [Select]
finditem twj * c_ , #backpackid
set %digshov #findid
if #findcnt = 0
   gosub tinkershovel    <--- sets tool kit as #lobjectid
set #lobjectid %digshov <--- %digshov is null, so it defers to the previos #lobjectid
event macro 17 0
...

yay learning! Glad I could share.

7
Scripting Chat / Fire Beetle Math help please
« on: January 08, 2016, 01:32:04 AM »
Been working on my miner. Then I hardcoded the use of a giant beetle in it.... THEN I got 2 firebeetles (for 2 accounts)... going to be a minute before I post my miner, but am hoping someone can help me set up an equation to min/max the use of the fire beetle. I've been smashing my face on my desk for a couple days on this one.

Here's what I know:
minus the occasional ping spike, my miner digs once every second (95% confidence).
I roll humans, and experience 80% or more pulls of 2 ore per dig @ 24 stones
My mules empty are about 60 stones, full 555 stones.
I haven't done the math to figure out exactly how much ingots weigh, but 9/10 stones is close enough, although I believe this to be irrelevant.
Based on an average of 112 readings, smelting on the beetle takes an average of 1.135 seconds (.7min - 2.0max)
Based on a small number of readings, trips to the secure with the firebeetle take roughly 20 seconds.

I currently have my mules set to go home at >405 stones (max-150), this is due mostly to only having my highest skilled miner smelting everything on the fly and the other dropping valorite+ ore in the secure to be smelted by my other miner. But, this is also due to the ever increasing diminishing return on smelting on the fly... which by its nature is always increasing (diminishing) after the first smelt since the bagweight increases.

So... I could try and set-up a growth curve taking into account the weight of the ingots, but I think a rough estimate is good ecough since lag and other outside influences are a factor, and I believe the weight of the ore and the time to smelt/drop are WAY more important.

My gut is telling me that MAXWEIGHT - 200 stones is really where I should be heading to secure, as that is roughly 10digs at ~20 stones per dig...

10digs = 10seconds + 1second for smelting > 1/2 the time to drop at secure (10 seconds)...

I just can't believe that digging once then smelting for a total of ~2 seconds percycle until I reach my %carryweight target to go to secure to be beneficial... that can't be right, can it? So if it's not... what is the target weight to head to secure???

It's been a couple years since I've had to do real math (not accounting), and I feel I'm just missing an important component.

Thanks,

Lydaan

*edit* - its late.. forgot something

The other way i was thinking of doing this was counting smelts. ie go to secure after the 18th or 19th smelt as the total additional time is <= the time to drop...

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

Feel like I'm talking to wall, but sometimes it's helpful to see things laid out in front of you. So this is what I'm going to do.

I'm just going to assume 20secs for a secure drop for the first run, then I'm going to setup a timer for secure drops to take an average of the time it takes. Then I'm going to setup a timer for smelts and sum the time for each smelt, and after the first run, it'll be variable based on an average of how long secure drops take.

something like:

Code: [Select]
if %smeltsum > %avesecdrop - 1000 ;1second....
   gosub securedrop

8
Scripting Chat / LPC for finditem and event property
« on: December 29, 2015, 07:36:32 PM »
As I've been working on my mule script and specifically the endless tinker sub and the dig routine, I find myself becoming very accustomed with the limitations of finditem and event property... specifically the update lag that exists... ESPECIALLY in #property. I know setting LPC really high will not effect the ability of these 2 to process info, but as cheffe eluded, finditem takes about 18.5 lines of the 20 alotted? i think? just due to the length of time to process and the length (in time) of a cycle. Do you think setting LPC to 1 or 2 would give finditem enough time to fully process before the next few lines were read?

As an example, I think I could eat the time by reducing a wait timer, since EUO does nothing during waits, and gives those cycles to the OS, setting LPC to 1 or 2 seems like a better use of that downtime, especially since it's only 1/20 of a second.

Sample current "code:"
Code: [Select]
sub dig
   repeat   
      finditem shovel
      if no shovel
         make shovel
      dig
      wait 6
      scan journal for stuff
      wait 8
   until forever
return

Now with an lpc adjustment:
Code: [Select]
sub dig
   repeate   
      lpc 2
      finditem shovel   ;1
      lpc 10?           ;2
      if no shovel
         make shovel
      dig
      wait 6
      scan journal for stuff
      WAIT 7   ;<--------- reduced by 1
   until forever
return

While I think this might help finditem, and would only really be neccesary in extreme cases, I don't think it would help event property/#property as it feels like that update is server response related, and limited to ping.

I'll probably fart around with this on my endless tinker sub, and think of someways to speed test finditem update...

9
Scripting Chat / Travel... needs a discussion
« on: December 27, 2015, 10:52:22 AM »
I'm sure a lot of you know I'm working on a mule gatherer script, and while I'm working out the kinks on my endless tinker tools sub I thought I'd start a disussion on travel subs. All this is in EUO, but the biggest problems I'm running into are UO related, and should apply to whatever you're using for scripts (unless it has built in spellcast waits and such).

First, let me describe what I believe to be an EUO limitation:
Sometimes the #ltargetid/event macro 22 0 screws up... it just doesn't target. I had a lot of problems with this in TM's travel sub, which was one of the contributing factors for me to try and make my own... At this point I'm convinced that event macro 22 0 just plain sucks, so I have a little bit of gosub travel spam in my script to compensate for when it fails. Don't think I can do much else at this point... whatever... it's fine enough... the fails are few and far between.

Second, and the crux of my issues, is cast recovery:
I've toyed with my journal scanner *a little bit* to no avail. The problem is I keep getting "You have not recovered..." which makes it loop, until it hits my *fix* which returns from the sub when "That location is blocked," is displayed. Not the best fix, but solves the problem for my script, but much slower than what I'd like. I've put event sysmessages (for debugging) just about everywhere I can think of, but have hit a wall, and want to get the other parts of my script working in the meantime, since it "works," anyway. At this point, I think the sub is failing, because of my lack of understanding of Cast Recovery, and all my mules have 0 FCR. I think that other things are making "You have not recovered..." post, making my travel sub loop.

My goal is to have as many things as possible have non-static waits, and I strongly believe that travel is one of them.... I tried #charposx/y before and after travel, but the update seems to be real slow on charpos, as I wasn't able to get that to work at all... so right now, if it hits cast recovery, it loops one time until it returns "That location is blocked."

So, here's my travel sub so far... it's a little dirty, but I think that the meat is there. Oh, and it's only recall right now... just wanted to get this working.

Code: [Select]
recover:
   set %jStart #jIndex
   set %manacheck #mana
   event macro 15 31 ;recall
   target 5s

   event macro 22 0
   set %jEnd #jIndex
   set %closerbx #contposx + 250
   set %closerby #contposy + 130
   if #contsize = 452_236
      click %closerbx %closerby r
   set %journalrange %jend - %jstart
   event sysmessage scanrange = %journalrange
   for %i %jStart %jEnd
   {
      scanjournal %i
    if you_have_not in #journal || More_reagents in #journal
      {
         msg wait, wut?$
         msg omg$
         msg I'm so stupid...$
         wait %recovertime
         goto recover
      }

      if That_location in #journal
      {
         wait 10
         return
      }
}
if %manacheck <= #mana
      goto recover
  wait %recovertime
}
return

Thanks all. Just hoping to start a discussion on travel subs, and what they need to work flawlessly

Lydaan

edit* posted a non working travel sub... fixed

10
Scripting Chat / Mulchine - stripped down gatherer - A learning experiment
« on: December 14, 2015, 11:03:16 AM »
To those of you that read my previous post... sorry... was just excited I got some stuff to work...

Starting this project over with an outline of subs, so I can move from mining to logging once I get tiles worked out.

This is Pre-Alpha of Mulchine: a bare-minimum Mule script.
This isn't a tutorial, as I have not much of an idea of what I'm doing... This is not a walkthrough, as again I have not much idea of what I'm doing... This is a sharing experiment, where hopefully my small breakthroughs will encourage others to attempt DIY projects. So, I'm going to lay this out following some of the guidelines set in Cerveza's tutorials. But first, a little background...

I play on a freeshard. This is my only tangible experience with this game. I currently have several DIY helper scripts for training skills, and combat, and, my favorites, dropping and seperating stuffs in containers.... I will first try to make the script work on my shard, and then edit, if necesary, to make it work on anything else. My free shard allows 3 active accounts with 5 characters each, and afk macroing is "encouraged," so my goal is to have at least 2 accounts gathering, filling or selling something at all times. I'm going to start with mining, and then when I'm satisfied, I WILL tackle tiles and make an LJ mule script to go along with this, then a BoD getter, then a BoD Filler, then a wood stuffs seller, then a blah blah blah... about a year total, hopefully a lot less.

Oh, and I'll be doing this in EUO, because that's what I'm comfortable with, right now.

Achievable script goals (Subject to change) v0.0-v1.0:
Make Mule carry bare minimum requirements to maximize gathering uptime.
Make Mule strip grids to the bone before moving on to next grid.
Count ores AND track rare-ore spawns (my FS has bonus ores/ingots Blaze, Ice, Toxic, Electrum and Platinum)
Do blah blah blah to make it loop endlessly...

Future goals (Subject to change) v1.1-v2.0:
Smelt Ore
Add Defensive Pet, to thwart "Friendly," players from dragging stupid orcs into the stupid cave... What's up, now?  :P
Add Pack Animal to increase gathering uptime... my Packhorse is named Idiot... because... well... he's an...
Add lumberjacking

Unpossible goals(Subject to change) v3.0:
Master tile mapping and hardcode it so the user only has to mark good runes.

So, let's map out some make-believe code to build an outline

Code: [Select]
;---------------------------
;Name: Mulchine
;Author: Lydaan
;Build: v0.0 - v1.0, Ore Mulchine
;What: build what I said, up top...
;Thanks to: going to be using TM's Rune sub, for now. THANKS TM!
;---------------------------

User inputs
-----------
Hard coded inputs
-----------
runes
-----------

Mining Main:
   digroutines
      vein/grid tracker
      rune tracker
      ore counter
  
   shovel routines
      check for shovel
      check for tinker
      check for ingots
      make shovel/tinker get ingots
  
   dropore
      go to secure and drop ore
      go back to the SAME vein/grid

TM's travel sub...

I think that about sums it up for now... I'll add some code in a few hours and edit this when needed. Hope I can live up to what I'm trying to do.

Thanks,

Lydaan

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

So, had a toothache that ended with a root canal about an hour ago keep me away from this for the last couple days. I'll hopefully have all the operations that take place at the secure location up tonight, but in the meantime I thought I'd share something cool.

I call it endless tinker:
Code: [Select]
;--------------------------------------------------------------
;Name: Endless Tinkering Tools Sub
;Author: Lydaan
;HowTo: call this whenever your mule tinkers something
;Notes: Just have iron in your backpack. Enjoy!
;--------------------------------------------------------------
set %tinktypes KTL_JTL_MTL_LTL ;if your tinker tool type is not here, just _add *I think... I'm no expert*

sub endlesstinker
event macro 8 7
finditem %tinktypes * c_ , #backpackid
event property #findid
str mid #property 40 4  ;40 4 for reg, 52 4 for exceptional
set %regtink #strres
str mid #property 52 4
set %exctink #strres
set %checktink : , #spc , 1$
if %checktink = %regtink || %checktink = %exctink
{
   set #lobjectid #findid
   event macro 17 0
   wait 10

   click 80 160
   wait 5
   click 280 170
   wait 2s
   click 80 160 r
}
return

I think that's how I add all tool types?

- Lydaan

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

So here's v1.0 for EUO

It's all manual setup, just follow the examples at the top of the sub. It's stable, but the travel sub hangs sometimes making a restart neccesary. I've run it for about 24 hours on 2 accounts, so about 48 hours of test time, 10 hours consecutive on both with one still running after about 14 hours.

Mulchine has a smelt sub, just make sure you're mule's secure rune is within 2 tiles of your secure and smelter

Note: All the waits are turned way down for speediness... this leads to you not being able to touch anything while it's running. There's also the possibility that you might get a lot of you must wait errors... this can be remedied by finding all the waits and changing them to "wait 20" I'll add controllable wait variables at the top later.

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

v1.1 is running STABLE!!!

I've ran the smelt sub probably 30 times... works well enough right now, tho not exactly what I want

Still recall only... but travel is a whole other issue... might hammer that out tonight, but have already spent about 9 hours on this today.

Most notable attributes of this script:
First, it hauls ass .. err ORE, yeah ORE. I've used variable waits based on contsize to speed things up, and I've only made 1 pair of scissors out of about 10,000 shovels (sitting on stacks of valorite  ;D)

Second, endless tinker sub is now stable enough for mule scripts, and almost stable enough for selling/training scripts... computer crashed the other night while I was working on my lockpick selling script (makes lockpicks as fast as possible), and I haven't opened it yet to see if I saved my endless tinker progress before bed.

Endless tinker is dependant on #property, so you must be playing on a server with age of shadows. This sub stops your mule from using that last tinker use on a shovel and instead makes another tinker tool!  8)

It's still a work in progress, but:
added blackrock stuff, except for the uvf one pointed out by Ghost... that's going in the gem bag for now... what do I need to do? ::) maybe #findcol?  :D or do I have to str check #property?   :'(
added a debugger for possible variable/non-static wait hangs
added an endless tinker tool debugger if that fails (really shouldn't unless your skill is <80.0, then maybe... I have no mules to test with <80.0 )
added an option for stripmining or moving on to the next rune if on the last vein at a rune and close to maxweight
added extensive notes in the header
added user controlable wait variables in the header so you can ratchet it down as tight as your server will allow
AND I've spent about 1/3 to 1/2 my time on trimming the fat off the dig routine... I have 2 journal scans for a worn out shovel and a backup #findcnt=0.... it crafts shovels and gets right back to digging in about 1.5 - 2 seconds
I also haven't gone overweight (hit 553/555 often) in about 3 weeks.

I've been running this nonstop on 3 accounts for about 4 days now... stable, stable, stable...

Things to work on:
Travel... just need to figure out where to put the fcr wait in.... *may* happen tonight
Counter... going to look into dumping to a log, as I don't really want to start in on a menu without these mechanics and other scripts started
Pets/Packy WILL be coming... need to hashout #systime and set up a global variable for pet feeding and smelting and other things... thinking about tying the FCR wait with #systime so I can skip it when my mules do other things long enough

So, again... STABLE AND ABOUT AS FAST AS IT GETS... Do yourself and myself a favor and try this out!


Code: [Select]
;==============================================================================================================================================
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;==============================================================================================================================================
; Script Name: Mulchine
; Author: Lydaan
; Version: 1.1 for EUO 1.5 *** ScriptUO.com Exclusive***
; Revision Date: 12/29/2015
; Purpose: FAST looping mule runebook gatherer. Mines, makes shovels and tinker tools,
;          drops ore at secure, smelts after a few loops... should be autonomous
;
;          Mule carries bare minimum:
;             Runebooks with dig locations (1 stone each)
;             Spellbook or Chivbook (1 stone) (Recall only right now)
;             10 ingots (1 stone)
;             1 shovel (5 stones)
;             1 tinker tool (1 stone)
;          for a rough total of 12-15 stones + charweght
;
; How To: The minimum for the first run (currently):
;            recommended 300+ iron ingots in secure
;            1 tinker tool per mule in secure (1 use remaining should be fine)
;        You can start with ingots and tinker tool in your backpack, if you want
;
; Copyright: 2015/12/17 Lydaan
; *** you may freely use my subs... just give credit where credit is due
;
; Thanks to: CyberPope for his AWESOME Mining Radar... it's the best!
;==============================================================================================================================================
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;==============================================================================================================================================

Plenty of notes in the header, but I thought I'd post MY wait setup... everything is set to default in the dl.

Code: [Select]
;______________________________________________________________________________________________________________________________________________
;______________________________________________________________________________________________________________________________________________
; wait timers:
;    Every wait that may be non-static (server response dependant) *should* or at least *will* be non-static
;    These are variables for all static (actions that cannot be made non-static) waits
;       Adjust at your own risk, but I would assume you can ratchet these down a little to make your server respond faster
;       Wait 14 is the fastest that any action may be performed on my FS without UO posting "You must wait..."
;       *** I run global "wait 14" with 0 problems ***
;    Adjust these up if UO is posting "You must wait..." or it's glitching and you think it's wait related
;    Turn them all to 0 if you like spam/broken scripts
;______________________________________________________________________________________________________________________________________________

set %globalwait 14           ;20 default (1 second). -I use 14- *GENERALLY* the global wait is 1 second *** see header of "wait timers" section

set %digloopglobalwait 14    ;20 default. -I use 14- *** see header and end of "wait timers" section
                             ;This *GLOBAL WAIT* is specific for the action of digging. Co-dependant on %digjournalwait *** see header and end of "wait timers" section
                             ;I've found <20 overloads the client post and increases the (may just be the "perceived") dig rate
                            
set %digjournalwait 6        ;This is the wait for "There is no metal..." "You have worn out..." and other dig related journal posts. *** see header and end of "wait timers" section
                             ;6 works for me, adjust up/down up to a maximum of %digloopglobalwait *** check is scanjournal errors, resulting in mana burn/skipping veins
                             ;Adjust up if you experience excessive mana burn, or you suspect your mule is skipping dig locations
                              
set %genericwait 5           ;Script stall fail-safe. generic wait that's less than the previos action, or neccesary... used minimally so far (twice right now)
                              
set %smeltwait 5             ;20 default. The time between "using" each ore-stack and targeting the smelter *** does not seem to be attached to the global wait on my FS
                             ;*** 5 does not glitch for me (<5 does), but HILARIOUSLY overloads the client post and my mule just stands there waiting for the server to catch up...
                             ;*** I (maybe foolishly) assume this makes it variable/non-static (fastest possible)

Thanks for reading!

- Lydaan

P.S. Do yourself a favor and set the %slowstartup to "skip" after you run it once. Leech catcher... *This Post-Script will self destruct in about a week*


*edit... welp, there seems to be a bug... I'll try to get a solid working v1.1 up tomorrow morning

*edit again... ok, sooo.... the bug is when you set debug to no, the script fails to make shovels...  hmmm, so going to post one WITH debug for those with weird gump sizes, and one WITHOUT debug...

11
New member introductions / Hello Script UO
« on: December 09, 2015, 02:25:18 PM »
Hello Script UO!

My online handle is Lydaan, and I am a gamer. All games... doesn't really matter.

About me:
I'm in my 30's and recently graduated from the University of Arizona with bachelor's degrees in Accounting and Management Information Systems (MIS), and looking for a career. I'm a longtime computer hardware nut, and have built many computers, but am somewhat lacking in the programming/coding department (just experience... have the know how).

I studied music for several years, and consider myself a budding producer (stuff on Soundcloud already, but private... maybe pm me). I play many instruments... All brass instruments (trombone, trumpet, TUBA - HELL YEAH, etc.), many woodwinds (Saxophone, flute, etc.) Drumset as well as stage percussion, and one of my favorites, the harmonica. I've even led a bar band in Seattle for a couple years.

About my gaming:
Minesweeper anyone? haha, not so much anymore, but still hold it dear...
Gamer status started with Doom... then online competition with Age of Empires and Half-Life. lanned Diablo 2 (as well as others) for countless hours. I studied Counter-Strike more than I studied class subjects during my first run at University. I like card games: Poker (my favorite), Star Wars CCG, LOTR CCG, Magic, Hearts, Gin Rummy, etc. ; and pretty much any Board Game.

I Never played UO back when EA was running it, but have recently gotten into it thanks to my friend Iseldorn. We play on Lost City Shard which is an AFK friendly Freeshard. I realize some may look down upon this, and will refrain from posting AFK scripts.

I must say, I'm glad I found this site, as I've been using EasyUO and their forum is somewhat dead (Lots of posts from 2 years ago...), and am really interested in scripting to improve my programming/coding skills.

I've already written a few helper scripts (Netflix afk) in EasyUO, to help with skill gains, and am very much looking to get better at this, and I hope I may be able to contribute at least a fraction of what I've seen available. If anything I can probably help with some of the little headaches that I've run into while writing my own scripts...

Lastly, just wanted to say thanks for the *required* introduction. These sort of things are always enlightening to the self and create a welcoming environment within the Forum.

Hope to chat with you all soon,

Lydaan

Pages: [1]