Ranger Fox

Game saves - The online game save backup feature does not have to be immediate. A game save will be created immediately on the device and can be backed up to the server some other time. This allows you to have access to your game saves across devices. If you switch to another device, you can resume the same cartridge. It's a convenience feature. - As for how we'll work with a different cartridge's game save, it should be understood by the author that such a game save might not exist. If the cartridge is downloaded and later played offline, this might pose a problem. Perhaps each cartridge should have a manifest so things like this, online-required play, and other capabilities be declared. After all, multiplayer would have to be an online-only feature. Video - I've gone back and forth on what to do with video: 1) should it be a link to YouTube, 2) should I store it on the server and stream it, 3) should I store it on the server and the player app (and user) decide whether to download all assets ahead of time, 4) how much storage space should I allow for each cartridge, 5) should video and other expensive assets be retained when a cartridge is archived, 6) should I convert video to a lower quality if someone uploads in high quality (say, convert to 720p if someone uploads in 8K). - I have a rather small cellular data plan. Last year, it was only 2GB/month, but then I was bumped up to the 5GB/month plan because my old one didn't exist anymore. I don't like the idea of having to stream a video in the field. But if I have to download a cartridge in the field, I don't like the idea of having to download all assets, either, because my playthrough might not need every single asset. So, perhaps all assets should be downloaded while on WiFi and streaming be used on cellular (unless the user wishes to download all assets via a cellular connection). Player app I've also wondered about constructing a player app 100% using Blazor. Three years ago, I constructed a rudimentary player app using Blazor and a cartridge in C#, just to see what that would be like. Blazor has changed since then, and the proper way to do it these days would be with MAUI if we were going the .Net route. UI It would certainly help to have assistance with someone wireframing, drawing out, or constructing the UI for the site. Doing that and making it responsive would take me quite a bit of time. If I could have someone better do it, my time would be better spent in creating the back end. And though I want to do the thing in Blazor, I'm still new to it. Professionally, every time I was brought in to work on a project, people said a site was using MVC only for me to realize I'm back in WebForms land. I've done a weird way of making WebForms sites over the past decade, using WebForms only to construct the initial layout and JavaScript and API calls to handle everything else. An unreleased version of Kit was made using almost 100% script hosted in WebForms (I didn't release it because I tired myself out after the builder portion was created, so I never completed the cartridge listing and login portions). I've wanted to construct a site using Blazor. However, I believe the first thing you make from start to finish should be discarded right after you make it because you've learned so much. Oh, well. At some point, I'll either construct a site at work using Blazor or a new Wherigo listing site using it. And, yes, a huge amount of work would need to be done to launch Wherigo v2, but a large amount of planning also needs to be done ahead of time. The question as to which languages a cartridge should use and how it should be packaged is also up for discussion. That will be sooner than later, but the intended features might likely play into such a decision, so I wanted to discuss features first.

If we're interested in seeing Wherigo progress, we'll need a list of features for the next version of Wherigo. This topic is for coming up with a list of features and categorizing them into of these buckets: Required - This must be done and there's no question about it. High Priority - While not absolutely necessary, having this will be extremely important for the product. I would like between three to five major things here. v2.1 - This feature can be deferred, but not for long Nice to Have - Great for quality of life, but we can do without it for a while Long Term - We can do without it, but it would be nice if we can get around to including it one day Required Cartridges as files - But try to avoid letting players get their hands on them, so we might encrypt them when we store them on a device Zones as points - The bare minimum for a zone, just a point on a map with a proximity range for events. NPCs and items - I see a lot of cartridges that use these, so I'll make them required Message boxes Multiple-choice inputs - Allow the cartridge developer to set the order. This is still text-based. Open-ended inputs The Wherigo Foundation cartridge contributor scheme - A cartridge will be owned primarily by one account, but you can assign full access to other accounts ("contributors"), give other users readonly access to the source, assign some playtesters prior to release, and make your cartridge open source (but readonly) to all Game saves - Not only are they stored locally, but they'll automatically be backed to the server so you can access them across devices. Authors will be able to save any type of serializable object to the game save storage. An author can access game saves from other cartridges where they're a contributor. This will allow state to be carried over to other cartridges. Map-first game board - The main game board is the map. Show everything on the map and update all objects live. API - Everything from the listing site, player app, builders, emulators communicate through an API Scoring mechanism - You get points for playing and building, and you have to do both to make the most of it. You can't continue taking from the community, nor can you build without experiencing cartridges for yourself. The time involved, infrequency of completions, special achievements (50+ people completing a cartridge in the same day), and so on can be taken into account with scoring. Listing service administration - Set up the possibility for reviewers and other community roles Allow for cartridge searching to be done within the app and online The listing site must be responsive. Certain links could also launch the player app and allow immediate downloads. You can also just click a button on the site to send the cartridge to your device without having to launch the app and download it from there. (Or the app, when launched, could just query for cartridges on the user's download queue.) Timers - full suite of controls: start, stop, pause, get remaining or elapsed, events Automatically mark a cartridge as complete on the site when the cartridge says it's complete. Logging a cartridge playthough is optional and will instead be termed as feedback instead of a log. Tile-based inventory view. Inventory items can have a quantity (e.g. number of keys) or percentage (e.g. fuel). A cartridge's publication still needs to be tied to the geocache's visibility and status Decide about the cartridge type and rating system. Some sort of categorization. Backwards-compatible player. Allow v1 cartridges to be hosted on the listing service and provided through the API. High Priority Video - Do we want streaming from a YouTube link or do we want video files included with the cartridge itself? Give the player the ability to skip a video Audio - Full audio information: start, stop, start from a time index, raise an event when the audio clip finishes playing, looping Skinnable UI - Only the default skin will be available. This is here so we make sure the UI skin is kept separate from the player app's UI. Skinnable items: message boxes, inputs, NPC dialogs, buttons, etc. Either allow for multiple images in a UI or one image as a background and UI elements like buttons in the foreground. Make sure this UI is responsive to the device's dimensions. Multiplayer - Gametime events in one cartridge can affect other players' experiences in the same cartridge Show a timer (count up or down) on the map view A special text message-like dialog UI when interacting with one or more NPCs QR code scanning functionality When there's an NPC or item with which you can interact, show it on the map view or show some sort of UI cue to the player v2.1 Zones as shapes - So many cartridges use zones as points that I don't think it's a high priority to have shaped zones. You still want them for out of bounds or other things. Give authors the ability to show a zone's shape and/or icon on the map. Make sure the Tetris cartridge I created can work. This will lead to Metal Gear-like features. Tasks - I don't believe tasks are that important, but they do help when resuming a cartridge or if it's unclear what you should be doing. Show incomplete tasks on the top, then descending by order of completion. Multiple-choice tile inputs - Instead of just text-based, allow graphics and tiles for a multiple-choice input. Allow for multiple items to be selected. Use animated GIFs in UI elements Running in the background? Vibration when you reach a zone? If a zone has an icon, show the icon on the map. Things within a zone could have a number indicator to the side of the icon. Allow photos to be submitted with playthrough feedback New cartridge notifications Other object states - NPC/item view open and view close? Or is this too specific? Nice to Have Cartridge author debugging tools - log cartridge errors, playthough data, and so on and make these metrics available to a cartridge's contributors One general completion trophy and one hidden trophy for a cartridge? See other players' locations on your map so long as a player has consented to location sharing Cryptix type input How to prevent cheating? Create a subsystem so it's easier to have moving zones, NPCs, or items. Remember: all object states must be reflected immediately on the map. NPC fields of view - define a field of view and events for when the player enters and leaves an NPC's field of view. Think something like Metal Gear. Projectile subsystem - Allow the player to launch a projectile in the direction the phone is facing. Allow for a speed, maximum width, and distance for a projectile. Allow the width to increase with distance so players don't have to be precise on their aiming. Raise collision events when the projectile collides with a zone, NPC, item, or other object. Allow NPCs to launch projectiles likewise (this would be easy, considering the player itself is an object on the field as well, so you just pass in the player or NPC object as the projectile's origin). Players can give a cartridge author some kudos or something meaningful to the scoring metagame. Show nearby geocaches on the map so those playing a cartridge won't miss a cache. Launch the geocaching app for more details (but save the cartridge's progress prior to launching the app). Allow cartridges to query the player's current speed. Allow events to be set if the player's speed crosses a threshold. Achievements - Based on cartridges completed and created, distance traveled, lonely cartridges, kudos earned, types completed, and so on. Long Term Wherigo Invaders Interaction with other devices like Air Tags Augmented reality would be cool, but I don't know how to set something like this up Collectable cards for cartridges Scoring competition? Allow cartridges to be completed additional times for special events? Weekly or monthly missions Messaging going through the geocaching API I wonder if we can somehow integrate waymarks into the game? Allow one or more graphics to be overlaid on the phone's camera view. This will enable certain interesting puzzles where the graphic will form a word, number, image, or something helpful with something placed in the field. I remember playing the game One Shot where I had to overlay one window atop the game's main window in order to show the path through a maze. Should we allow premium access? We do need some sort of revenue stream if we're to afford the infrastructure. Should we allow micropayments with cartridges for certain features? A cartridge can be completed free, but not all content could be unlocked. Also, a cartridge can't do something shoddy such as launch a ten day timer until completion or allow the player to complete the cartridge instantly for a micropayment. That's all I could come up with in a little more than an hour and a half. And accomplishing it with a volunteer group will take years and years and years. Yes, Wherigo will need to generate some sort of revenue stream so we can afford the infrastructure. I love things to be free and dislike paying for anything digital, but Wherigo does need to have some sort of revenue if it's to pay for its expenses. However, I will not allow ads. Ads are disgusting.

I guess. I'll start another topic in a moment.

Some thoughts, in no particular order: Pokémon Go is successful because it uses the fanbase of a successful franchise. I'm not so sure it would be as popular if it itself were to introduce the idea of Pocket Monsters. Likewise, we have a fanbase of geocachers. Latching onto that avoids the problem of advertising and gathering an initial userbase. And, to be honest, the part of my moderator responsibility would need to prevent discussion in the forum of a non-geocaching service. (That just seems fair delineation.) I like the idea of WASM, but I'm partial because I like what's being done with it with Blazor. Whatever capabilities included in Wherigo v2, I would want absolute control over one feature: networking. You can do some pretty cool things if you gave cartridge developers network access, but there are just too many security concerns and opportunities for abuse. No network access for you. Back to the WASM sandbox. I like this idea. We would expose everything necessary to Wherigo v2 developers through an API, same as when you're creating an app or application. You can create your own UI that interacts with this API as well. I'd want something set up so developers can pull code snippets from a repo managed by the community. Cartridge size does become a problem. High quality assets, videos, audio files: these all can consume a good deal of storage space and bandwidth. I still like the idea of capping cartridge size. As an alternative, it might be interesting instead to run the game on the server and stream the results to the client. If you're familiar with server-side Blazor, that's what I'm thinking about. If you say something like, "people will download the cartridge at home since they know they'll be playing it," I'd have to disagree. Think of some use cases: people meet on the trail or at an event and then want to do a cartridge, someone finds themselves somewhere with unexpected free time and might want to play, hotel WiFi in the US isn't really that great, something is published for an event, and so on. I'd like to be easy on people's metered cellular data plan. Game saves would be mirrored on both the device and the Wherigo Foundation server. Game saves can be deleted from the device when the game is deleted, but persisted on the server. A developer would be able to write a cartridge that can request a game save from another of the developer's games, then read it. This opens up the possibility of carrying over items and equipment from one cartridge to another. For example, while players can play my Chapter Two game without having played Chapter One, players who have played Chapter One will be able to carry over certain things they acquired from Chapter One, plus certain NPC states. This might make Chapter Two easier or more challenging, depending upon actions taken in Chapter One. Developers would have a good analytics suite. They'd have error logs, playthrough statistics, and so on. You wouldn't be able to track them to a specific user, but I do want developers to have more feedback from their games. I'm not sure Groundspeak is as money hungry as one might think. We all have to focus most of our time on what keeps the lights on and employees paid. But I'd expect a different behavior from a company interested in increasing revenue for the sake of profit. I do know some things learned from my volunteer side that I can't share publicly because I haven't heard it through non-private channels. Should the community and I pursue Wherigo v2, we too will need a way to generate revenue to pay for our expenses (relying on donations and individuals' contributions is not a stable plan). There will then be other parts of the community critical of our handling of funds. Creating Wherigo v2 will require a multi-year commitment from many different people. This is a large undertaking. Keeping a group of volunteers going though life's vicissitudes is its own challenge. Always keep in mind the barrier to entry. How much would someone have to learn to create a simple cartridge? Make this as low as possible. We create the tools, but it's the rest of the community that creates the content. The more tools we have that make it easier for people to create simple cartridges, the more users we will have. Several of those users would then try to learn how to make more complicated things. But it needs to be accessible to as many people as possible. Would lab caches have been as prolific had you had to create a Wherigo cartridge, even using Kit? I think not. (And if you think about it, the lab cache app acts like a perfect Wherigo player app: it lists the cartridges available, downloads the one you select, and runs it.) So, here are the steps we'd need to take: Define a feature set for Wherigo v2.0, v2.1, then shove everything else that would be a good idea for a future version. Choose three killer features that would draw interest to v2.0, then a couple simple to implement other features for v2.1. Put all the rest off until later. Even were we just recreating Wherigo v1.0, there would be a ton of things to do: player app API, player app, listing service, back end API, CDN, scoring mechanism, full website, overall brand theme, and so on. Knowing those features and having a vision for the future, decide on a technology platform. Will WASM give us what we need? Regardless, the player app and sandbox/engine itself be separated to the point where we could launch cartridges that use completely different engines. Decide on technologies for most of the features. For example, even if multiplayer won't be a v2.0 feature, you'll know later we'll be using some sort of pub/sub like RabbitMQ or SignalR. But when other features are considered together, that might guide our adoption of one thing over another. So it's important to know where we want to end up. Outline everything that needs to be done at a minimum prior to launch. Get commitment from people and know this will take a while because you're working with everyone's free time. Make sure people aren't working isolated and without feedback and encouragement. That's one thing the rest of the Wherigo community who can't contribute technically can really help: feedback and encouragement. Create the teams. Who is going to be responsible for what? Have redundancy. This isn't for just for software engineers. We need artists and testers. As long as we can keep going if someone has to drop out or go on a very long break, things are looking good. (Why, yes, I do place a high emphasis on continuity. If this is to succeed and stand any chance at being officially recognized, it has to survive volunteer churn. If I was Groundspeak, I'd demand the group demonstrate they can survive in the long term without dumping the responsibility back onto the company.) Everyone would need to recognize that everything they create is not private. For example, if you create the only player app, you can't make your GitHub repo private or take it down if you want to leave. Everyone is depending upon it. The team has access and you'll have to leave your work with the team if you leave. The repos themselves could be private amongst the team. Anyone on the team can make a pull request, but we'll leave it up to those in charge of that project to decide to merge or send it back. Always more than one person so the project can survive. (Sure, we can start with single people, but the entire project doesn't succeed until we have redundancy.) Find funding. Now that we know the technologies and features involved, we'll know what to look for when pricing tools and environments in Azure, AWS, or something else. We'll need at least a dev and prod environment, including rules for signing off on automated deployments. I'll commit to funding around $2K a year since I'm doing that already. But that likely won't fully cover all the dev and UAT environments necessary. And suppose I'm going on a caching trip and the airplane crashes. If we do this, we need to make sure it can survive if one source of funding dries up. Likewise, I don't want to be shouldering $10K a year or whatever in expenses as the only one keeping the lights on. That's the reason I came up with Wherigo Invaders. Work with everyone to come up with a minimum viable proof of concept: create a cartridge using script or code (a builder can come later, but it will need to come), upload this to a website, have an app contact the API to log in, search for it, download the cartridge, and launch it. When you enter the zone, have it display a hello world message. Well, that's all the time I have for a reply.

I tried making a deal with Groundspeak around 2014 or 2015. I'd review the partnership agreement within a day or two and send it back, then have to wait nine months for their side, despite my asking monthly where the agreement was. Then there was the passive-aggressive nature of not allowing cache descriptions to mention anything about any community-developed software. When I started moderating this forum, I was also supposed to check with Groundspeak about whether or not to allow discussion about community-developed software. After not hearing from Groundspeak after the first player app was released, I managed to get permission to be the arbiter of which software gets discussed in this forum--a privilege I'm not sure is granted to other moderators (and, doubtless, the current team at Groundspeak has changed and no one remembers I still have this privilege). And, finally, I was disturbed that the partnership agreement had wording that said that if I stepped away from Wherigo (without setting up continuity plans, I guess), it would be shuttered. And between the ton of overtime hours I was spending at work and the questionable nature of whether of not anything I put my time into with Wherigo could see the light of day, my intense involvement began to wane. I do have a plan B, but it's risky and I do not want to do it alone. I must have a lot of people helping in order to pull it off. Plan B is a hostile takeover. To put it simply, make awesome tools people want to use and then begin developing the Wherigo platform further, creating new features and capabilities. Oh, and hope that Groundspeak doesn't pull out a cease and desist. They'd always be welcome to help provide direction on features to add since it's originally their product, but I wouldn't tolerate having to wait, say, nine months for feedback. (That was one of the other things I wanted in the partnership agreement from before: if I have to get permission to do something, there should be a certain period of time in which it should be decided so I'm not waiting for a reply for too long.) Trying to go the Wherigo Foundation v2.0 route involves a massive amount of work (regardless a benevolent partnership or hostile takeover): - The site UI needs to be overhauled so it's responsive and modern. I would choose Blazor. - Mobile apps would need to be created, likely using .Net MAUI so I can share Blazor views. - An API underlying it all would need to be created and authentication would still need to go through the geocaching API. Microservices should likely be used, but I don't have much experience doing enterprise architecture with microservices, CQRS, and the like. - If we want to move Wherigo from lua to JavaScript, C#, or something else, we would need to decide at the outset. Player apps could have a backward compatibility mode. I'm more concerned about ease of development for the future. One strong point for lua is we can tightly control what it does because it must always do everything through the player app API. Were we to move it to C# or JavaScript, I'd be afraid a cartridge developer might use external API calls to do things they shouldn't. As long as we can guarantee still using lua would be fast enough for cartridges, I don't mind sticking with it. But we should make a decision as a team at the outset. - One feature people would want is the ability to embed video into cartridges. I'd need to set up a CDN so we can stream video to cartridges so the download is smaller. It might be that all assets are not required for an individual person's playthrough, but they can choose to play in offline mode, which would require all assets to be downloaded. If a cartridge uses multiplayer, the cartridge can't be offlined. - I wouldn't mind Urwigo being the official builder if we could port it to either the web or OS-agnostic code. A web-based builder app and emulator would be more accessible to people. - I would need to create an event system (likely run through RabbitMQ) to be able to give Wherigo multiplayer capabilities - We should create a Wherigo v2.0 spec ahead of time, outlining all new features and providing a roadmap. All application developers would need to be in on this and agree to it. I can't have it where I create multiplayer and the player app developers implement it and the builder and/or emulator developers don't or release it eight months behind schedule. - The cartridge download process needs to be streamlined, but this would be easy once an API is in place - Media assets and an overall themed art style would need to be chosen - An overall point scoring system should be created. I shared a complete idea with the Wherigo Foundation a while back. The point scoring is a combination of playing, building, and completing cartridges that haven't been completed in a while. The number of points you receive when playing (taking from the community) would begin to taper off until you build cartridges of your own (give back to the community). - Wherigo would need to be self-sufficient in its own funding. What I've been hosting comes to just under $2K a year or something (I'm not sure because I just pay the bills these days without looking at them). I can continue funding Wherigo up to about $5K a year, but I'd rather it generate revenue to fund itself. So unless anyone would have a better idea than Wherigo Invaders, then I'd need to implement that massive meta game. Any overage on revenue would be first held in reserve for group needs (software licenses, hardware for testing, etc.), then the overage would be split between the group and community. I would want the money aspect addressed ahead of time because it's one of the things that can cause a rift in groups, and I'm uninterested in having conflict in teams when altruism should instead be the rule of the day. So, that's what you're looking at and why I haven't tried again. It's a massive amount of work and would be more than just a little miracle to pull off with a group of volunteers. There are many different technical skills that would be necessary. If I could get together a group, I'd be willing to try one last time. I've said to Groundspeak before that Wherigo development isn't going to be the Ranger Fox show, it's a community effort. I'll organize it, lead it, and be one of the main engineers in the group, but it needs to be a group effort and have continuity plans in place in case someone has to drop out either for a time or permanently.

My motor vehicle is likely capable of going 185 kph (115 mph). By the same logic, we can infer that by having a motor vehicle capable of going at such speeds, I intend to drive at those speeds. Instead, we find I drive around the speed limit. Same goes for an electric scooter. On greenways, speed depends on the situation: the number of people on the greenway, the condition of the greenway, visibility, weather, and so on. If I say 28 kph (18 mph) is a nice speed, you might be in a place where your greenways are crowded and such a speed is too fast. On the other hand, I've been on few greenways that are on great condition (no roots growing underneath), wide, and vacant, at which I've gone at 56 kph (35 mph). It's all situational, based on safety at the moment. And you'd slow way, way down when approaching anyone, anyway. In some places in the world, it's legal to have micromobility vehicles on certain roads, especially in downtown urban areas. Having a capable electric scooter allows you to be in more situations and remain safe. Drivers in my area are impatient and sometimes idiots. If I have to park far away from a cache and need to ride on a vehicle road to get somewhere, I want to be able to go the speed limit or whatever is safe for the situation (whichever is less). Over the years, I've observed the situations that develop when motorists encounter someone on a moped (or another motorist) going a fair deal slower than the speed limit. People get impatient and an unsafe situation develops as traffic backs up, people try to change lanes, pass with limited sight, or attempt to pass in the same lane, leaving little distance between the car and moped. The point of having something that can go very fast is you can use such speed when the situation calls for it in order to remain safe and not be the cause of an unsafe situation.

Let's see if I have this right: you have some tables. You would like to remove a random item from each table, then you would like to show a random item from each table. I created this demo cartridge (hosted on my NAS). It contains one zone. When you start the cartridge, it will populate three tables (I'm not doing anything with the third). When you enter the only zone, a random value will be removed from two tables, a random value will be chosen among the items that remain in those two tables, and a message box will be shown with the results from the first table's operation. Dismissing the first message box will show a message box with the results from the second table's operation.

When I purchased the SSL certificate, it was supposed to be a wildcard for everything at wherigofoundation.com. However, I was unable to assign it to www, then I couldn't use it for Kit, so I had to buy a second one for Kit. (Yes, it was supposed to be a wildcard, not a single certificate.) Anyway, it looks like Azure (my web host) has added managed certificates, which are free. I wish I had known that right before I spent $300 on a new wildcard certificate that I didn't end up using and deleted about twenty minutes later. Oh, well. So... anyway... thanks to @tyrokofor asking about this because it gave me some incentive to fix it.

I've made extensive use of tables in my Cacher Pursuit cartridge. Look in its Init() function to see if that's of help to you. I have a table called allQuestionGroups in which I store a question group, which is a table itself of a table of objects (objects are nothing more than tables themselves). The last I knew, this cartridge compiled and worked in emulators and player apps. You can download the source code and look through it. The source is clean, hand-created, and practically everything is commented (because it's meant for people to learn from). All but one of my cartridges, Tetris, is open source. An excerpt from the cartridge, commented for this thread: --Defining a new table local allQuestionGroups = {} --Defining a question group table local qgroup = nil --Creating a question group table like an anonymous type. Note I'm also setting up a table called Questions inside. qgroup = { Zone = zoneCachingTerms, Category = "Caching Terms", Questions = {}, MaxAttempts = 5, Complete = not zoneCachingTerms.Active, WedgeMedia=zmediaWedge1, SuccessMessage = "Great! You earned a pie wedge!", IncorrectMessage = "That's incorrect. Try another question.", GameOverMessage = "Guess you need to get out a dictionary. Game Over.", GameOverMedia = zmediaGameOver } --Inserting the question group table into the main table that stores all question groups table.insert(allQuestionGroups, qgroup) --Creating a table like an anonymous type to insert into my question group table table.insert(qgroup.Questions, { Type = "MC", IsAsked = false, Question = "What event is normally held in April?", Options = { "CITO", "Geowoodstock", "Geobash"}, Answers = {"CITO"}, Media = nil }) --And again table.insert(qgroup.Questions, { Type = "OA", IsAsked = false, Question = "The geodetic discs fall under what category?", Answers = {"Benchmark", "Benchmarks"}, Media = nil }) In pseudocode, the structure would equate to this (omitting a few properties for brevity): List<QuestionGroup> allQuestionGroups; class QuestionGroup { List<Question> Questions; Zone Zone; string Category; int MaxAttempts; bool Complete; } class Question { string Type; bool IsAsked; string Question; }

I did a bike trail at the beginning of the year with an electric scooter. I thoroughly enjoyed doing that. I was able to go much farther from my car than otherwise. I didn't need to be aware of the time it would take me to get back since the scooter could do a max of 48kph (30mph) back. I kept that scooter in my car's trunk throughout the year. It proved useful for situations when I had to park farther away than I would like. I could just get the scooter out and be at the cache in no time. Parking 1-2km away isn't inconvenient anymore--and isn't far at all by scooter. And, finally, earlier this month, I was able to grab the scooter I wanted for about 45% off the retail price. This one, pictured, should max out at 100kph (62mph). I'm scared to take it that fast. The most I've done with it on a vehicle road to get to a cache is 84kph (52mph). I should really wear additional protection other than a bike helmet if I'm going to go that fast. I plan to bring both scooters with me to the Nov. 5th bike trail event GC8HMKG. I had hoped to find someone I can do the bike trails with, but no one replied to my note on the event page and six out of the seven people I contacted said they couldn't go. I'm waiting to see what that last person will say. (If anyone here wants to do those two bike trails with me, you can contact me. I'll let you ride the more sedate scooter. It's not like we'll be going that fast on the bike trails, anyway.) I've seen the rental scooters around in different cities I've visited. I haven't tried riding on one of those, so I don't know about their speed or acceleration. I'd figure due to liability reasons they wouldn't be able to go all that fast. But I don't know. I've found enough caches that I feel like I need to keep finding novel things to do to keep things interesting. This is novel enough that it'll take a couple years to wear out, then I'll need something else to do to freshen the experience. One of the other things I'm doing to keep caching fresh is to do challenging hikes to waterfalls. However, several waterfalls I've visited don't have caches, likely because the hikes to them are dangerous and difficult. And, yes, I know the last post on this thread was from two and a half years ago.

Seems fine to me: the coordinates don't pop up, but instead you just follow the cartridge to the final.

By the way, I was halfway tempted to create a cartridge where the entire point is to try to hack it. I decided against it, though, because it'd be teaching people the wrong thing.

Actually, if I come across a cartridge that is supposed to be difficult to hack, I'll derive more enjoyment from the hacking challenge than I would playing through it normally. I'll still try to play through it normally, but by then I'll just consider it a formality. I believe the best defense against hacking is crafting an experience that makes people want to play through it. Given a multi's final coordinates up front, what would decide whether I do the final or visit each stage is my expectation of the experience I'd have in doing it the normal way. Just this year, in fact, I had the coordinates to each stage in a multi. I didn't think much of the multi, so I went to the final stage first. I liked what I saw and was curious, so I went to the next to last stage and liked that, so ended up doing the entire cache in reverse because I enjoyed the stages and they weren't a pain to get to. This is what you want to happen with a cartridge you create: though someone hacked it, they saw the fun experience you laid out, so they play through it anyway and pick up the final cache whenever they're near to it. Make it be worth someone's time to play your cartridge. Time is a resource more precious than money. Make me be willing to pay you with my time for the experience you're offering. Give me a reason to find your cache, cartridge, virtual, or whatever compared to another one nearby. If you create a worthwhile experience most people enjoy, who cares if one or two people deprive themselves of that and just go to the final? At their point, it's their loss.

Hügh has the best explanation. The file you want to download is the GWZ. I gave the option of all three depending upon people's use case: - The lua/zip option will download a zip file. This is good if you want to import the cartridge into another builder and do other things to it. - The GWZ is what you want for uploading to the Wherigo website. Really, though, the GWZ file is just a zip file with its extension changed to GWZ. (It's not that uncommon. DOCX and XLSX are zip files as well.) - The GWC is a compiled cartridge, suitable if you're trying to export from Kit to a player app. I thought I offered a brief explanation on Kit with all these options.

I guess the reply to this never got posted. Just download the GWZ from the site and post it manually to the Wherigo.com site. The automatic posting thing is a little old. When I'm not working evenings or nights at my job, I'll look into this.

There are a couple things I do to determine whether to show the final zone. First, I test for the first zone point in the final zone, not the zone's original position. That's a little odd and I think I don't do that in my other arcade cartridges. You may have updated the zone's OriginalPoint, but perhaps not the Points array. Second, I test for the player app's name. Typically, emulators report "desktop" for their names, so testing for this prevented people from finding the final by playing this in an emulator (which was never a concern in my own area). Search for the comment text "If you are close enough, we will show the coordinates. If not, we will not bother." and you will see the check two lines below. You might not have commented this out. (In my other arcade cartridges, I relegate this to a function call that can be disabled or updated easily. After creating Whack-A-Lackey, I learned a LOT and made my other cartridges far easier to modify and update, now that I knew what I was doing. Whack-A-Lackey, by the way, was the second original cartridge I created, though I had been helping others with their cartridges prior to that.)

I haven't had problems with people looking through log files. Usually, they just load the cartridge onto their phones and don't know how to access the log files it produces. I believe the easiest thing to do is just have a zone called "geocache" or "final" that you move upon the cartridge's completion. Speaking from my own experience at hacking cartridges (I can see the source code), if I see a zone labeled that, I don't even look at the rest of the cartridge's code to see if it's doing anything. If I get it wrong, I just play the cartridge in the field (I usually play them, but I like having the coordinates ahead of time so I can sign the log if wander close while playing the cartridge--or in case something happens). So, in my opinion, just moving a zone called that is enough to deter. If you would like an unhackable cartridge, have the player's answers determine the coordinates for the final. For example, if a player enters "4" for how many benches are in an area, don't validate that, but instead use the number four in assembling the final zone's coordinates. If the player got it wrong, they'd be taken to the wrong place. You could also just use the cartridge to show the player what numbers to find and let the player assemble the final coordinates manually. In the end, though, just mild deterrence is enough. You want to encourage people to play your cartridge instead of do a lab cache. Don't make it too difficult or complicated for them and don't take too much of their time. And you can do nothing to deter the most effective means at hacking a cartridge: people talking and and sharing the final's coordinates.

The 2015 copyright was part of the footer I was given by Groundspeak, during talks at about that time. The preview site part, too. I could change it. I haven't been actively developing the site for a while because its development tired me, the maybe/maybe not talks with Groundspeak were running me down, and the years-long deluge of excessive unpaid overtime at work was exhausting me. But above all, it was the uncertainty of whether I should continue putting my time into something that might not see the light of day. I could improve the footer's text. That's easy to do. What I really should do, though, is recreate the site so it's mobile-first (responsive) and has a far better look and feel. I could do that, but at the cost of a ton of my personal time. Is it worth it? Since I'm not so sure, I'm hesitating. I could sink a lot of my personal time into the site, improving and extending Kit, and creating a new cartridge management and builder integration service. Would it be worth it, though? Reviewers would still be advised not to publish cartridges that mention anything to do with the Wherigo Foundation, Urwigo, Earwigo, etc. The only official place to host cartridges is Wherigo.com. Even after spending all that time improving the site and services, that'll still be the only official place.

Most people sign with ink because it tends to last longer than pencil. I have seen many cache logs and occasionally see that someone wrote with a pencil. You are fine. Also, since you are new, it is unlikely you will be caught up in whatever rivalries or pettiness might be in your area, if any is. No one will erase your name on the log. Your signature might rub off over time, but that's all. Continue to enjoy the game.

You'll have to contact Groundspeak directly about this. I don't have access to their site.

So, for now, we've concluded the Minnesota one is likely the first time this has been seen as a challenge cache. The certainty isn't too high, but it's what we have. Since I moderate and don't review, I was unaware these challenges were not allowed anymore. I'd better make sure I take good care of mine, then, since another one can't be created. And I can understand how this might turn into a competition. Being at the negative end of a rather nasty area competition for many years, I still don't like being dragged into something. I also guess that means one of my mystery caches would no longer be allowed. I placed one of three locks on an ammo can, with the other two located within. The clues one must gather differ based on which lock is on the final at the time. The whole point was an experiment to see if I could come up with a way where others' progress could affect those who came after. Fortunately, I hadn't heard of anything negative resulting from it. Well, if anyone hears or knows of a cache older than the Minnesota one, do be sure to add it here. I think it's fascinating to trace and document the origins of things in this activity. Even almost twenty years after the concept was first created, we can't quite point definitively to its origin. Imagine the trouble that will be faced by those in the future, perhaps those putting together as much history as remains for a fifty year anniversary.

I recently came across a wiki article that cited the first Lonely Cache Challenge as being placed in Kansas in August 2011 (GC32RV2). That's incorrect because that cache cited GC2NC0K, placed in April 2011. That person's profile says they're from my general area, where I created one in August 2009 (GC1X3KG). So, that got me thinking: what was the first Lonely Cache Challenge? After all, we attribute the Fizzy (Well-Rounded Cacher) Challenge to Kealia's creating it in honor of FizzyMagic, so what of origins of this challenge? Looking on the forum, I saw this post and this one from 2004, mentioning Quest Master's Lonely Cache Challenge (where the term was also "dust-offs", and I found the term "resuscitator cache"). He has an empty bookmark list, linked to from a 2007 post, but no challenge cache under that account. The account Lep, mentioned in this post, doesn't have any caches on that account. After that, the forum posts go past when I created my challenge cache, so by that time at least one existed. So, forum, we know the term existed since at least 2004. As the general community has far more time than I, please take my research and figure it out. I'm curious and historians will thank you.

Please access Kit from https://kit.wherigofoundation.com/

Oh, boy. Groundspeak's Builder's embedded browser plugin might need to be updated, then. Well, when I can get some free time, I guess I'll have to decompile it and see if I can fix things. It'll take a while before I have that amount of free time.

That's correct. All but one of my cartridges, Tetris, is open source and you can download the source code from Wherigo.com in the manner Hügh said. Do be aware that my arcade-type cartridges don't have much to show in any builder app. Almost the entirety of the games' logic is within the author script section. Whack-A-Lackey's code is a little messier than I'd like because it was the first of such a type of cartridge, therefore an experiment. I did much better with Battleship and far, far better with Cacher Pursuit. Part of that was because I knew what I was doing by then (ha, ha) and the other part was because I knew I'd release the source code to the community, so wanted it in such a condition where it was easy for community members to learn from what I did and make adjustments to how the game works (all variables and text the games use are provided at the top of author script, with explanations about what each does). Anyway, when you download the GWZ, you can rename it to ZIP, unzip it, and then you can see the lua file. If you open it in a text editor and search for the text "author functions", you'll find a good starting point. About a hundred lines down, you'll see a lot of equals signs to call your attention to something. That's where a lot of the things you can change start off. Perhaps one day I should rewrite Whack-A-Lackey so it's far easier to modify. (At the moment, my time is taken up in setting up a demo microservice project for work, so that'll take a while.)