It's been a while since I talked to you all. I've been quite busy and I'm not sure how much time I have to spend on here. However, I'm always interested in the subject, so I decided to at least respond now. :-)
For those who don't know me, I've been working on a Wherigo player in the past and was part of earlier discussions about v2.0. I'm a programmer, I like free (open source) software, and I believe users have the right to be in control of their own devices. In particular, I believe that if a player wants to cheat in a (single player) game, they should not be prevented from doing so. This may not be very relevant at the moment, but I thought it could be useful to mention so you understand how I generally feel about this.
So let me now way something about what Ranger Fox was writing:
5 hours ago, Ranger Fox said:
We will need to track both the lua version AND Wherigo version against which a cartridge is created.
Yes, this makes sense. The idea is to have the cartridge source on the server, correct? I believe that is important, because different Lua versions have near compatible language syntax, but incompatible bytecode. This means that it should be relatively easy to write code that will work with multiple Lua versions, but only as long as it isn't compiled. And I think we should allow players to include only one version of Lua, without making it impossible to run most cartridges.
Quote
For v2, we can decide to use token text when things like a user's name is requested to be placed into the cartridge. Therefore, it'll be up to the player app to substitute that token text when it comes across it. This would allow me to store and serve one compiled bytecode to all clients, reducing server resources and response time prior to a download begins. I like that idea. Wish I thought of it sooner. (We could possibly inject the player's name into a v1 cartridge to achieve the same effect.)
I think it would be a lot easier to inject the tokens into Lua as variables. No need for the player app to search and replace anything.
Quote
A cartridge author can choose to switch an existing cartridge to a new version of lua or Wherigo if desired. Simply use the builder application (or other tool) to upload the cartridge source code again, using a different version identifier. The API will once again perform a build validation against the building service.
This is good for making "certified" versions, but I think it would also be useful if players can attempt to compile cartridges for different Lua versions if the author is unresponsive and doesn't do this.
Quote
When cartridge bytecode is requested, it will only be built against the lua and Wherigo versions against which it was uploaded. This ensures on our end that the cartridge functions true to how the author [should have] tested it.
In other words, I would like for this to not be the case. It's fine if there is a giant warning about it, but it would be nice if it would be possible.
I think some authors may not like this, because you never know if the internals can be (more easily) discovered on a new Lua version. While it may give them a false sense of security (because this is possible from bytecode as well, no need to wait for a more "debuggable" Lua version), if they want an option to disallow this, I'd be open to that. However, if they select that option, it means that they are (even more) responsible for keeping the cartridge up to date. This should be made very clear to them.
Quote
When deploying a new version of anything to the Wherigo ecosystem, updates must flow in this sequence: builder service, API, website (if applicable), player app, builder application. If this sequence is broken, bad things can happen. We could perform a preview release by allowing these to work with new versions without advertising it or enforcing a new version by default. This would help for testing. Communication will be crucial.
Yes, properly documenting this process and having a test environment before making it live are indeed essential for a good user experience.
Wherigo v2: Feature List
in Wherigo
Posted
Hi,
It's been a while since I talked to you all. I've been quite busy and I'm not sure how much time I have to spend on here. However, I'm always interested in the subject, so I decided to at least respond now. :-)
For those who don't know me, I've been working on a Wherigo player in the past and was part of earlier discussions about v2.0. I'm a programmer, I like free (open source) software, and I believe users have the right to be in control of their own devices. In particular, I believe that if a player wants to cheat in a (single player) game, they should not be prevented from doing so. This may not be very relevant at the moment, but I thought it could be useful to mention so you understand how I generally feel about this.
So let me now way something about what Ranger Fox was writing:
Yes, this makes sense. The idea is to have the cartridge source on the server, correct? I believe that is important, because different Lua versions have near compatible language syntax, but incompatible bytecode. This means that it should be relatively easy to write code that will work with multiple Lua versions, but only as long as it isn't compiled. And I think we should allow players to include only one version of Lua, without making it impossible to run most cartridges.
I think it would be a lot easier to inject the tokens into Lua as variables. No need for the player app to search and replace anything.
This is good for making "certified" versions, but I think it would also be useful if players can attempt to compile cartridges for different Lua versions if the author is unresponsive and doesn't do this.
In other words, I would like for this to not be the case. It's fine if there is a giant warning about it, but it would be nice if it would be possible.
I think some authors may not like this, because you never know if the internals can be (more easily) discovered on a new Lua version. While it may give them a false sense of security (because this is possible from bytecode as well, no need to wait for a more "debuggable" Lua version), if they want an option to disallow this, I'd be open to that. However, if they select that option, it means that they are (even more) responsible for keeping the cartridge up to date. This should be made very clear to them.
Yes, properly documenting this process and having a test environment before making it live are indeed essential for a good user experience.
Thanks,
Bas