wijnen

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