Ranger Fox

I updated the cartridge so you also have a radar item. It will attempt to update every five seconds if you move three or more meters away. Thus, you can either play the game by asking and being told or just stay on the radar item. I'll let you contribute pictures for the warm and cold messages, then I'll wire them in.

You can find a rough working version here. In this version, you ask an item whether you are hot or cold. I have five special messages as you get closer. When playing, the answer to the first question is "Ranger Fox". The cache zone is about 120 meters to the west of the starting zone. You should be able to change everything around by viewing the cartridge in a builder application. Note all the variables. Pay attention to their descriptions. You can expand or constrict when the game's special messages are shown, change the message itself, and change the general hot/cold message. If you look at the source, the main work is done in the function DoHotOrColdWork(). I'll let you play around with it and provide feedback. If you want to refine it further, you can. Please send me the source code when you're done. For kicks and giggles, I'll hide a Wherigo geocache in my own area using this cartridge, just because I don't believe many of the locals like Wherigo.

Some thoughts and observations: Interesting about the question for the starting location. I wouldn't have considered doing that since information could always get around. Instead of a timer every ten seconds, we can just wait until the player moves more than fifteen meters away. Doing so simplifies the implementation since that's one less thing we'll have to worry about. Okay, so a message can pop up to tell the player hotter or colder. I'll have to make something so the message must be dismissed prior to starting the next fifteen meters. When someone reaches the geocache zone, we can have a message pop up and the geocache zone become visible. When I get involved in cartridge creation, so long as it's not absolutely dependent upon the location, I try to make it reusable and editable by others. I've gotten better at that over the years. Most cartridges, though, require you to edit the lua script. This one, though, I'm going to see if I can make it so you can edit everything 100% in a builder app. That means you're going to see a TON of variables. These will control how the game is set up, the messages shown to the player, distances, and so on. My personal success criteria is how easy it is for other people to edit the cartridge for their own area.

It shouldn't be too hard to make a cartridge like that, then. There are a couple ways this could be set up: Every 30 seconds, the cartridge would automatically tell you if you're hotter or colder than last time, provided you're at least 15 meters away from the last coordinates Provide an item that has a command that will tell you whether you're hotter or colder than last time Encase the player within a visible zone. The zone's name to the player will either be "HOT" or "COLD". When the player exits the zone, the OnDistant event would fire, triggering the code to update the zone's name and move it to the player's current coordinates. You'd have other considerations: Define a range of words (on fire, burning hot, hot, cool, cold, freezing, not even remotely near) to use based on the distance to the hidden cache. If you're at most ten meters away, you get "on fire". If you're at most twenty-five meters away, you get "burning hot". And so on. Perhaps we could somehow encode the coordinates so this could be a play anywhere cartridge like the popular Reverse Wherigo cartridge. In fact, this entire concept is very similar--but you're not given a distance, which makes it more difficult. (Aside from the online solver, I could just go to three locations, get the distance away, and then use something to compute the final coordinates based on where I was and the distance--but that might be beyond some people.) How do you want to let people know if they're hot or cold: an item, zone name, message box? You don't want to limit the number of guesses people have because they can just restart the cartridge, not resuming from save state. Refine the idea here. Should we use an item command for players to ask if they're hot or cold? Should we use a zone? Perhaps limit it to telling players every thirty seconds regardless where they are? If the idea is hammered out, I might make an open source cartridge you can use. Just plug in the final coordinates, perhaps adjust the variables that control the words used, and you're off. I'll make sure it's easy to change around if you import the cartridge's code into a builder application. But, first, hammer out the full concept here.

You're very welcome. Anything to reduce complexity and make cartridges easier to work with is a plus. To make things even more fun, you could put a timer object in inventory. You could make the name look like "300 seconds remaining", then adjust the name every timer tick. You might have to enable and disable the object to notify the player app that the name changed. Theoretically, you could also do the same for a zone's name. I do not, however, know off the top of my head how player apps will react with regard to their navigation UI if you change the zone's name, then disable and enable it to force the UI update. That is, if a navigation compass is displayed and the zone briefly has its enabled state toggled, I'm not sure if the compass UI will continue to be shown. That's why I was going with the item idea instead. Enjoy!

Timers are rudimentary. You can start and stop them, but can't poll the remaining time or pause them. What we usually do is set a smaller interval timer, such as five seconds. When the timer elapses, we increment a variable that represents the number of times this timer has elapsed. We can then perform tests based on this. You can then stop and start the smaller timer without worry. Thus, some pseudocode on the smaller timer's elapsed event: Increment the number of times this timer has elapsed If the number of times this timer has elapsed is greater than or equal to 15 x (60 / 5), perform the game over routine Note: the math works out so it's the number of times the timer can elapse in 15 minutes if the timer elapses every five seconds Else if the number of times this timer has elapsed is cleanly divisible by 60, move the antagonist Note: this is called modulus. Since I don't believe you can do this through the Urwigo UI, you could always maintain a second timer elapsed variable, incrementing both the game order and the antagonist move variables when the timer elapses. When you move the antagonist, you set the antagonist move variable to zero, thereby resetting it. Else don't do anything

Try removing the apostrophe from the requested answer. I bet that's it. The apostrophe is an interesting character. Some phones replace the standard apostrophe character with another one entirely. It's not just a font thing: it's a different character code entirely. I know about this because my mother's geocaching user name uses an apostrophe. When I was helping her sign in to the geocaching app on her phone a couple years ago, I noticed the phone kept replacing the apostrophe character with another one. To get it so she could log in, I had to pull up her profile in a web browser, copy her user name, and paste it into the app's login box. Honestly, I never connected that to what would happen with Wherigo when someone tests for an apostrophe in their answer.

That's one of the most requested features since the start. When you create another cartridge, instead of uploading it as a new listing, you could reuse the deleted listing, reusing it for the new cartridge. That way, you won't have a cartridge listing you can't remove anymore.

Mind sharing the GWZ with me and the link where you uploaded it on Wherigo.com so I can look through it over the weekend? The address I'm currently using is the geocaching at Ranger Fox one.

If you're downloading for Garmin, I do know the Wherigo compiler strips out the sound files because Garmin devices can't play sound. I believe the pictures should be included in the cartrdge. Are you saying the compiler strips out the mp3 files when your download target is "Pocket PC"?

I considered what I'd do if some sort of drastic winter weather happened to me. I'd likely be walking several miles in an attempt to continue my streak. I've been doing this ever since just before my first year geocaching anniversary, so it's something I do. The walking through the snow would just be another story for me to tell. Of course, living through some stories might not be delightful, but they make stories all the same. And as long as the streak forces me to get out and do things and have experiences, it fulfills its purpose. Last week, I visited an area where I was able to get some fairly nice photos of birds while going for a cache. If I wasn't forced to go places due to a streak, I wouldn't have had that experience.

I consider the only day possible for you to log a challenge cache is whichever is later: the day you sign the physical log or the day you complete the challenge. Since all modern challenges involve finding caches, the only real day to use a challenge cache is the day you sign the physical log since waiting for later means you would have found a cache on the same day that enabled qualification. (And we're not going to complicate this by bringing my physical-only personal rule into it since some challenge caches can involve virtuals, events, earthcaches, etc.) If you try to do something you don't believe is right, it'll gnaw at you for ages to come. Do whatever you want. A streak has no social value for me since it has long since become a way of life. It's me versus myself on this, and I'm not going to give myself any excuse to self-denigrate me. I tend to adopt as many restrictive yet fair rules as I can find. Whatever you do, make sure you don't regret the decision. --- Oh, crud, @Vicious Cycle, I don't actually plan things beforehand or make any special effort! It's just based on wherever I feel like going on a given day. Guess it's not a real streak. (I'm joking with you--but being truthful that I don't plan.)

It's only a problem if that's what it's like in the code. A builder application will strip out spaces for any variables it generates. When you wrote "Butcher Park Tour.Version", it seemed like you were quoting code.

Great to hear you found a solution. It's an even better feeling to figure it out yourself. If your code actually used a variable like "Butcher Park Tour.Version", it would first be the spaces in the object name that did it. Also, the object likely wouldn't exist. The naming convention would usually make the object be named "cartButcherParkTour". I believe if you attempted to concatenate a string and numeric data type, lua should do the numeric type's conversion to a string for you. Most languages will be that helpful.

I waited a bit to see if anyone else would offer to help. So, looks like I will. You can download other cartridges, right? If so, it might be due to something interesting in your cartridge. Every now and then, a cartridge might use a reserved word or do something else that gives the compiler a hard time. And, rarely, you can use the compile service and get a cartridge, then not be able to download it once you upload the cartridge to your listing (this is very, very rare). Anyway, if you'll send me your GWZ file, I'll put in some time to figure out why. I'm not expecting this to be a quick fix, but I'll get it done and then let you know what it was. As long as I can reproduce your problem when I upload the cartridge, I can figure out what's going on. What I usually do is remove most of the cartridge's content manually until the download works, then slowly add parts of the cartridge back into the file until I get the download error. Anyone can do it, though it does take someone knowing what they're doing since you have to make sure you still have a cartridge that can be compiled successfully.

Yeah! Progress. And be that guy, @Mangatome. Laws and regulations exist to encourage everyone to be respectful of others' rights so we can all play together nicely. And congratulations to @jokergil, who successfully caused the first site update in many, many years. Just a little lighthearted joking.

I assumed you were either using translation software or you weren't fully fluent. I appreciate the effort you made. I hope people can be just as patient with me when I try using translation software to communicate. I will eventually go overseas somewhere. I will be very uncomfortable being in a place where I won't be able to communicate. But I did make a promise to myself to go overseas after finding 100K. I need to follow through with it one day, once I find someone to come with me. I think the first of the two trips will be to Japan to experience nature, onsens, an shrines--but not the big cities. I don't care for cramped, crowded places.

Whoever replied might not have understood your question. If you would, please reply to them and send them a link to this reply. To get a link, click on the "..." in the top-right corner and choose "Share". It will give you a link you can use. ------- @jokergil, I believe you are asking about changing your profile text, profile image, and homepage address on your Wherigo.com profile. As mentioned in Groundspeak's reply, you should be able to edit your profile text on geocaching.com via this address: https://www.geocaching.com/account/settings/profile . The other two items, your profile image and homepage address, are discontinued features. These cannot be edited via geocaching.com. Of the two, the more worrisome is the homepage link. Since it cannot be edited anywhere and the feature is no longer supported, I strongly suggest Groundspeak remove this section from the Wherigo.com profile page. The profile image could be removed as well, but it at least acts as a decoration. I have a suggestion for Groundspeak: since you'd likely not prefer recompiling and deploying the site, there is a way you can update the site to remove this content without a recompile and deploy. Here are directions: From either the server or source control, retrieve the file /my/profile.aspx and open it in a text editor. Search for the text "lblHomepage". It will take you to an ASP.Net Label control. You'll notice it's in an "li" element. The element likely just looks like this: <li> Change the element so it looks like this: <li runat="server" visible="false"> Do the same for the "li" element following this one. Doing so will prevent the user's location section from being visually offset by two empty "li" elements, making it look odd to someone looking at the page. If you would like to remove the profile photo, find "lnkPhoto" in the file. This will take you to an ASP.Net HyperLink control. Above it is this "div" element: <div class="detailsLeft"> Once more, update the element so it looks like this: <div runat="server" visible="false" class="detailsLeft"> This will leave you with an empty section on the left. If you would like to make the profile information span the width of the container, follow these directions: Search for the text "pnlProfile". It will take you to an ASP.Net Panel control. Remove the 750px width style. It might look like this: Width="750" Search for the text "contentLeft". It will take you to a "div" element with that as its ID. Change it to look like this: <div id="contentLeft" style="width: 100%"> Search for the text "detailsRight". It will take you to a "div" element with this as its class. Change it to look like this: <div class="detailsRight" style="margin-left: 0px;"> Save the profile.aspx file and deploy it to the test environment, if one still exists. If one does not, you may deploy it directly into the production environment because I know what I'm doing. You're welcome. Grattitude could simply be expressed with words, if you found the above helpful. If you're not advised to post a reply, then please remember this kindness and perform a kindness to someone else and suggest they pass it on.

You're right. I didn't check there because I remembered a time when they removed the user name changing functionality. Since I had no need of it, I hadn't taken note when it was brought back. (And someone like me changing their user name is going to be a big no-no.) Personally, among the features that were removed over time, the one I'm sad the most about their removing it is the profile picture. I used to change my profile picture every month to show I was still active. Some months, I changed it weekly. This forced me to come up with interesting places and poses near caches to take a picture. After the feature was discontinued, I stopped taking posed photos of myself because I lacked the discipline to keep it going if I wasn't going to do anything with the photos. Looking back, it was nice to look at the profile pictures I had taken, and a little sad to realize I don't have that many usable profile pictures taken after the feature was discontinued. Anyway, that's a fun little tidbit of a tangent for you.

I believe you're confusing a cartridge listing with versions. If I upload "My Fun Cartridge", that's a listing along with its first version. If I want to make an edit to the cartridge after that, I go to the listing and click on a link to upload a new version of the cartridge. You don't create an entirely new listing. Since you're not creating a new listing, nothing needs to be deleted. (And while it's true you can't delete a cartridge listing, you can still edit the listing an uncheck the box to show the listing in the directory, which effectively hides it to all but those with a direct URL to the listing.)

It looks like modifying one's homepage (website) was removed from the geocaching profile options, but the data still retained. Both the Wherigo and Waymarking sites were not updated to remove a user's homepage URL. The easiest thing for Groundspeak to do would be to wrap the HTML in a new span tag with the runat="server" and visible="false" attributes. The server would then not send that section of the HTML to the client wile still allowing the code to run without a null reference exception. Taking this action will NOT require a site code edit or recompile, which is a strong plus in Groundspeak's situation. Oddly enough, the Waymarking website has functionality to allow you to change your user name. I don't want to experiment with something like that.

The text "Nothing of interest" is something the player app itself puts there. The text itself is not editable. Thank you for the compliment!

We're intending to build new methods against which cartridges can call. This itself is a change. We will need to track both the lua version AND Wherigo version against which a cartridge is created. For those who don't understand this, here's an easy example: when Wherigo v2 comes out, it'll likely support video files. We'll call this Wherigo v2.0. When we complete work for multiplayer and release that, it'll be Wherigo v2.1. The lua version, v5.4, didn't change in the meantime, however, a Wherigo v2.1 cartridge cannot be played on a player app that only has Wherigo v2.0. The user will need to visit their app store and download an update to the player app. I intend for these tenants to be followed: When a builder application contacts the Wherigo API, it must define the lua and Wherigo versions ("versions") against which the cartridge was created. The API can reject the command if the versions don't match ones it accepts. Both versions will be stored alongside that version of the source code (i.e. it isn't globally defined at the cartridge level, but at the version of the source code). The listing service will contact the building service, asking for it to perform a build of the cartridge against that lua and Wherigo version as a test. If it succeeds, the API will accept the source code and version numbers. For v2, we can decide to use token text when things like a user's name is requested to be placed into the cartridge. Therefore, it'll be up to the player app to substitute that token text when it comes across it. This would allow me to store and serve one compiled bytecode to all clients, reducing server resources and response time prior to a download begins. I like that idea. Wish I thought of it sooner. (We could possibly inject the player's name into a v1 cartridge to achieve the same effect.) A cartridge author can choose to switch an existing cartridge to a new version of lua or Wherigo if desired. Simply use the builder application (or other tool) to upload the cartridge source code again, using a different version identifier. The API will once again perform a build validation against the building service. The API will provide to any caller the lua and Wherigo version numbers it supports, including one endpoint that just says the current version numbers for all things. When the API provides cartridge search results, it will include the cartridge's current version numbers. It's up to the calling application to know whether it can play such a cartridge. When cartridge bytecode is requested, it will only be built against the lua and Wherigo versions against which it was uploaded. This ensures on our end that the cartridge functions true to how the author [should have] tested it. The player app is responsible for loading the proper environment to handle a cartridge with this lua and Wherigo version number. When deploying a new version of anything to the Wherigo ecosystem, updates must flow in this sequence: builder service, API, website (if applicable), player app, builder application. If this sequence is broken, bad things can happen. We could perform a preview release by allowing these to work with new versions without advertising it or enforcing a new version by default. This would help for testing. Communication will be crucial.

Okay, then let's do this: Wherigo v2 cartridges will at first be in lua. The player app will need to be built in such a way that we can swap the environments we're using. For all v1 cartridges, the player app will use that version of lua. For all v2 cartridges, we'll record the language and version against which it was built. When the Wherigo listing service API provides the cartridge to the player app, it will also provide this metadata. The player app can then load the correct environment and the cartridge itself. As time progresses, we would then be able to upgrade the lua version and even offer other languages for cartridges without breaking existing cartridges. We can also feel free to add objects and methods to the player API without upgrading the environment. If we modify objects or methods in the player API, we can then build that as a new environment. Media must be supplied with the cartridge data when publishing a version of the cartridge. What the Wherigo listing service API does with this information is up to that system. However, the media does not need to be compiled with the cartridge code. The listing service API can provide media files to the player app either on demand or all at once. The listing service API also reserves the right to provide either the binary data itself or a URI for the media. (I would not prefer to serve binaries directly from the listing service API. Instead, I'd prefer to provide a URI to either Azure or AWS Storage so the listing service API can reply to more requests without having to scale out--though the API itself will me made specifically to be scaled out.) The player app is given latitude with how it deals with coordinates and cartridge events. The player app might therefore process proximity/in events at the author-desired coordinates and distance, but distant/out events when the coordinates read twice the EPE away. The player app team can implement this however they wish. Later, I need to start a thread about what people expect in the new version of the listing service. For all I can tell, everything I have in the current one is what we'll need, plus responsive design (and, oh boy, will I definitely need a UI/UX engineer and/or designer to help with the front end).

Perhaps people fall into these groups: Players: Someone who does not know anything about Wherigo First-time player, either good with technology (most younger people) or is scared of new apps (my mother) A player who knows that you go to locations with Wherigo, but does not know you also have NPCs and items A player who is confident about their knowledge and would just need to know about changes Authors: A first-time author, grouped into one of two buckets: script kiddie or better, someone who doesn't know (and shouldn't care) what's involved in making a cartridge Someone who would just like to create a basic type of cartridge, or one that can be templated into a point-and-click process Someone who is now familiar enough with cartridges and would be willing to learn a little more to create something different. This person would be a great candidate for looking at code/widget snippets to implement them inside their cartridge. They might not understand the code behind it, but they understand that to get the effect they want, they have to have two zones and one item supplied to the widget to use it. Good with UI or code, but not both A group of people who would need to edit the same cartridge, sharing it back and forth, to create something Someone who would prefer just to work with the code and not with a builder application Someone from a parks and recreation department or park worker who is looking to create a tour of their park. This person has some organizational backing, but not much experience doing anything with Wherigo or coding in general. They might want to create something like a passport book, where visiting different areas will reward you with stamps in the book, and some way to turn in a completed passport book for a prize or something. (I've seen several instances outside Wherigo of agencies trying to do this.) Does that help? Anyone with comments or opinions?