Up to Main Index Up to Journal for August, 2016 JOURNAL FOR SATURDAY 6TH AUGUST, 2016 ______________________________________________________________________________ SUBJECT: Mostly boring accounts DATE: Sat 6 Aug 21:21:35 BST 2016 This week I've been working on the account loading code again and made some pretty descent progress - compared to recent coding sprints not too difficult. As much as possible I'm trying to keep compatibility with the old player files. Is this something I should worry about at this stage? After all only prototypes have been released at this point in time. What prompted this is the fact that old[1] player files do not have an Inventory field. So we end up with code like this: // LEGACY: Add inventory if it is missing. Pre re-re-write player files had // no Inventory field. if !attr.FindInventory(d.player).Found() { d.player.Add(attr.NewInventory()) } Not a big deal, but I'd rather not have legacy stuff building up already. Maybe I can just add some upgrade notes that say old player files need editing to add the field to be usable? I've also got the issues of where to put stuff. By that I mean, do I put all of the player account handling into the player attribute in attr/player.go? I don't particularly want to as it is not specifically game play related, but it is player related. I'm thinking that maybe there should be a separate account package. Not too sure at the moment so still mulling things over. Working on player loading I also realised I could almost reuse a lot of the zone loading code for it. Before I can I need to do some refactoring as at the moment it is tightly bound to just handling zones. Maybe yet another package is going to be required for a loader that player and zones can both call on. I did think of refactoring some of the general loader code back into the recordjar package but that's already pretty clean and standalone so I rather not go polluting it. Everything I'm currently happy with has just been pushed out to the public dev branch for those interested. Is there anything else I want to mention? Oh yes, I caved in and got myself an official Arduino Uno R3[2] - supporting the project and all that. Just in case I want to do some development work on an ATmega328P or something... Actually, maybe people who have been politely nagging me lately can answer something. Which flavour of assembler would be the most beneficial? Atmel AVR assembler - actually the avra clone on Linux, I really don't want to be using Windows - or avr-as from the GNU AVR binutils? I was thinking Atmel AVR as it seems to be the official one but Atmel also use the GNU avr-as as well in the Atmel Studio and for the Linux command line tools download. I'm leaning more towards the Atmel AVR assembler at this point but would welcome any feedback. So opinions and advice in an email to diddymus@wolfmud.org would be appreciated. Finally, switched to using Go 1.7RC5 with no issues. -- Diddymus [1] Pre re-re-write files. [2] Actually an official Genuino Uno R3 being outside of the USA. Up to Main Index Up to Journal for August, 2016