Author Topic: #FINDCNT incorrect value  (Read 7003 times)

0 Members and 1 Guest are viewing this topic.

Offline The GhostTopic starter

  • Elite
  • *
  • *
  • Posts: 1917
  • Activity:
    0%
  • Reputation Power: 25
  • The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.
  • Respect: +245
  • Referrals: 0
    • View Profile
#FINDCNT incorrect value
« on: November 13, 2016, 05:56:32 AM »
0
I'm having so issue with #FINDCNT that returning the correct value.  99% of the time it return the number of monster find, but at some occasion, I only have one monster and #findCnt see 2 on the side bar.   This happen for  3 type of monster so far.   No it not the same ID as me.    Any one would know why this happen

Code: [Select]
Finditem %monstertypes G_1
if #findCnt > 0

Offline Gemviper

  • Sr. Member
  • *
  • Posts: 481
  • Activity:
    0%
  • Reputation Power: 0
  • Gemviper hides in shadows.
  • Respect: +57
  • Referrals: 2
    • View Profile
Re: #FINDCNT incorrect value
« Reply #1 on: November 13, 2016, 06:23:38 AM »
0
I'm not sure this is related but last night the game was "losing" static items that turn into deeds. Example: a fire painting. If you ran a loop to see if the painting was there the script would occasionally lose track of the painting as if it had been re-deeded but it hadn't been.

Something else was strange as well, a search for G(or G_18) was ALWAYS targeting whatever item was at MAX range in the SE corner instead of the usually closest item that matched. IE: looking for an item used to start the search close to you and expand outwards but it wasn't doing that last night.

No this wasn't from a script someone wrote and inserted code to make it not work in some situations, I put things down in a grid and tested repeatedly... maybe 20% of the time the above was happening on a simple G finditem outside of any script.

Just some weird stuff last night... seems fixed today.

Also weird - someone using an elite script from this forum causes my screen to spam with "pathfinding" text whenever they are near and waiting for a house to fall(nothing happens to my character, the text is above his head not mine). He runs 3 accounts at idocs regularly, in case that sounds familiar. I see the text over his head x 3 non-stop, even when I'm not running EUO. Again, no clue if any of this is related beyond the time it happened(last night). My guess is he's somehow sharing info between his scripts/accounts improperly but figured I'd mention it... last night had some odd stuff going on.
« Last Edit: November 13, 2016, 06:31:52 AM by Gemviper »

Offline manwinc

  • Elite
  • *
  • *
  • Posts: 2556
  • Activity:
    0%
  • Reputation Power: 32
  • manwinc is a rising star!manwinc is a rising star!manwinc is a rising star!manwinc is a rising star!manwinc is a rising star!manwinc is a rising star!
  • Gender: Male
  • "The Devs Hard at Work"
  • Respect: +123
  • Referrals: 1
    • View Profile
Re: #FINDCNT incorrect value
« Reply #2 on: January 13, 2017, 11:05:02 AM »
0
Is this happening after things have died?
Monkeys and Typewriters!

" Oh I know, We'll make a Boss Encounter that requires 3 keys per player to enter, Then we'll make it not a closed instance so you never know if you are going to pop into a fresh room or a boss that has 1% Health left with 20 dudes smashing its face in, wasting your time and effort"

Offline BobOzarius

  • Full Member
  • ***
  • Posts: 103
  • Activity:
    0%
  • Reputation Power: 2
  • BobOzarius has no influence.
  • Respect: +26
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #3 on: January 13, 2017, 12:20:46 PM »
0
It can also be that some spawn will spawn in areas where you can't see them, but the script picks them up. You should check their z-height. There is a lot of other info in the #findindex of the monsters you can't see that can help you debug what's going on. Post the info for all the items for each #findindex. Maybe there's something in there that can help.

Offline The GhostTopic starter

  • Elite
  • *
  • *
  • Posts: 1917
  • Activity:
    0%
  • Reputation Power: 25
  • The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.
  • Respect: +245
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #4 on: January 13, 2017, 02:18:37 PM »
0
I was hunting at the dragon Liar, killing Frairy dragon and notice that  my snippet only cast LS and not othe special.  Yes  my snippet work becaue i use it at other location.    The findcnt event indicate 2 when only one is present.  The harrower return  a findscnt of two,  not sure why.  

Manwinc, no no corpse around.  

This is on Rebirth BTW I haven't try it on OSI yet.  

Edit:

I add a Finditem %monstertypes G_1 in my patchfind loop  and that fix a part of the problem. The Wyvern still see two findcnt 2. 
« Last Edit: January 13, 2017, 05:03:23 PM by The Ghost »

Offline Gemviper

  • Sr. Member
  • *
  • Posts: 481
  • Activity:
    0%
  • Reputation Power: 0
  • Gemviper hides in shadows.
  • Respect: +57
  • Referrals: 2
    • View Profile
Re: #FINDCNT incorrect value
« Reply #5 on: February 03, 2017, 04:14:00 AM »
0
I have a loop to move towards an item until it's in range and used an if #findcnt <> -1 to loop again... and when it finds nothing near me the #findcnt goes to -1 but an itemtype of YM is somehow found(#findcnt remains -1) and the loop does not recognize the false condition and continues moving towards....


wait for it


a chest at luna bank even if I'm in Skara Brae! Literally, the character runs towards Luna despite that being a different subserver. I checked the itemID it was looking for(despite a #findcnt of -1) and it's the chest beside the provisioner in Luna which shouldn't have an itemtype of YM to begin with. I decided that using a #findcnt check as a condition was probably not a good idea, lol.

This was just for testing purposes, I don't use it in any script.


Offline BobOzarius

  • Full Member
  • ***
  • Posts: 103
  • Activity:
    0%
  • Reputation Power: 2
  • BobOzarius has no influence.
  • Respect: +26
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #6 on: February 03, 2017, 06:19:17 AM »
0
Why not just use: if #findcnt > 0. That means an item was found. -1 might be throwing it off since it's finding a YM item. Which I believe literally means nothing... and it sounds like it's coming up with -1 as the result...?  Grasping at straws here. But #findcnt works perfectly. I use it a ton.

Offline The GhostTopic starter

  • Elite
  • *
  • *
  • Posts: 1917
  • Activity:
    0%
  • Reputation Power: 25
  • The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.
  • Respect: +245
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #7 on: February 03, 2017, 04:22:19 PM »
0
Same her I use it alot too.   It just that for some type of monster it not returning the correct result.  I can count the monster in one hand that return false value.  99% of the time it work perfectly.   I have never notice before I didn't count the monster I was attacking.   

Offline Gemviper

  • Sr. Member
  • *
  • Posts: 481
  • Activity:
    0%
  • Reputation Power: 0
  • Gemviper hides in shadows.
  • Respect: +57
  • Referrals: 2
    • View Profile
Re: #FINDCNT incorrect value
« Reply #8 on: February 09, 2017, 01:46:32 AM »
0
Quote
Why not just use: if #findcnt > 0. That means an item was found.

Not always. If you perform one finditem and iterate through the results to perform an action, like run towards one of the results, an if #findcnt > 0 will return true even if that particular item(or corpse) is no longer there, is ignored etc. The reason being if 25 items were found the #findcnt just increments downwards with each iteration.

example: You're running a looting script and while running towards the 3rd result of your finditem iteration someone else picks it up. CHecking to see if it's still there before continuing to run using if #findcnt > 0 will result in a false positive... you may have found 25 items and so the 3rd result would still leave #findcnt at +23. It increments downwards with each iteration.

Of course you could add a new finditem but that defeats the purpose of just using one to begin with(speed). In this scenario it's actually better to set a variable with the current item result and monitor it's distance from you until it's within 3 tiles. If it suddenly goes N/A it's gone and you can continue the loop to move on to the next item.

Check to make sure your script isn't using #findindex together with a #findcnt > 0 within it's loop? I'm not as polished as some others here though and I'm sure you can get better advice, but I hope that made sense.
« Last Edit: February 09, 2017, 01:51:49 AM by Gemviper »

Offline BobOzarius

  • Full Member
  • ***
  • Posts: 103
  • Activity:
    0%
  • Reputation Power: 2
  • BobOzarius has no influence.
  • Respect: +26
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #9 on: February 09, 2017, 05:17:17 AM »
0
#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.

Offline The GhostTopic starter

  • Elite
  • *
  • *
  • Posts: 1917
  • Activity:
    0%
  • Reputation Power: 25
  • The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.The Ghost is on the verge of being accepted.
  • Respect: +245
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #10 on: February 09, 2017, 07:18:16 AM »
0
Thx for the input. 

I'm scanning to monster at one title and attacking it.   I notice the last time I was doing The Harrower   
that my statement  was activated
Code: [Select]
if ( #FINDCNT = 2 )
gosub ms

and this statement wasn't activated
Code: [Select]
if ( #FINDCNT = 1 )
gosub ls

Like I said, it happen with big boss monster.   All the champ lvl work perfectly.   

Offline BobOzarius

  • Full Member
  • ***
  • Posts: 103
  • Activity:
    0%
  • Reputation Power: 2
  • BobOzarius has no influence.
  • Respect: +26
  • Referrals: 0
    • View Profile
Re: #FINDCNT incorrect value
« Reply #11 on: February 09, 2017, 09:41:39 AM »
0
Well you probly want it to be if #findcnt >= 2. That would be much more logical. Unless you ONLY want it to MS at 2 monsters, because you want it to whirlwind at 3 and above. And at 1, you want it to ai or something. Then maybe I see your point. But = 1 and = 2 works fine if there's 1 and 2 monsters found. Are you pixel scanning for LS? Did the icon move? There's a lot of reasons why it didn't activate. We'd probly need to see your code.
« Last Edit: February 09, 2017, 09:45:04 AM by BobOzarius »

Tags: