Up to Main Index                         Up to Journal for September, 2016

                  JOURNAL FOR WEDNESDAY 14TH SEPTEMBER, 2016
______________________________________________________________________________

SUBJECT: It's quiet... too quiet.
   DATE: Wed 14 Sep 21:39:45 BST 2016

Yet again I have not been writing journal entries. I have excuses and reasons,
both unimportant as I've not been idle. This could be the quiet before the
next release...

I've recently coded the encoder for the RecordJar package to mirror the
decoder. The encoder helps writing data to a RecordJar.

I've written some simple code to write out a new player .wrj file. However
this is not full blown marshalling yet. In fact we don't have full
unmarshalling either for player files. This means that you can't load or save
a player file that contains items, or containers with items, just yet. The
code is there already but is currently specific to loading zones and needs to
be generalised.

The account and player creation process for the frontend package is nearly
completed. It can ask for the new account, passwords, character name and
gender and use those to write a new player file using aforementioned new code.

The last bits are coming together for the release quite nicely despite there
being fewer journal entries ;) Just needs a little more polishing before the
changes go out to the public dev branch.

There are a few other missing pieces I've been working on. The text package's
folding can now handle text with ANSI - ECMA-48 standard or ISO/IEC 6429 -
escape sequences. This is important for adding coloured text - although no
coloured text as been added yet. I have added a color.go file to the text
package to make handling coloured text simpler.

Text can be coloured in one of two ways. You can put the colour names in
square brackets and then call Colourize:


  text := Colourize([]byte("This is [RED]Red[NORMAL]"));


This is best used with text read from files - usually via a byte slice and
hence the conversion to []byte used in the example above.

The second way is to use the colour name constants. For example:


  buf.WriteJoin("You see ", text.Yellow, name, text.Normal, " here.")


This example is using the WriteJoin helper from the cmd package that allows
multiple strings to be written to a buffer one after the other. You could use
[YELLOW] and [NORMAL] in the strings and call Colourize but it would be much
slower.

The color.go file is new and I'm not sure if it needs a string method such as
ColourizeString. I'm reluctant to add it as a convenience as its usage - and
that of Colourize - is actually discouraged. Instead the colour constants
should be favoured due to performance. In fact the only time Colourize really
needs to be used is when the server loads configuration and zone RecordJar
files when it starts up[1].

As a minor note, most of the above work was done in the middle of nowhere on a
tiny netbook from 2008 with a single core Intel Celeron M @ 900Mhz, 1 Gb RAM
and an 8.9" screen. Maybe it's time I upgraded to a Chromebook?

--
Diddymus

  [1] Actually I can think of a second use - allowing colours in user input.
      For example "say [RED]Ra[GREEN]in[YELLOW]bo[BLUE]w![NORMAL]", But do you
      really want to allow something as annoying as that?


  Up to Main Index                         Up to Journal for September, 2016