GitLab

I'm not 100% sure why this fix works, but it does, and I'm still
fulfilling my obligations to free resources, so I'm rolling with it.

See the added comment for some more details.  Basically there seems to
be a problem with destroying the SDL renderer before destroying the
window, though that would appear to be the correct order of operations.
I'm not sure if I'm doing something wonky to cause the issue, but simply
rearranging the order of destruction makes the crash go away, so here we
are.

This adds a check so that we look for resources:
 * first in ./res, to support running the game as you're developing it,
 * next in $APPDIR/usr/share/3omns in case we're running in an appimage,
 * and finally in the configured DATADIR (/usr/share/3omns) to support a
normal install.

I'm not sure what magic I thought restrict was performing when I wrote
this, but I now know better.

Looks like the spec has been updated since I looked at this last.

It's the new way.

No need for those abominable characters unless absolutely required.
Also compacting the configure.ac code a bit.  Still seems pretty
readable to me.

Heh, had this sitting around in my working tree from who knows how long
ago.  Ship it!

Seemed like something that maybe some day someone might maybe want to
think about wondering about changing.

The one from Mailaender looked like it came from an older version of the
appdata spec, so I took the liberty of modernizing it and expanding it
in my own words.

The spec is a little ambiguous (and the validator tool seems to disagree
with it sometimes, e.g. about whether the <translation> tag is required)
but I *think* this is syntactically correct.

Thanks!

Forgot this when I made a similar commit to INSTALL recently.

Oops, shoulda did this allll last week.

It's been out for a while, might as well keep current.

The C code is pretty easy--unsigneds just become integers, no big whoop.
The lua code is a little trickier since every math operation has to
(gets to?) take the new integer type into account.  I think I got it all
ok, might've even gotten a little pedantic in there... but if this isn't
the place for pedantry, what is?

It's more properly "network play" now that it should work outside of
LANs.

I'm calling this state 0.2, mostly so I can cut another release from
here.  Nothing significant has changed from the user's perspective,
things just work better under the hood.

I *believe* the net code is now reliable (and by that I just mean game
messages won't be processed out of order) even on the noisy, unreliable
internet.

I haven't done a thorough audit or even much testing to prove this
belief, but at this point any network errors are unknown bugs and should
be considered separately.

I'd forgotten to add this to Makefile.am when I added the file.

Thanks to github user nemysis for pointing this out and sending a patch.

It doesn't matter.

Instead of storing the elapsed time between think calls in the bot, we
simply pass it through every time from C.  This means the bots can
operate with variable timing each think call, not that it'll ever happen
that way.

Stop using globals as much, move init code into its own function.

This takes advantage of lua language features a little more nicely.

Column-aligning across lines can be great, but not where it was being
used in these places.

Previously the bots assumed that of the nearest dudes in any position,
they would always be closest to that position.  This was wrong in a
number of cases.  This does the filtering properly.

Just like print.

Instead of relying on tail call elimination, this sets up a loop that
repeatedly calls the "do whatever we should be doing next" function.
Then every action the bot can do simply returns the elapsed time of its
combined sub-actions.  That way they're more easily composable, and the
logic is easier to follow, too.

Rethink is a better name.  Plus it makes sense to call it from the
starting state instead of start saying what state to go into directly.

It's like decorating methods with an async keyword in other languages.

This cleans things up a bit, where the bot AI code isn't just part of
the dude code, but a separate class that can control the dude.