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