Ranger Fox

@Mangatome Then from your perspective, we have not yet reached the limit of what we can do with lua if done correctly. What will need to be done is the following: The player app should be able to run one version of lua for all v1 cartridges (retaining compatibility, such as it is). We will run all v2 cartridges in the latest version of lua. When the player app requests a cartridge from the Wherigo API, the player app's current lua version will be included in the request. The Wherigo API is responsible for compiling a cartridge with the requested lua version. As long as the Wherigo API is updated prior to releasing an updated version of the app with a newer lua runtime environment, things will work as expected. In this manner, we can also deal with old versions of the app. (The Wherigo API reserves the right to tell the app when it is too old and must be upgraded.) Updates to the player app could include updates to either the lua environment or player app API. Because of this, once we expose an endpoint to a cartridge, it is fixed in stone and cannot be changed. I know how to version web-based APIs, but have not yet put time into determining how to version the player API. (In other words, we need to guarantee cartridges built in 2024 will still be able to run when the year is 2030--or even cartridges created in 2026 using a 2024 version of Urwigo.) I imagine we could just have an interface per player API version, which when upgraded will simply chain call into the newer method. As mentioned above, the Wherigo API's compiler service would need to load the compiler appropriate for the request. (I'll likely store a compiled cartridge when requested for the first time, then skip the compiling step during subsequent requests.) We will need to have living documentation that covers the player app's specification: lua versions, required libraries, and the player API (not only the part that allows interaction with the UI, but also that allows the subset of network features we desire). I would like cartridge state to be kept separate from the lua version if at all possible. I want to work on a more robust state management API. Other thoughts: I certainly don't mind exploring a version of player app that will allow cartridges to be written in C#. You definitely know player apps better than I: how difficult would it be to construct interfaces for the player app such that we could easily drop in different types of cartridges? Even if we stay with lua, that's my intent to preserve compatibility with v1 cartridges while continuing to update lua for v2 (unless we decide each cartridge's manifest can tell the player app the lua version against which it's supposed to run). My first priority is to everyone's security. I still would like to allow authors the ability to use network resources, so how about this idea? When an author wishes to use network resources, their cartridge can undergo review. Once approved, that particular URL scheme will be whitelisted for that cartridge. When a player app downloads a cartridge, it can also download the URL whitelist. The player API will expose a network layer whereby it will only allow whitelisted URLs to be called. In this way, we maintain security while at the same time giving authors the ability to consume network resources. As for in what the player app will be coded, I must leave that up those who will volunteer for the player app. My preference is for the environment to be something in which most people are familiar. That way, when some volunteers have to step away for a while, other people can take up the responsibility with not as much of a learning curve. My preference is MAUI or Blazor Hybrid. I know Groundspeak seems to like React Native (their Adventure Labs app is built using that), but Wherigo v2 is not going to be a Groundspeak project (though I still want Groundspeak's backing). For developing all this, I'll want public GitHub repos with a couple project leads (always more than one since we're all volunteers) set up to review and merge pull requests into the trunk. Anyone in the community can make a pull request. Whether we want these repos initially private is still a good question. I'm glad we're not all jumping into coding this. And some public news: I attended a mega event last weekend, and Jeremy from Groundspeak was there. We'll set up a time to talk with each other and see if I can get Groundspeak to agree to let the Wherigo Foundation run Wherigo if we can deliver.

The reverse Wherigos are like the geocaching equivalent of light poles, traffic signs, and guard rails. I would rather not interfere with what cartridge authors submit so long as the cartridge does not involve content inappropriate for children or anything copyrighted that might get us as a content-hosting service in trouble with the copyright owners. Instead, I would like to let the scoring and other systems encourage usage. Reverse Wherigo cartridges might be worth fewer points if people consistently find them--and since the person putting out the geocache doesn't own the listing or is a contributor, they won't receive any points within the Wherigo scoring system. And since the reverse Wherigo cartridge won't be listed multiple times within the Wherigo cartridge listing service, it won't be a target for the Wherigo Invaders metagame, further decreasing the likelihood someone on the Wherigo side would want to implement something. In the future, you might want to worry about cartridges with only one zone. This might slightly skew the numbers. I'm hoping that by their being completed quickly and easily, they'll likely consistently be worth less points in the scoring system. (If you haven't read that post, please do.) Perhaps by also implementing a kudos, favorite, or other feedback system, authors of more popular yet less-completed cartridges will also receive a larger point kickback from completions in the long run than someone who created a park and grab equivalent. (Don't forget that, unlike geocaching, the Wherigo v2 scoring system will not equate one completion with one point.) I suggest you contribute in the scoring system topic some ideas that will encourage the activities you (as a community member) wish to encourage. I will eventually have to turn the scoring system into a mathematical formula. And I hope that not all of Wherigo's user base will overlap with geocachers. We need a user base of our own. That's where we might run into one-zone cartridges.

Yes, about the player app... What is the consensus about this? Are the player's stability problems related to: The player's implementation The API a cartridge uses to communicate with the player How some cartridges are built The use of lua for cartridges I don't mind switching cartridges to being built using some sort of WASM or just straight C#, supposing we can prevent authors from using networking features that would compromise users' security and privacy. While there are many wondrous things people can do if you gave them unrestricted network access, there are likewise a lot of things you wouldn't want them doing. I don't mind creating a cross-compiler so lua-written cartridges could be translated into some sort of other code that's faster and more stable. However, something like that is outside my current capabilities. Anyway, the current question is whether we wish to remain with lua or switch to a different language. As long as we can guarantee stability, I don't mind remaining with lua unless there's a more compelling reason. (If cartridges could run on a Pocket PC in 2008, I don't see any reason they shouldn't be performant on 2023 hardware.)

I'm not as familiar with the Android players, but there was recently a thread where someone was asking similar questions. Since your question was vague, I can't give you a specific answer. I don't know if you can't download the cartridge at all, don't know where it's downloaded to, are downloading it and are pointing the app to the right location, have given the app the ability to read from the right location, etc. Try the thread below to see if its solution works for you. If not, I suggest you post there a question that specifically details what you're seeing and trying to do.

Check the usual stuff: Make sure you're not using HTML in your description. This is likely about 95% of the problems right there. (And if you're just using the "<" and ">" characters, try going without them.) Make sure the cartridge file is under 20MB Just in case, use the online compiler service on the site to make sure it'll compile your cartridge About the only place you can get Wherigo support is this forum. Groundspeak redirects everyone here. Everyone in this forum is nice and helpful, and I'm proud of this community.

... ... ... I'm being ignored? Jokes aside, I look at it this way: people have a certain amount of temporal capital and invest it in ways they believe will provide the desired returns on such an investment. If you're looking for adventure, there may still be competing caches which advertise to provide that should you spend your temporal capital on them. A Wherigo author would need to be able to compete with those caches, advertising on their listing page about the enjoyment the experience will give. If you're looking for numbers, I guess there could be a series of reverse ones? In the end, Wherigo shouldn't always have to compete with geocaching. I don't mind sharing a portion of the user base with geocaching, but Wherigo does need to have its own distinct user base. To do that, we need good tooling for authors, help articles and tutorials for authors, an easy experience locating and downloading cartridges for users, compelling and interesting author-created content, cartridges working flawlessly in the player app, and an engaging scoring system (and perhaps the Invaders meta game would help with engagement). Once it no longer becomes possible for geocachers to download the cartridge files, that'll cut down on a good deal of coordinate acquisition. The reverse Wherigo solver websites would still contribute to a significant amount of coordinate leaks, but that has become the Wherigo equivalent of a park and grab, so if that's what the author wants, that's fine. And we'll always have geocachers sharing final coordinates. We shouldn't be too concerned with the geocacher side of things beyond this if we're aiming for an audience all our own. At this stage, feedback and ideas would be very helpful. Later on, volunteer for something based on your skills. Not everything will be programming. You could test, contribute artwork, create some ideas for demonstration cartridges, make some tutorials, give feedback on feature ideas and UI designs, make videos, and so on. Everyone should be able to find some way to contribute because everyone has a different set of skills and experience. And since everyone is volunteering their time (back to temporal capital), it's both appreciated and needed. We'll work at whatever pace we can afford. Even as little as one hour a week will still push things towards completion. Keep a watch for any topics labeled "Wherigo v2". Not everything discussed will be in this one thread.

Just thinking aloud on this, but if the player app and cartridges ran in WebAssembly, we'd be able to do everything on a website without need of an app. When I was playing around with a preview of Blazor three years ago (practically to the day, based on some of the files' timestamps), I messed with making a web-based player and a player API I could then call into for cartridge events. It was more for me to play around with than anything else. I was trying to see how close to the current format I could come. I did manage to make something I could play with, complete with a map, zones, events, dialogs, and inputs. It's not much and I doubt it works with the production version of Blazor, but you can poke around in it. The Overlook zone is where I played around with different inputs and introduced a dialog that played a video from YouTube. You can pick up the source code from here until I remove it: https://www.wherigofoundation.com/temp/Wherigo_Player_Next_20200130.zip Had I intended at that time to create Wherigo v2 or even make a production player and API, it would have been a lot different. I was just playing around a couple nights to see what was possible, then moved on since I needed to use my after-work hours for work-related things (yes, it was during that job that took over much of my non-work life for a few years).

Completion codes were added because there wasn't a way for the player device to connect to the website since Wherigo was created in the pre-app days. Any contempory development on Wherigo would involve APIs. Thus, the app would download the cartridge, you'd play it through, and the moment the cartridge declares itself as complete, the app sends the completion information through the API and the cartridge is marked as complete. Because of this, an author would not have trouble knowing who actually completed the cartridge. The trouble instead comes from when a group of individuals try to complete a cartridge together and only one or two of them are using the app while the rest are following. The geocaching approach is everyone gets credit. The Adventure Labs approach is only those going through the lab stages in their app gets credit. Wherigo will likely follow the latter unless the player app allows everyone in the group to register that they're playing an individual cartridge, which might be an interesting feature. I should probably start organizing people so we can begin working on the listing site. Cartridge features aside, we're still going to need an API and updated listing service site. I've been balking at this because I know I'll need to do this with microservices and I still have very little professional experience in architecting a microservice architecture. Those times I thought I was coming into a business that used recent technologies, I found out they were behind the times. At least the listing site seems like it might be easy, with microservices covering: cartridge listing, logs/feedback, completion/bounties, user data, user permissions, and authentication. Then send events via a bus like RabbitMQ. That would solve one use case I've seen in geocaching: a user writes a found log, the logging service handles it, the logging service raises a LogCreated event, the geocache service hears of it and updates its log summary count, and the user data service also hears of it and updates the user's find count if applicable. But I'm not up on the whole dynamically bringing up additional microservice processes with their own databases restored from the event source type of thing. Perhaps for now, each type of microservice can connect to a database shared with all the same type of microservice. But, still, no database transactions if I'm to provide as much performance as possible. I'll need to create a public GitHub repo, create projects for the different services, and stub out a lot of the methods. People can then contribute. Yeah, funding will be important. I'm just dreading the increased bill I'll have for this. Oh, well, as long as people are having fun. Regardless what happens, I'm not budging on my strict anti-ad stance.

Yes, owners will have a kickback on the bounty collected. Perhaps the kickback percentage will also be influenced by the number of favorites/kudos/applause/thumbs up a cartridge has received over the last three months and cumulatively. Thus, if you do a good job and keep raking in applause from the players for a job well done, you should keep reaping the rewards. I'm aware people can game any system to their advantage, so I'm not going to try too hard to prevent creative individuals. Their local community will handle them through social behavioral feedback. (Then again, there are geocachers who time and again do divide and conquer to find more caches. The community says they don't like this behavior, but they keep on doing it. So the point is we can't stop all behavior, but the scoring system should at least demonstrate to all players what we're encouraging.) Last year, I hid a cache that wowed the local community. They enjoyed it. I guess I got several favorite points for it (I haven't checked). It was an adventurous one in the heart of the area. But since it was a multi, no one else has attempted it after the area's who's who list of cachers has found it. I'm thinking of that as an example for the scoring system: a good experience and applauded by the major players, so get a kickback and increase the bounty to incentivize other players to try it when the bounty gets to be too big to ignore. One strategy players can have is to wait for a bounty to increase, but complete it before someone else snipes the bounty from them (or at least right after the sniper on the same day since everyone who completes a cartridge on the same day gets the same bounty). I want the bounty system to encourage some good behaviors while also being a fun and entertaining part of the game. People might tell tales of cartridges they completed right up to the completion trigger and stopped in order to wait for that bounty to increase. Over days or weeks, they waited and even spent an authority or two to help the bounty grow. Then someone came in and sniped the bounty from them, completing the cartridge right before midnight! Oh, no! You shouldn't have waited that long! Well, they then waited and used a few more authorities to help the bounty increase. However, that same person who sniped the cartridge before spent an authority to allow them to complete the cartridge a second time, sniping the bounty yet again! The horror! Then the sniper later used another authority to reduce the bounty down to one yet again! Will that sniping person ever leave the other player alone? The player and sniper laugh, the player pats the sniper on the back, and they continue to enjoy the Wherigo event, sharing other tales of their experiences to those gathered. Sounds like fun. It would be nice to bring that joy to people.

1) Once you complete a cartridge, you're welcome to return and adjust the agents deployed to the cartridge. However, you can usually only make up to five roster changes every play period (month). The player app and the Wherigo Invaders API would verify the player has completed the cartridge prior to processing the agent change, though we could allow perhaps one or two roster changes without having completed the cartridge. 2) Yes, game balancing will be important as well as keeping it fresh and occasionally implementing new concepts. If the meta game is interesting and worthwhile in its own right, we shouldn't be lacking in people willing to support it.

Perhaps we could use something analogous to the geocaching favorite system? After a certain number of completions, a player gains some applause points that can be used to apply to cartridges. Applause points also function in the same way as the author completing cartridges, resetting the counter that eventually kicks off the decreased point modifier. The decreased point modifier worked off this assumption: authors can improve by experiencing what else is out there, both others cartridges and what it's like to play cartridges. Likewise, encouraging players to create cartridges gives them a better understanding of the process and they can perhaps share ideas from cartridges they've come across. Since it's possible to form a small group to create a cartridge and everyone gets credit, it's not as exacting a price to exact. As maps become more populated with cartridges, perhaps we can let up on the counter that leads to the modifier being applied. We don't have to use the modifier idea, but I would like something in place that encourages people to create and play, even a little, the side they don't frequently do. I think the experience would be good for them. To put it in perspective, perhaps I can thing of WVTim. He put out a lot of good gadget caches. I would want to incentivize him to put out more. Applying favorite points to caches would prevent that modifier from ever going into effect, keeping him placing and reaping the rewards. But those who continue to place park and grabs that aren't appreciated as much by the community should have an incentive to go out and find something. Perhaps they'll come across a gadget cache and get an idea about placing something to which the community will give favorite points. And someone like me who constantly finds caches should be encouraged to place something at least once a year. I could even help someone make and place a gadget cache since I don't have a workshop and woodworking tools of my own.

Wherigo Invaders is a meta game played across cartridges. I developed the idea during the time of the Wherigo Foundation and have made some tweaks over the years. You should recognize bits and pieces of various other games within Invaders. Try to spot the influences. I will try to be brief with this so everyone can get the gist of the game. The Overview: You're part of one of three factions (invaders, defenders, or rogues--the names are arbitrary and can be whatever). Gameplay consists of completing missions (cartridges), deploying agents, and using authorities. Your goal is to undertake missions at certain locations (Wherigo cartridges) and either infiltrate or protect these target locations from the other factions. You do this by assigning your agents to these locations. Those completing these missions can make up to a certain number of modifications to the agents deployed to these locations (the cartridges), either removing some (by force if necessary) or assigning more. At the end of the month (or other period), a tally is taken of all locations (cartridges) to determine which faction and family's agents dominate the most locations. Completed missions also factor into this tally. The Details: When you first join, you can pick a faction: invaders, defenders, or rogues. Each faction has a strength and weakness, played like rock-paper-scissors to each other. I have not decided what these are. Once you join a faction, only an authority will allow you to switch sides. Choose carefully. Cartridges Your goal is to complete missions (Wherigo cartridges), collect the bounty, and recruit agents (these are game pieces). Agents can invade cartridges (hence the name, by the way, though these days I could just say you can deploy agents to cartridges). You can also take agents deployed to a cartridge. Let's say you can take or deploy up to three to five agents per completed cartridge per month (without an authority). If you are part of the defender faction, you can choose to move some rogues from a cartridge into your inventory. However, when the end of the month comes, you will be heavily penalized for all agents not of your faction in your inventory. So you need to strategize about deployments. Families Every month, you can join a family (team) of up to ten people. A family works together to deploy as many of their own agents into as many different cartridges as possible. At the end of the month, families will receive a score based on the number of cartridges they dominate and cartridges they complete (weighted against difficulty of completion). The more people of different factions completing a cartridge, the more difficult it's judged to control that cartridge, so the more that cartridge will be weighted in the scoring. The global factions also receive a score. Prizes are awarded based on these scores and the difficulty level. I don't mind families consisting of different factions, with the reasoning that people from different factions must at some point work together to accomplish a goal. Perhaps I could give a 1% point bonus to same-faction families. Agents Agents have their own abilities and stats. I'm thinking that if you want to remove a non-allied faction's agent from a cartridge, you need to deploy agents with enough stats to fight against the non-allied agent. Allied agents can be removed from a cartridge without a fight. A particular agent might have high attack, poor physical defense, and no manna defense. Another one might gain a 20% defense boost if two allied agents exist within the same cartridge. Unseating some agents might require a family's help. Agents deployed to a cartridge slowly recover HP while agents in your inventory recover at a greater rate. You could use an authority to affect recovery rates. At the end of every month, all agents with less than 50% HP will be recalled to their owners' inventory for recovery (so we don't have agents sitting for months or years in the same cartridge). As part of making revenue so Wherigo can pay for itself, you'd be able to purchase some blank agent templates (with stats preassigned and not modifiable) and add your own icons and names to the agents, then distribute them (or sell them) to the player base. Members of the Wherigo Foundation will have their own themed agents to give to people they meet at events. Authorities When you complete a cartridge, you have a 20% chance of gaining an authority. When someone completes a cartridge you authored, you have a 5% chance. An authority is presented like a virtual card. Like card games, you have common, uncommon, rare, ultra-rare, extremely rare, and legendary rarity, with the rarer cards offering better perks. Some authorities allow you to prevent an agent from being removed from a cartridge for the month. Others will allow you to recall one of your agents without visiting the cartridge. Other authorities can allow you to complete a completed cartridge again, reaping the bounty. Or you can operate at a 50% bounty handicap this month to gain 25% greater bounties next month. You could lock a cartridge down to one faction's agents for a period of days or prevent such a thing from happening to a cartridge or all cartridges you've created. You could use an authority to freeze a cartridge's bounty for a week, reset it back to one point, or to its maximum value in the last thirty days. You could choose to betray a family member and steal the points they gained that day--or double-cross someone who does that to you. You could fast heal one of your owned agents at the permanent cost of 5% of its max HP or DEF. An authority could even let you change sides. Authorities spice things up. Random Threats At times, a threat invades a location (cartridge). It is neither invader, defender, or rogue. A threat acts as a plague (entropy), slowly infecting other cartridges, decreasing the bounties for both players and authors. That cartridge no one ever seems to play that has that upcoming six month bounty bonus you've been planning for might become infected and have its bounty quickly drained to zero, dashing your plans. Clearly, you'll want to defend against the plague, so you should deploy some of your agents to guard against the threat. The plague will still try to invade, eroding the agents' HP over time. A rival faction might also choose that time to invade, taking advantage of your faction's agents' reduced capacity, kicking them out and instilling their own agents, perhaps with an authority to protect them. The easiest way to eradicate the plague (entropy) is by completing cartridges. The other alternative is to deploy agents to fight against it, and last alternative is to use a rare authority to stave it off. And who knows? Perhaps a different kind of threat is introduced each quarter. We could have some pirates trying to invade your cartridges in the spring; the summer could see an invasion from the vulpine army, with rabbit-themed agents getting insta-killed (an Easter egg); the fall could culminate with the zombie apocalypse (an extra bonus bounty applied to horror-themed cartridges and a significant boost to the creators' kickbacks); and winter could have the invasion of the naughty elves. Anything to keep the meta game fresh, add a bit of spice, and keep people coming back. The Goals There are several goals behind Wherigo Invaders: 1) provide a meta game with the primary goal being the completion of cartridges (Invaders would need to be toned down if it distracts from the completion of cartridges, or tweaked until it performs this function); 2) have this meta game easy to understand at first, but extremely nuanced and full of ways to plan a strategy; 3) keep people playing Wherigo even if there aren't any new cartridges in the area; 4) generate some revenue by selling chances to recruit rare agents or acquire rare authorities (note "chance"; it'll operate like a gacha game). (The revenue will, of course, go towards the Wherigo Foundation's expenses, commissioning artists for the game's artwork, back to the community to sponsor events or give out physical swag, and--if we make enough--we can divide it between Groundspeak and the Wherigo Foundation's active members in whatever way is fair as a thank you.) The Inspirations Did you catch them all? We have agents deployed in cartridges like travel bugs in geocaches. Adding your own artwork to agents is akin to icons with geocoins. We have three global factions like in Ingress. The cartridge's scoring system to incentivize rarely-played cartridges came from terracaching circa 2006, I think. Authorities are cards from any type of card-playing game you can think of (and we will oh so definitely have an authority called "The Death of My Conscience" because I like that name from Vampire: The Eternal Struggle, which I played for a couple months more than two decades ago). Families and the one month game period with possible missions is like clan wars with Munzee. The cartridge-completion chance of getting an authority or agent is like pulls from a gacha game of your choice. The plague doesn't have any inspiration other than as a mechanism to prevent against lonely cartridges, which is why I also call it entropy. The scoring kickbacks are from Munzee cap-ons. And that is Wherigo Invaders, the mysterious idea alluded to over the years by your favorite vulpine moderator. Was it worth the anticipation to learn? I'm aware that dumping the entire idea, complexities and all, might be a bit overwhelming. However, introducing the Invaders meta game to players will start off nice and easy, then we'll add more concepts and strategies every other month or so, tweaking modifiers as we go along to balance out the game.

Wherigo scoring will work more like a game than geocaching's one find, one point system. The scoring system will encourage the behavior we wish of Wherigo's player base. That said, these are the goals the scoring system will attempt to accomplish: Decrease the number of cartridges that are unplayed for long periods of time (in geocaching terms, decrease the number of lonely caches on the playing field) Encourage giving back to the community through cartridge creation Make sure those creating cartridges also experience playing them Encourage quality over quantity for cartridges We will accomplish the above by implementing scoring in this fashion: The bounty collected from completing cartridges is based on a cartridge's activity. A cartridge will start off with a first clear bonus. This bonus will be rewarded to everyone who completes a cartridge during the first day the cartridge is completed. After that, the completion bounty will decline over the next seven days until it hits the minimum level of one point. After that, every couple days a cartridge is not completed, another point will be added to its bounty. A full month will add an additional, yet low, bonus. A half year will add a noticeable bonus and a full year a substantial bonus. Everyone who completes the cartridge on the same day will receive the same bounty. Cards gained from Wherigo Invaders can be used to alter the bounty, even allowing someone to complete the cartridge a second time. Invader faction dominance and a change in which faction dominates the cartridge can also affect the bounty and additional completion rules. As time goes by and you accumulate more points from completing cartridges, you'll eventually develop a negative modifier. At first, you'll only be able to collect 95% of a bounty, but the amount you'll be able to collect will slowly decrease. That's because you're taking from the community without giving something back. It'll stop at 10%, though. To remove this modifier, you'll need to create a cartridge, either alone or with others. If you keep creating cartridges but don't play any, you'll also develop the same type of modifier. You'll gain fewer points from the bounty kickback you receive from your cartridges until this goes to about 10%. You can remove this modifier by completing some cartridges, gaining experience from playing what others have created. I'm still considering how I can encourage quality over quantity. Perhaps I can give players a rare resource to apply to cartridges they like. The more of this rare resource a cartridge collects, something happens. The cartridge's authors at least receive bonuses, but I'm still uncertain about the players. I need some way to encourage rewarding for good cartridges and not stockpiling resources on shoddy cartridges or just because someone is a friend. If I apply the scarcity factor, perhaps that'll help. I should also note first-time cartridge completions receive random Wherigo Invaders cards and perhaps the ability to draw for an agent. That or a completion has a 20% chance for a card and you can spend points in the shop. Spending points won't decrease your score. Instead, your score is the sum total of spent and unspent points. For example, someone's public score might be 10,000 points. The person might have spent 8,000 points in the shop and be saving the remaining 2,000 unallocated points for a spree later--likely for the next round of Invaders agents or an authority draw. I have yet to come up with a mathematical formula for the scoring mechanism. The above is what I envision. This is the starting point. The community will review the idea and we'll shape it. Once we're all satisfied, we can come up with the math. (I didn't have too much time to type things up since I had two posts to write, so I didn't go into details. This, though, should be a good start for discussion for what we'd envision for a fun scoring system for Wherigo.)

You are aware that makes you a great person to provide feedback and test things? There are times when someone like you needs to step in and say, "you software engineers might think this is really neat technically, but it's either a stupid idea or just confusing to anyone who isn't a software engineer." Your perspective into what would help you make more and be able to maintain the cartridges you have is important and needed.

I believe you're touching on the underlying problem with zone enter/proximity without actually correctly identifying the it. You're observing that a player tends to drift in and out of a zone, so you're trying to keep the player inside it. I believe the underlying problem is the player stops walking when the cartridge displays something to the player, and this means the player is typically on the edge of the proximity/enter boundary, so the GPS position drift will eventually cause fluctuations between the player being inside and outside this boundary. Such a thing could be resolved by a player app taking a look at the estimated position error (EPE--even this value will fluctuate). A zone's proximity and entrance events would fire at the author-intended distance, but their opposites--distant and exit--should be fired at their distance plus one and a half times the EPE. Let's take a zone that is 10 meters square, has an entrance event, and the EPE is usually 5 meters. The player will typically stop on the zone's border. As long as the player doesn't wander 7.5 meters away from the zone's border, the player is still considered within the zone. They're still hosted and available. I made a second version of Kit, but it fizzled out once I had to build the rest of the website around the builder. I spent so much time on the builder part that I tired myself out and didn't complete the rest. I could do the programming, but the UI design work just made me tired. This is going to be a common theme. I program at work, so doing the same thing at night albeit on a different project tends to get tiring unless I can balance the programming thing out with some other activity. My other activities--geocaching, photography, travel, and riding that high-powered electric scooter--usually take a good chunk of time. I should take up locksport or something (I do have several picks and practice locks, by the way). Anyway, the way I see it, technology has moved on since I first created the Wherigo Foundation and Kit sites. The WF site needs to be separated into a responsive front end atop the Wherigo API. The Wherigo API needs to be split into the listing service and player app event system (things that can allow multiplayer and other player app features). Then there's the Wherigo Invaders meta game that ties cartridges together. I don't have much of a background with microservices, but it's possibly the Wherigo API might need to sit atop microservice land to allow us to expand the system with increased load. And if I use microservices, then I'd probably need some sort of event system so I can bring new services up. The more I consider a truly enterprise architecture, the more I get tired thinking about how much work that would entail for me to do--and why I shouldn't do it alone. As for the front end, I can choose between React, Angular, or Blazor. I like the idea of WebAssembly and it seems the industry is trending in that direction, so I'd probably go that way. I'd need to build for mobile first, desktop second. But since it's a gaming site, as @Forest-Ghost pointed out, you'd likely expect a fancy UI with a ton of animations--and something really high class like that is a little beyond me. I can go deep and learn only so many things with my time without giving up all my hobbies. Wow, @charlenni, it has been a while! So, about the environment. I still think Kit was the right approach: come up with some typical cartridge scenarios and build a UI that allows the average person to create something without having to touch code or know code is being generated. Let's take my Battleship cartridge for example because that's a rather complicated one. You could create a kit that would produce a battleship cartridge: give the user a way to define their battleships, adjust text that's shown in the cartridge, and upload images to use. An author doesn't even have to know code is being written. Likewise, you could mimic all of Adventure Labs by having a kit (UI) that looks 100% exactly like the current labs UI, then output a cartridge's code as a result. We can then have Urwigo able to import these canned cartridges if someone wants to edit them further or create something completely different. At the end of the day, the measure of success is how easy, rewarding, and entertaining it is for someone to author a cartridge. Someone of low skill level should have tools for them and someone of high skill level could seek the advanced tools. Prior to developing anything (but after the requirements phase), we'd need to come up with an architectural plan. If I can somehow swing microservices (light old Java joke), I can have an environment where multiple languages can be used. My only concern about that is in retaining enough talent on the team that we have skill overlap. Since this will be a team of volunteers working for the greater good, it won't matter which time zone you're in. Everyone can work at their own speed, contribute what they can, and help where they can and would like. For a project like this, for those who can't program, I'd need them either designing or keeping the specification and answering the programmers' questions about what Wherigo is supposed to act like to the users, or coordinate across teams. Well, first, I'd need someone to keep track of some of these things we've been discussing that we'll all forget. For example, that idea I had at the top of my post here about the player app treating zone entry and exit events using different distances. I can bet we're going to forget about this. And I need to post that other thread about the Wherigo scoring system, and another one about Wherigo Invaders. We'll need to hammer those things out, though Invaders could be done another time. Still, Invaders might make a fun meta game... (I know I've explained Invaders before, but I forget where. I don't think it was in this forum. Perhaps a private email. Ads will always be out of scope. I don't like them. Yes, I agree that it's more telling to define what's out of scope than what would be in. I believe the offline/connected decision will eventually be done on a per-cartridge basis because it'll be based on the features the author desires to use (or in settings established in the player app). I'd like to start off by saying that cartridges can be offline, then go from there. Video will be the first question. Multiplayer will require online. (And I just went off on a tangent instead of sticking to the point you made.) Any forum will likely be that. We could either set up a wiki or documentation site to house everything. I can see discussion about individual documents moving there. But I also feel it would be good to continue general discussion in this forum as a way to keep the entire community involved and show that progress is being made. That's a whole other discussion, then: what would interest non-cachers to pick up Wherigo. The geocaching side might like that the cartridge terminates in a box with a log. The non-caching side couldn't care less about that box. The end result of a Wherigo cartridge should be different from a box. A geocacher can create a Wherigo and let it lead people to as many boxes as they want, but Wherigo should be done for something else: stories, adventures, challenges, games, and so on. And that's where we need to start: decide what Wherigo should be seen as and the feelings associated with it. We shouldn't just say it's another way to get to a box. After all, when Groundspeak released Wherigo fifteen years ago this month, there wasn't any overlap with geocaching. Soon after, though, people began making mystery caches using Wherigo, then the Wherigo cache type was created. I agree with this: Wherigo should be its own thing and, by the way, it's also possible to use it for geocaching if you want. The cartridge-loading problem with a player app is a non-issue. The Wherigo API will fix all that. Think of the Adventure Lab app: you see all the labs in an area, you can see information about a lab, then when you click "Start", it downloads the lab (sort of, since the media are downloaded as needed: I'm generalizing to make a point here) and off you go. Yeah, a project lead. I bet when you brought that up, people then thought, "I wonder what Fox is going to do?" Yes, I recognize I have a great deal of power and influence, so we should likely address that. I don't use it for personal gain or to satisfy an ego. This has always been a project of altruism. I intend to fill roles as needed. I do intend to be one of the key people providing a vision and direction to the project. The Wherigo Foundation name goes along since the Wherigo Foundation is the community's effort at improving Wherigo. I intend for whatever we produce to be hosted at first from that domain name, then in parallel at Wherigo.com if/when a partnership can be reached.

You could make a quick little cartridge using Wherigo\\kit (link in my signature) with two zones and a question. Once you have that set up, you could export a zip file with the cartridge to your computer, then import the lua file into Uriwgo and see how it's set up. In short: OnGetInput (let's call your input MyQuestion) Store the input value into the "answer" variable If the answer is equal to "theCorrectAnswer" then (The "this" you mentioned when a correct answer is given) else Play sound "buzzer" MyQuestion.GetInput end if

This is a place to get some help, yes. I'd suggest you give a summary of the overall idea, then go into specifics about what you want to accomplish and what you've tried. Please be clear and don't worry about beinge verbose since more information could be helpful. You can zip the .urwigo and other image files and make it available for download somewhere so someone can open it and see what you've done so far. I'm not sure who will answer your question (the next time I might be available would be sometime tomorrow night), but if it's not me, I'd suggest the person provide some steps so @Challenger519 can learn from them. The most important thing isn't the solution: it's the knowledge gained to get there.

I tend to live under a rock. You'd figure I'd be connected and well-informed, especially with my geocaching activity, but I'm not. I don't tend to do much with social media. So, yes, do see if there's any interest there. I'm envisioning a map populated with icons. If the zone has multiple points, the shape will be shown and icon optional (if provided, one can be shown). If the zone is just one point, the icon should be required, but if it's still not provided, a player app-supplied default icon will be used. Tapping on the zone will bring up a small box exactly like in Adventure Labs. You'll see the zone's full name, icon, distance, and one line of the description. Tapping on the zone will bring up the full description, larger photo, and a compass with distance if you're not already inside the zone. NPCs and items can themselves be displayed on the map with icons and have the same treatment. I share your viewpoint regarding programming language. For security reasons, I'd rather not give anyone the ability to make external calls. While it's true you can do a lot of cool stuff, such as dynamically build images (think of tracking your route in a maze or showing where you are in a maze without having to have every possible image in the cartridge), it's also true this would be a wide open door for someone to do harm. So while I'd love to see Wherigo run on C# or JavaScript, I would need a way to guarantee they'd run in a sandbox with the only external resource being the Wherigo Player API. You can pull it from my archive on my NAS here: https://nas.rangerfox.com/sharing/xD1PIc0ba The link will work until I move the file or rename the directory. The file isn't glamorous, but will make you happy you don't have to write any of that in your cartridges or deal with that low level. The file came from Wherigo Foundation's compiler. The associated file, WIGInternal, exposes these functions: GUI interfaces: LogMessage(a, b) MessageBox(a, b, c, d, e) GetInput(a) NotifyOS(a) ShowScreen(a, b) ShowStatusText(a) Events: AttributeChangedEvent(a, b) CartridgeEvent(a) CommandChangedEvent(a) InventoryEvent(a, b, c) MediaEvent(a, b) TimerEvent(a, b) ZoneStateChangedEvent(a) Internal functions: IsPointInZone(a, b) VectorToZone(a, b) VectorToSegment(a, b, c) VectorToPoint(a, b) TranslatePoint(a, b, c) Come to think of it, this is the first time Wherigo.lua found its way to the forum. I've had Wherigo.luac for a while now, but until today I hadn't had a reason to decompile it. I've also decompiled the builder application and thought about fixing some things with it so I could have a working version for Windows 11, but just haven't gotten around to it yet. A desktop at my house still has Windows 10, so I just remote into it if I need something. I've been lazy. These days, if I think about programming something, I usually just log into work and do something there.

It would be fun to see Wherigo run in WebAssembly, then. Anyway, if development proceeds, the intent is to make something awesome, let people use it, then see about the partnership again. Considering what I had gone through last time, I'd just as soon Groundspeak approach me, but nothing's stopping me from reaching out again, save my dislike of the indifferent actions last time. I can still continue to run things until something happens. I'll point out that I do have that official Groundspeak third-party developer standing with Groundspeak. When asked how I wanted to be listed on Groundspeak's official third-party developer listing page, I asked not to be included on it because it would be contradictory for Groundspeak both to recognize me as an official third-party developer and yet say cache listings can't mention the software. All other official third-party developers can have their group's software mentioned on cache listings. If we want to get technical about it, the listing site is in this middle ground, Kit should be 100% good, and everyone else's software who falls under the Wherigo Foundation banner should be fine as well because they're part of my group, but perhaps not because we're a little too loosely organized. And the moment the v2 project becomes not-Wherigo, I'm going to have to make sure discussion moves off this forum because it'll then fall outside the forum's guidelines and topic of discussion. I'd have to do that regardless of my moderator standing.

I've run across mystery caches that require you to go to a website and play a Wherigo-like game. Admittedly, I looked it up on the geocaching map and I don't see the cartridge anymore where I thought I played it. You could get around this by hosting a Wherigo cartridge on Wherigo.com where all you need to complete it is a code. You get the code from playing a v2 game. Or the final geocache would contain the completion code word that, when put into the v1 cartridge, would give you the final coordinates. As long as the v2 site is set up properly, such a placeholder cartridge could be generated automatically. And if the web service on Wherigo.com is still in place, posting the cartridge could be done in the background or as a final step to submitting the v2 cartridge. The real test is in figuring out if there are enough people who can contribute their time to making v2 happen and getting a commitment from them. But first, when I get some time, I'll share a couple more things I came up with back then: the scoring system and Wherigo Invaders. It might make for interesting discussion and some ideas.

I'd rather we start off trying to replace Wherigo, then go off on our own if a partnership can't be reached after we demonstrate a fully-working product. It at least allows us access to the player base of geocachers for the time being. But as I said, gathering a group of volunteers to create everything that's needed (and a commitment) will be a challenge on its own. We can control whether media is downloaded or streamed if everything is uploaded to the listing site as one package. This would require a lot of storage space, but storage is cheap these days. When downloading a cartridge, the player app would have to download the cartridge's manifest and required assets (e.g. the compiled/interpreted code), then look through the manifest and, based on settings or input from the user, decide what to do with the cartridge's other assets. It could even warn players that the cartridge's assets total 500MB, so it's advisable to connect to WiFi to download the cartridge, else it will need to stream the assets as needed. I would, though, prefer offline playability, but the manifest might also say the cartridge must have Internet connectivity because multipayer features are being used. The Wherigo Foundation used an example of a cartridge built to play poker or blackjack with other players. I do not know how difficult it would be to set up AR, both from a player API and cartridge author standpoint. It would be interesting to demonstrate this as a proof of concept one day. The AR I'm thinking of is something that looks at what's in the environment on the camera and places a 3D character that might even be obscured by foreground objects. Don't forget this would be a community effort. Doing the Wherigo Foundation and then later having a job where I was putting in on average 50 hour weeks every week exhausted me for several years. And when I needed a break from working on the Wherigo Foundation site, I ended up making a 42 mile hiking multi geocache because to keep balance I needed to be equally intense on something else. While I think I've recovered from all that and don't have that job anymore, I'll only put in the time for this if I have a group of others who are putting in time. It doesn't have to be much time every week--even five or ten hours will eventually get us somewhere.

Let's use the term "template" to refer to something cartridge-wide, such as a template that allows you to create a Whack-A-Lackey game, and the term "snippet" or "action snippet" to refer to a small piece of code that allows you to do something. Moving a zone won't be a snippet, though, because it should be a method call within the Wherigo Player API. A snippet could be as simple as "ask a question over and over until the right reply is given". Anyway, templates and snippets are isolated completely within the builder app sphere. This means once we have the Wherigo v2 Player API set in stone, anyone would be able to work on this outside the main group. For me, being able to see a mockup of a design and have all the graphical assets would be a big help. In the group, I'd rather focus my efforts where there's a gap in capabilities. When I get time, I should outline the Wherigo scoring and Wherigo Invaders concepts. Yes, Wherigo v2 should handle zones as single coordinates or as a shape. I would prefer to deal with zones as single points because that makes the distant/proximity/enter events so much easier. I don't know the math involved to determine if someone is ten meters from a zone that's in the shape of a star with a dozen points (points to the star, not zone points). Picture that star. Picture two of the star's points or arms. (We're going to exaggerate here.) Picture each arm goes out half a kilometer. Now, picture someone standing just outside where both arms meet, or someone a quarter of a kilometer from that vertex. What would an efficient algorithm be like? This is one of the reasons why I won't be on the player app team: I think others would be able to make something more efficient. (But if we lack a player app engineer, I guess that'll fall to me. Ouch.) So, anyway, if you have a single point zone, I'd like to rule that the zone's OnEnter event is based on getting within the device's estimated position error (EPE). I'd prefer to guide cartridge authors to use OnProximity for single point zones. OnEnter can be used for zones with a large enough area for it not to be a chore for a player to get within EPE.

Yes, that makes it challenging. But no one said we couldn't create a dummy cartridge on Wherigo.com that tells people the cartridge needs to be downloaded elsewhere. (A bit of a hack, but whatever.) Again, the idea is to produce something so good that the community will use it regardless of the geocaching guidelines, so much so that it forces Groundspeak to make a decision: partner with the group or close Wherigo. I'm hoping the former. If we create a separate platform, we lose the geocaching audience, must build our own audience, and will not be able to discuss it on this forum. At the moment, my interest lies in fixing Wherigo so more people can enjoy it. "Fixing" also means "adding more features" so people can enjoy it. I believe it's going to be difficult regardless to get enough people on board. We can start off trying to make a better Wherigo experience, then spin it off as something else if it's fun and a partnership fails. You might not be able to do it the other way around.

And as far as the other reply: I disagree about integrating the builder with the site, at least from a technical level. If we had a web-based builder app, we could perform a seamless redirection between both applications. Besides, with the API in place, the Urwigo builder can also offer a seamless experience. You can use the app to search for cartridges either by the map or any other UI because, you know: API. Templates are a good idea. I was mostly thinking about smaller snippets, but it's reasonable that someone could build a larger template. I'd rather start with cartridges being closed source because almost all are tied to a final geocache. I can't simply remove the last zone in a cartridge when it's copied because there isn't a simple way to tell what the last zone is. Other cartridges simply tell the final coordinates. I'd rather incentivize open source sharing or say a cartridge automatically becomes open source after a period of one or two years after its last update. I forgot about the media resizing feature. But, yes, media should automatically fit the view, but should be capped at zooming in 200% to avoid being too pixelated. Hopefully, it's more about downscaling. Yes, there won't be completion codes because of the API. When the cartridge marks itself as complete, the player app will send that information to the site via the API when the device has a data connection again (or immediately if it does at that time). Assets get a bit difficult to work with because we'd need some sort of community curation. Fortunately, someone could create an asset management application and API for builder apps to use. It does not have to be tied to the listing service's API (really, it shouldn't anyway). I don't have experience with Unity. However, the player app itself should be able to load different player runtime environments. This would allow for v1 to work, v2, and anything more complicated, such as something with Unity. Wherigo v1 wasn't map-based because it predated devices being Internet-connected. These days, Internet connectivity is the norm. So, the UI should be primarily map-based I'll be relying on others, then, to come up with a good UI for the website. I can hold my own, but a graphic designer and animator I am not. Perhaps Wherigo Invaders is the perfect way to gamify the site. I should probably make a long post to cover what Wherigo Invaders is. You have concepts from travel bugs, Ingress, Munzee, trading card games, and whatnot, and this provides a sort of meta game that gets you to revisit cartridges. And the other items: If you're considering integrating Waymarking with Wherigo, you'll need to answer some questions. First: what is Wherigo at its core? How would including waymarks strengthen Wherigo's core fun factor? (Waymarking could have been Swarm/Foresqure, but was never developed upon after its release.) How easy would it be for an average Wherigo author to include AR? We need it to be easier and more enticing to set up Wherigo cartridges. AR could be explored in the long term, but building a fun core game that can be fairly easy to create content for is a priority. We need the map to fill up with cartridges. Skinning was on my shorter list. However, I didn't think about skinning the map itself. (That is, allow the author to create a map upon which the game is played instead of the satellite or road map. We'll have to either have map tiles or just a very high resolution, large map file. That could be doable. Credits and such play into Wherigo Invaders. Challenges would be interesting. I forgot about adding to the player API the ability to query the current time. Good idea.

Sort of, except it's going to be a hostile takeover. The idea is to make something so good that the community will use it regardless. This will have one of three outcomes: Groundspeak can initiate the partnership this time, ignore everything altogether, or put an end to Wherigo. Nope, not after my experience last time. Hostile takeover. Besides, I don't even know if there are enough volunteers to pull off the project at this point.