By the way, the 1070 might be nice, but the Sapphire RX470/480 8 gig... is super nice also. For a lot cheaper.

You should see the Vulkan drivers go. I have no idea how support is working for Linux, because I'm not interested, but the new Vulkan drivers... omg. The load balancing on a multi core cpu is amazing.

Quote from: BobOzarius on April 03, 2017, 07:48:37 AM

Now if only you'd stop buying Nvidia video cards...    The newer AMD cards are catching up in performance fairly quickly.

I'm a big Linux user.  So ATI/AMD drivers for that have always been a trainwreck IMHO.  After a few experiences with Linux support and ATI, I decided that they'd never get any more of my hard-earned money. 

Now if only you'd stop buying Nvidia video cards...    The newer AMD cards are catching up in performance fairly quickly.

     It's bad practice to have a repeat without an until. Also, your wait timers don't allow for any error at all. So your character would be walking all over the place. To every corpse. What if the corpse was 9 tiles away? Is 2 seconds enough time while walking? Maybe. What if you lag? Having that wait 10 after the event macro 17 isn't very efficient either. It's a better idea to set a wait timer, over what it would normally take for a corpse to open, and detect if the #contid has changed. Because no 2 corpse container ids will be alike. Then on error, you can break out of that loop while you wait. What if the corpse doesn't open for some reason? Then you wait that 10, and continue through the code like an error never occurred. Which it did... That's not a good idea. You should look at mine for a better idea of how to do it. I actually put in a return for a corpse cont error so it will not continue to execute code if the container doesn't open. That also will fix missing corpses, because it won't ignore that corpse if it errors and it will reloot that corpse again. It's just more logical.

     Plus #findkind is oldschool.    #findcnt is better.  That's a very basic wait to handle cutting corpses. Now that I wrote all that, I'll write corpse cutting into mine to show you. Another issue you have, is you are doing a finditem every loop for tools, when that isn't needed. It's fine, just slows things down needlessly, when you start writing larger scripts that will matter. And this code should now account for all timings from actions performed in the script itself, so outside of this code, no timing should be needed to use it. It's all taken care of in the looting code itself. You could probly just do a gosub loot and put that code into that, with the variables at the top of the script and it would work fine.

You also probly need to account for the timing of instanced corpses, which this does not do. You'd have to loot it once at the beginning, and then again after a couple minutes when the other corpses become un-instanced. (Is that a word?)  Or if you're finding corpses nonstop, instead of looting it twice, find the corpse, set it to an instanced timer, then loot it just once when it combines the instances. But if you're competing with others, probly better to just loot it twice. So you get your items at least. That %contWait timer probly needs some tweaking also. It looks like it would work correctly, but I'm not sure. It seems to wait as long as it takes for a corpse to open, plus 100ms. But is that too long? After opening a corpse with event macro 17, you have to wait at least 1000ms on OSI to perform another action. That's something to consider. That's why I made the timer 1100. But what if the container opens in 500 ms, you'd have a spare 500 ms you'd have to wait before performing an action, so you'd have to account for that somewhere.

  http://www.freeformatter.com/regex-tester.html

#findcnt > 0 is the standard way of doing things. It's the way recommended by Cheffe also. You'll always have a problem if someone picks up an item after you do a finditem to see if it's there, but you should never rely on a finditem after a second anyways. The longer you wait between a finditem the more chance you have of an item disappearing or being picked up. That just makes sense... why would you wait that amount of time without doing another finditem? I'm well aware of all the ways that finditem can be used, and I've never had a problem with #findcnt > 0. Not ever. What you said above doesn't really make sense. You're saying if you do a finditem, then ignore an item, it will still be found? That's not logical. If a corpse disappears, and you do a finditem for it... it can't be found either... so that makes zero sense also.  Maybe you're not 100% certain of it's use, I can give you some example code if you'd like. If you do a finditem, and someone picks up an item while you're iterating through the #findindex, of course it will show as being found, but how often does that ever happen? Once in 10000000000 times? I'm trying to understand your point, but you're losing me.

for #findindex 1 50