Mangatome

I think it is possible to include other lua files in Urwigo, at least I've done something like that. However the way to include them is by using require("filename.lua") in the "Lua user directives" window. (I'm writing this from the top of my head, as I don't have my Urwigo install on this machine.)

Not to be that guy again, but if @jokergil lives in the EU and Groundspeak does not want to remove personal information, they will be in breach of the EU's General Data Protection Regulation, which nobody wants. So if you live in the EU, jokergil, I'd suggest writing to dpo@geocaching.com the following: "Please remove the homepage link from my Wherigo.com profile". They have then 30 days to respond and keep you informed of how they will comply. Of course it'd be much easier for everyone if they'd just follow @Ranger Fox's tutorial above and be done with the issue forever

I also find it impossible to change the Home page link, whether on Wherigo or on Geocaching. Since the homepage URL can be considered personal information, you should have a right to delete it. I'd suggest you to contact Groundspeak again through the help form at https://www.geocaching.com/help/ then select 20. Privacy Rights under "How would you categorize this request?", and then Deletion Request.

Thanks for the suggestions. I'd be curious to see if we can factor some of these, and get estimates on proportions of the general audience falling into these categories. We can't really guess that without evidence, hence the process I mentioned above, and tools like surveys, etc. Regarding the surveys, I'm thinking it could help us answer some questions raised by your thread Feature List, such as: What does the community like about v1? What does the community dislike about v1? What features does the community lack in v1? It could also help us prioritize some features, asking the community to order or rate the importance of some feature ideas.

Spot on. The Lua bytecode is indeed version-specific and unspecified. The consequence is that it should be considered transient and therefore it should never have been part of the Wherigo specification. In my opinion, Groundspeak made a mistake there. What using the bytecode as a language for game logic does is locking the version of Lua that the ecosystem uses, putting very strong pressure on player and editor developers to remain compatible with deprecated versions of Lua. (I personally had to backport Lua 5.2 bug fixes into a C# port of Lua 5.1. I do not wish that on anybody.) This is unbearable technical debt, almost impossible to ever pay back, since the cartridges in the wild are forever locked to this format. I disagree there. Just because the bytecode never changed doesn't mean it will never change. The Lua authors clearly meant the bytecode to remain internal and not be persisted. Strong disagree. That is precisely the mistake Groundspeak made, and this would equally lock us to a particular version of Lua, with the same maintenance and technical debt issues we currently encounter. And what good would it do anyway? Really, why do we even need bytecode at all? It's not necessary to execute code - the Lua interpreter can load text as code, obviously. It's not necessary to obfuscate code in transit - it wasn't even good at it, and we could do better with encryption and a simple key exchange with the listing service API, if that was even ever needed. It's not necessary to reduce file sizes - most of a cartridge's weigh is media, and there are good HTTP compression techniques nowadays. It's not necessary to speedup runtime - cartridge code is usually small and will likely be interpreted very fast on modern devices. So, personally, I would advocate for simplicity and flexibility: the player app exposes to the listing service API the versions of Lua it supports the listing service API returns a cartridge payload along with metadata, but for a Wherigo v2 cartridge, the logic is Lua X.Y code, compressed and obfuscated if necessary. The code targets the maximum version that is supported both by the player app and the uncompiled cartridge stored in the listing service. for a Wherigo v1 cartridge, it is the Lua 5.1 bytecode for backwards compatibility

I'm not sure I understand what would then happen with the code when it is converted back to a number. But I would just multiply the number by 1000000 and then round it. Same for the reverse operation, you can divide the decrypted number by 1000000. This way you don't bother with decimal separators.

I think I mistook os.date() for os.time(). What if you use: timer_start = os.time() and if os.difftime(timer_start, os.time()) > 60 then -- More than 60 seconds have elapsed: player was too slow. else -- Player is on time... end ?

You make a good case for sticking with Lua, and I think it makes sense, to harness the experience and code bases the community has aggregated over the years. However I still think that, if we went this road, we'd need to bump to the latest Lua version, just to leave the possibility for a few humans to actually hack together cartridges from code.

Hi all! Following the very prolific thread Feature List, I would like to fork some attention to the process of UX research for Wherigo 2. We have seen that a lot of ideas, desires and frustrations exist in the community, and I believe that as a community, our first step should be to gather these thoughts and feelings a bit systematically, in order to understand ourselves a bit better and to help us prioritize and organize. To that end, I'm proposing a process called user experience research or just user research. There are various tools and methodologies that we could use for this but for simplicity I think we should begin by surveying the community of Wherigo enthusiasts using one or two surveys that will aim at understanding what works and what doesn't in v1, see how people use players and builders, what the relationship is with programming, etc. This will get us a wide spectrum of thoughts. It would also be nice to prepare some more in-depth live interviews with some users, in order deepen our understanding of the whole experience of Wherigo. From these, I would like to eventually get to a few user personas which are, in a nutshell, characters that represent user types. I think we implicitly have two types, Wherigo players and Wherigo authors, but these are too broad and I suspect there are going to be sub-types (e.g. casual author, player who only plays in groups...) that are crucial to identify. I'm starting this thread to get some help with this process. The first step would be to design some surveys (suggestions appreciated!) and later we'd need help to disseminate them among the community.

You are right that Lua has the advantage of being simple and versatile for programmers who enjoy procedural programming, but anything else is a can of worms (e.g. metatable madness for the simplest POO use-case). That makes it more annoying for engineering. Also the core libraries do not shine by completness, so there is a lot lacking there. But maybe it's a better course of action to try and fill these voids with existing or new Lua libraries than having to wrap .NET platforms in all our player apps. So, at this point, my thoughts on this matter is: Lua is nearly not simple enough for cartridge authors, as evidenced by the multiple testimonies above, but neither will be C# or whatever else scripting language. So it does not really matter what we use to sandbox cartridges, provided there exist robust and accessible pathways for people to make cartridges. In a way we already have quite a few workflows, web-based or not, visual or not. Even your language is a nice addition to this ecosystem (please open source :D). Personally I'm missing a C# to cartridge pathway, but that's just my personal preference. If Lua works for everyone and solves problems as a sandbox, let's keep it. But we'll have to invest in editor tools and resources, because it is my gut feeling that no one in this thread really enjoys or wants to write cartridges in Lua. Agreed, so the cartridge-side API should evolve to include modern features such as networking. I agree with you that at first we could focus on supporting the use case of a party of players playing a cartridge together, which is in my opinion the most promising avenue for the game.

I'm not sure whether the problem may be specific to earwigo, but in theory calling os.date() in the lua code should give you the time on the player device when that code is executed, not the time when you wrote the code. What I would do is, when you want the timer to start, to assign the date to a variable, for example timer_start = os.date() and then when people reach the goal zone if os.difftime(timer_start, os.date()) > 60 then -- More than 60 seconds have elapsed: player was too slow. else -- Player is on time... end Not sure how to put that into earwigo, though...

There are a couple of things to disentangle there. latitude and longitude are decimal numbers, but whether a comma or point is used as separator depends entirely on context. As a cartridge author, you must use a decimal point as @capoaira said. (From the point of view of the device that runs the cartridge, the concept of decimal separator does not even really make sense anymore, since internally numbers are stored as sequences of bits.) But then, if you want to present these numbers to the user, you need to represent them somehow, a process called formatting and that converts a machine number (bits) into a human number (characters, so text, really). That process may or may not be involve cultural settings such as what character is used for the decimal separator, where to put whitespaces, etc. But most of the time one who just wants to show a number does not have to bother with these cultural things, so "we let the programming language do it" and it uses some default. Broadly speaking, in programming in general I would expect the default formatting for numbers to be culturally variant, which means that if I print a number on a French machine, it should give a different result than on an American machine. That's not always the case, and some programming languages default to cultural invariant formatting, which is usually printing numbers an American machine would. Fast-forward to Wherigo: because of the various Lua implementations in use in the various player apps out there, there is no consistent result from printing a number. Depending on the app, you will get culturally variant or invariant results. Worse, there is no way from cartridge code to determine the language of the device the user is using, so you could not even write a custom formatting function if you needed it. The long story short is there is no way to guarantee your formatted number will follow the conventions of the user's country so a cartridge should probably not rely on it.

Overall, I agree. If we stick with Lua as a backend to sandbox Wherigo cartridges in the player, we'd save ourselves some trouble. Besides, thanks to projects like LLVM, Roslyn and others there are strategies to convert C# code to Lua. So, this will be a question more for the editor apps than for the player apps. And I think @Hügh is right, turning to polyfills could help extend cartridge lifetime. I think that overall, we need to use separation of concerns as much as possible. The player app(s) will need to honour various versions of the Cartridge API and the server API will need to honour various players through versioning. The mechanisms you describe seem right to me, and I don't see any major roadblock in versioning Cartridge APIs player-side. I think we are 90% there. The WF.Player.Core repo already defines an internal model to use something else than Lua as a backend. All entities from the v1 model are backed by interfaces in the data layer, so even if we stick with Lua, this out-of-the-box would let us switch from a Lua 5.1 to a Lua 5.2 backend. I say 90%, because I'd need a little refactoring pass on the code to upgrade it to newer versions of the language, code style, best practices and target platforms (Portable Libraries became .NET Standard since we wrote the engine). But the core mechanisms are here. I agree that it doesn't feel right to add such a bottleneck in cartridge publication. It seems more flexible to let final users decide if and how to let all or specific network traffic through. If anything to facilitate development and experimental cartridges in events. I could envision a simple permission system in the player app like @Hügh suggested. I also would prefer a C#-based framework to back the player. However the feature set we want to support should influence this choice a bit, so I think we should gather needs from the community before deciding on the player tech. I too am glad we're not jumping into coding this

In my opinion, the biggest problem is clearly the first, as evidenced by the disparity of behaviors a simple operation such as `os.time()` can yield depending on the player app (let alone the OS) due to various Lua implementations being used. And don't get me started on other parts of the base Lua library, for example math functions, which used to simply crash the Groundspeak iOS player because it hadn't been built with the math library. And of course, not to mention the varying support for basic Wherigo constructs such as proximity events, which may not even fire on some apps - I suppose, because of various implementations of the player. All the other issues are very secondary. As long as a cartridge respects the API, it should work consistently. The unreliability of players comes from the variety of implementations. So, clearly, on the player side, our number 1 priority should be to provide the community with a single player app that is built and distributed on all relevant platforms. For smartphones/tablets, this is going to be rather easy thanks to existing frameworks like MAUI or Unity, React Native etc (although I'd rather stick with C# and .NET on the player side). For GPS devices this may require to write alternative code bases if there is outstanding community demand (for instance a Monkey C app for newer Garmin devices). Making a better player, that works consistently across all devices people use. I think that should be the goal, and I think we're closer to it than we'd think. This may be a bit tricky due to sandboxing having been removed from .NET starting with .NET Core. There might be other strategies but that'd require some research. Also, do we really want to be more restrictive than the OS? If you're concerned about cartridge code exfiltrating sensitive data such as geolocation, this is something we could fix at the compiler level, by processing cartridge code and figuring out what goes in the network. Though, I admit, this would be a bit convoluted. But the question remains: are we restricting cartridge devs too much if we strip away the ability to reach the network? What you describe can be done with LLVM, if I'm not mistaken. But concerning whether or not to switch, I see it as a tradeoff. The main issue with Lua in my opinion, is that it's locked in Wherigo at a deprecated version. This makes it very annoying to keep it in sync with the evolutions of the Lua baselib and API (read: no player developer bothered to do so, leading to the inconsistent reliability of Lua base lib support in player apps). If we keep Lua we should at least use the native Lua implementations and stop relying on version-locked bytecode for cartridge code. This implies that the cartridge code should be compiled by the player at runtime (using the player's built-in version of Lua); or that the player should be able to load Lua bytecode for all major versions supported by the compiler.

This is beautiful insanity, I am baffled, and I really wish I had known about this earlier because it would really have made my life easier when writing cartridges Did you consider open-sourcing your compiler? Regarding the rest of your message, I agree with you on most points. You are right that many technical details of W1 actively make developers' lives hell. Not just cartridge devs but also engine devs (I would know; I had to backport Lua 5.2 fixes into a C# port of Lua 5.1 in order to support WF's player engine). My general solution for most of the problems you mention is: let's throw away Lua and move to a language that comes with a strong community, ecosystem and toolkits. The fact that we virtually cannot use any Lua lib without crashing half of the player apps out there is a shame, and that the bytecode is stuck to an almost unmaintainable Lua 5.0/5.1 is a disgrace. Personally my favourite language is by far C#, it's very well documented and designed, comes with a very strong baselib, and has a robust community making lots of good code available. We don't have to have the cartridge API target C# (although, like Ranger Fox, that'd be my personal choice); but the player and builders very well may, since the WF.Player.Core engine already solves a lot of the problems you mentionned, and can serve as a common model and processor for players and builders alike. Also it supports geometrical testing of arbitrary polygons quite fine

I completely agree! Modifiers are likely to incentivize publishing or completing "anything". Maybe the key is to keep it simple: there are points to collect when completing cartridges, and any completion grants owners a fraction of the collected points.

Thanks a lot for the detailed explanation of the concept! I like the idea of having meta-game campaigns to incentivize cartridge completions. Two caveats come to mind: How to handle cheating? I'm thinking about somebody who would use technical means to bypass having to actually complete a cartridge. Sustaining campaigns and balancing the game iteration after iteration will likely require a dedicated team.

I'm so thrilled to see this renewed activity around the future of Wherigo, thanks to @Ranger Fox and @Forest-Ghost for starting the train! Also big shoutout to @charlenni, I'm so happy to read you again! There's a lot of contents in the posts above, it's all very interesting and it will take me a while to dive through. I just wanted to add a handful of quick thoughts, as a professional game developer and GC enthusiast and co-writer of the WF.Core player engine with @charlenni. This thread shows that the community is eager to work together, and that's amazing. As @Ranger Fox said we need organization and communication. I'm afraid the forum is already showing limitations. What about some kind of periodic online meeting to organize efforts? There is a million technical ways we could build a Wherigo 2.0. The best one is probably the one that contributors are most fluent with, sure. But before we begin to plan out technical roadmaps I think we should start by compiling what cartridge devs and users want and lack. Maybe some kind of UX survey of the community? This thread is a good start but I think we need to be more systematic. Personally, my number 1 frustration is how limited in scope everything is within Wherigo. I'm completely tired of "Item" menus and "Zone" screens. They served their purpose back at the days of limited device resources, but these days are gone. So are the days of low computer literacy. Maps are necessary to WIGs but they are so 2010. Now people are used to using very nice UIs, especially in the realm of games. I would love us to think bigger. My dream Wherigo 2 is a hackable Wherigo, where a dev has the flexibility to extensively tweak the UI/UX to provide more interactive activities (I'm thinking for example, for the Pac Man cartridges out there, a map presented as a retro PacMan level screen, with ghosts and players represented with the proper game elements.). This is not mutually exclusive with making it easy for beginners to make cartridges, provided we maintain templates. I'm all for ease of use but please let's not forget advanced users who can get their hands dirty to make something new. I don't see this happening without the Geocaching.com platform. However, I believe we could harness the GWC format (especially the Media sections) to add arbitrary Wherigo 2.0 payloads. That would make Wherigo 2 backwards-compatible to the extent of being able of showing a message saying "Your player app is a bit too old, please use X or Y" or showing a bare-bone fallback using Inputs and Messages. This would definitely pass compilation and probably pass moderation. I'm really excited about this community endeavor and I'm eager to help however I can!

I hear you, but small file sizes and fun experiences are not mutually-exclusive. I'm not saying we should put World of Warcraft in a GWC But already a few animated and interactive elements, customizable UIs and maybe the possibility to use AR, to show videos or to communicate with other player's devices would enable many fun experiences.

Yes, that would not be for the casual Wherigo developers, although one could argue that Adventure Lab already covers the casual's needs (not to mention that Wherigo and Lua were never friendly on beginners anyway). However, I think the most advanced developers, those who made complex carts (like Pac-Man or Pokemon remakes or large RPGs) are currently tremendously held back by the Wherigo tech. I believe that a Unity-powered player could enable game developers to create very unique experiences and activities and make them available to Wherigo cartridges. (Scratch is way too limited in my opinion, I'd rather shoot for the stars. And besides, I have seen Unity being taught to artists with little IT knowledge in a week, so it's not that bad to learn!) To me, it would be like an experimental sandbox the community can use to push Wherigo forward. Minigames and activities could be developed and later repackaged for use in more casual setups. At this point, I think Wherigo will need all the pushes the community can afford. We'd probably need several projects in parallel to experiment with different directions the game could take. In parallel, there could be a project about making a new easy cartridge editor for beginners, etc. However the advanced users are currently very discouraged from creating things in Wherigo, and I believe this should be tackled.

Hello all. I'm sharing the concerns of others in this thread. I put a lot of work into creating Wherigo cartridges and I would hate to see them go. Also Adventure Labs don't do anything for me. I'll be very happy now as ever to join a community attempt at pushing Wherigo somewhere better. I have an idea of my own that I started playing with last year, but haven't had a lot of time to continue it. I'll try again to put some time in it this year. The end goal is to create a bridge between Wherigo cartridges and the Unity game engine so that cartridges could provide sophisticated game activities.

I've recently purchased a Montana 700 and there seems to be an official SDK to create apps for it (with some kind of C++ flavor). I guess someone could write one

Hello! I'm pretty happy about any official news in the Wherigo world, and this new official app is great news indeed. Hopefully this will bring greater compatibility on iOS for playing cartridges that go out of their way to do something unique (the previous app was very weak when it came to Lua base library support, for instance). On that note, players are encountering an issue when playing one of my cartridges, which I created with Urwigo. There is a zone that is supposed to trigger display of a message when players get "in proximity". In the various Android apps, that event is indeed raised, so the message is displayed when players get under X meters of the zone. However on the iOS app, nothing happens. I've been trying in vain to find any way to debug the issue, but alas there does not seem to be any logging (.gwl?) done. Are proximity events actually supported in the iOS app?

Users are reporting today that this problem seems to be solved. Please try again and let me know if it is not.

Hi! I've had multiple reports of users facing this problem in the past days. I will investigate this issue this coming week.