Audion64

Aggh, extremely sorry for the multiple posts... dunno how that happened.

Add my name to the list of those requesting this feature. As well as adding a quick "Ignore Listing" button to each cache on the map. The multiple screens/clicks required to ignore a single cache is WAAAYY to cumbersome. For me to ignore the chaff caches just within 20 miles of home would take me DAYS with the current system.

Add my name to the list of those requesting this feature. As well as adding a quick "Ignore Listing" button to each cache on the map. The multiple screens/clicks required to ignore a single cache is WAAAYY to cumbersome. For me to ignore the chaff caches just within 20 miles of home would take me DAYS with the current system.

Add my name to the list of those requesting this feature. As well as adding a quick "Ignore Listing" button to each cache on the map. The multiple screens/clicks required to ignore a single cache is WAAAYY to cumbersome. For me to ignore the chaff caches just within 20 miles of home would take me DAYS with the current system.

Have to agree with Kealia here, both features should be added ASAP.

Add my name to the list of those wanting the ability to have IGNORED caches filtered from the Google maps.... while you're at it, a bigger ignore list and easier ability to 'mass' ignore caches. There is sooo much chaff out there it's going to take hours and hours just to filter it out.

If you could present an existing, real-world example or two of an "out of hand" ALR, your claim might be more persuasive. A couple of examples of how the whole ALR thing is accelerating down the slippery slope.... Challenging Challenge Challenge The Anti Challenge Challenge What's next? The Anti Challenging Challenge Anti Anti Challenge? Come on get real.

I'm sure that this is going to create all kinds of controversy. I just want to say that I support the Groundspeak staff in this decision and thank them for doing it.

Ah, silly me, I missed the part about leaving the larger zone inactive. Which makes perfect sense and doesn't add processor load, just a tiny amount of memory usage as you mentioned.

I haven't actually downloaded and tried the cart (I will be for sure though) but this sounds like a very workable 'work-around' to the zone boundary 'in-out' problem. I would say that just programming the coordinates to change rather than creating extra larger pseudo zones would be better just in the sense that there is less burden put on the processor calculating zones which aren't actually being used. Looking forward to testing out your idea!

The built-in command to do that is "Show a series of Dialog messages to the Player." It's the second to last command on the list of Actions. After each screen of information there will be an OK button for the Player to press to proceed to the next screen of info.

Thanks for that info Delta68. Dunno why I didn't try that long ago.

It's also possible to force the Emulator to NOT report itself as 'DeskTop'... much easier than editing each GWC.

Getting a completion code takes seconds. I do NOT believe that you can get the final co-ordinates. It is simply not possible because they are not there! The best you'd be able to get is 64 possible sets of co-ordinates and then narrow that down by ignoring ones in lakes etc Thanks M Of course the coordinates are not within the cartridge in plain text or possibly even in encrypted form but if the CARTRIDGE can verify that a player is at the correct final location (be it thru a formula or whatever) then it is completely possible to reverse engineer the proper coordinates back out of the cartridge. Being that there are only 64 possible combinations in that case brute forcing it would be almost more logical rather than spend time decompiling the cartridge. BTW, at least 2 of the answers are available on the internet... so the number of viable combinations drops also. Either way, I'd much rather visit so I can actually DO the cache.

Using the flags should be pretty simple. Just use the 'Locked' flag for the Ball, that flag is built into every Item by default. Set the 'Locked' status for the Ball item to 'Locked' when starting the cartridge or when the Player acquires the Ball. Only set it to 'Unlocked' when the Player successfully completes the 'Place' command (ie, they have the Ball and are in the correct zone to be able to Place it). Then your Swing Check just has to look at the Locked/Unlocked status of the Ball to determine if it has been properly Placed.

Hmm.. PM me the final co-ords then! M Well of course I've not visited the physical cache, but I've logged a 'Completed' game on the Wherigo site. Your only option to prove otherwise is to verify the written log inside the cache. With enough putzing around I could get the final coords to you but my goal at the time was to get a completion code or uploadable 'completed' cartridge. I succeeded in that goal in relatively short time. I guess my point is just that you are never going to defeat a determined cheater from logging a find ONLINE for a Wherigo.... obviously they'll often not sign the physical log... that'd be too much work and too much like real geocaching. My original comment was just to say that the emulator check is VERY easy to defeat... you're hex encryption etc was definitely a little more difficult to bypass. But from what I learned in the little adventure I'm guessing I could 'Complete' just about any Wherigo in under 10 minutes now. Trust me, I have no desire to do that... I much prefer getting out in nature and enjoy a good hike than pecking away by monitor-light. But the old teenage 'hacker' blood must have never died in me, I enjoy that challenge too. The whole idea of cheat-proofing IMHO is to limit the number of times I have to visit my own cache to verify written logs. I seen people logging Wherigo's all over the place that they obviously haven't physically done, just to get the almighty ICON. And I've had people in my area log one of my high terrain caches but never signed the logbook and could not describe the area of ground zero or the cache container.... just wanted that high terrain smiley I guess.

Bet you can't crack our Brueton Park one! I've even uploaded the entire source code (see separate thread) M Took about an hour to crack, didn't need or use the source for the demo version. I'd personally much rather visit the UK (unfortunately I've never been outside the USA ) and actually play your cartridge though... it looks like fun.

I'd be willing to take a look at what you're working on Delta. If it's storyline scripting you're looking for (ie; not the programming type) I'd be willing to help with that. BTW.... there IS a way around the emulator check. Just like any sort of copy protection on software... you'll stop 95% of the casual cheaters but if it can be played, it can be cracked.

Device ID check won't work. It's actually running on the Colorado so it will return Colorado as expected. But in Demo mode the user can basically do just like in the emulator and 'virtually' move from zone to zone. As far as I know, there is currently no method to detect that a Colorado user has placed it into Demo mode.

Is your question 'attached' to an item or something? I guess what I'm asking is, if they answer incorrectly how are you getting back to the top to ask the question again?

We can put the GC# of an associated cache on the Wherigo page but cannot link to it since there is no way to enter HTML into a Wherigo page like you can with a normal cache page. At least no way that I've found.

No, more correctly, the Wherigo Player for the Colorado should be fixed to function as intended. The OnEnter function is SUPPOSED to trigger whenever the player crosses any edge of a zone. And this is how it functions within the PDA Player but apparently the Colorado and PDA versions of the Player are being developed separately rather than being cross-platform with identical source code being compiled for the two different devices. As a Builder and as a Player... the fact that the Wherigo Player does not function consistently across BOTH platforms is very disappointing. Personally I would even be willing to deal with MORE bugs.... IF those same bugs were consistent across platforms.

I guess the big question is, what shape are the default zones really? The Builder shows a standard zone as a square/rectangle, which I always thought was odd. I'm not really up on the math calculations but I would think that having the hardware calculating distance to a radius from a central point would be less CPU intensive than having to calculate actual shape edges etc. From my experience, making zones with multiple sides and in convoluted shapes seems to make them less 'reliable'. So I've usually stuck with the default squarish zone shape when possible. Anyone from Groundspeak want to chime in with how the actual zone OnEnter/Exit, distance to the zone etc are being calculated? It would be VERY helpful for us builders to understand this better.

No since you are entering it as the VALUE to set DeviceID equal to. Entered this way the Builder just assumes you are entering text so you can enter whatever you want. You can do the whole thing from within the Builder.

Well that's rather embarrassing. I goofed. I had forgotten exactly how I had done it. You are correct about not wanting to create the Env.DeviceID variable. In fact, apparently you can't. The Builder automatically removes the dot so your variable name becomes EnvDeviceID, and THAT is why my uploaded cartridge did not work. Now I am remembering correctly. You create the DeviceID variable (or whatever else you want to call it) And then set that variable equal to the VALUE 'Env.DeviceID'. And this is why there has to be the intermediate step also. To temporarily remove the emulator check simply change the word 'DeskTop' within the IF/THEN statement to anything other than 'DeskTop'. Fixed (and tested, as I should have done in the first place), LUA file attached. EmulatorCheck.zip