What changed in EDuke32, build by build

It didn't turn out that useful and was giving a warning with one of the preceding changes.

Also, very slightly tweak a factor toward a "brighter" (farther visible) scene overall to account for the "circular" nature of the fragment distance (as opposed to an "ortho" distance in Build).

Also, fix 'spriteflags' directive.

Having to tag these few variables and functions as ATTRIBUTE((used)) seems sensible, but what follows is just strange. OSD_Printf? headspritesect?

- fix getv movflags handling in VM_Move() - add actor.fall() - LunaCON: sanity-check some action members

Also, get rid of the strange filename[len]=255 hack in loadboard() and make its file name arg const char* at last.

- Pass original module name (dot=dirsep) to module via our require() - geom.lua: fix some operations using the vector type constructor - geom.lua: provide constructor for ivec3, useable like vec3

It's hard to call this a fix, since ideally, buffer sizes like these would be only as large as needed in the worst case.

See http://forums.duke4.net/topic/6526-eduke32-crashing-when-loading-a-dukeplus-map-save

Add a test case in test_tileoffsets.map.

(I think; untested.)

The commit revises the definition of qstrdim when TEXT_[XY]OFFSETZERO are used. With these flags, the offsets the user specifies are now the only dimensions the function cares about in terms of tile placement, so depending on the difference between the offset(s) and the size of the final tile, it may be slightly more or less than the dimensions actually displayed on the screen because tile size is never taken into account. (For example, if your font is nominally 9x7 like the Duke bluefont and you use a TEXT_XOFFSETZERO of 5 with a string five characters long, the total x dimension will be 25 even though the last character will overhang that amount by four pixels. If you use a TEXT_XOFFSETZERO of 12 with the same string, the total x width will be 60 even though there will be three pixels of empty space on the right edge.) This change was made because assigning text an arbitrary constant width in general implies an intent to keep character positions constant even with a variable width font, but returning the visible span of pixels on the screen that the tiles cover would have caused the string to move when alignment options other than the top-left were used. In other words, you can now safely use TEXT_[XY]OFFSETZERO with the alignment options and the text won't jiggle. Also, with TEXT_GAMETEXTNUMHACK, numerals are now effectively TEXT_XOFFSETZERO text that respect the above paragraph, so number count displays can look nice with alignment options too. Having to modify the extent/offset code makes me realize that I'm not quite happy with its structure because it gets tangled juggling different concepts like character width, X offset, and spacing, and how they relate when the line wraps or in terms of the final size. Fortunately, it produces correct results as far as I know, and it's not necessarily ugly, just hard to understand. Handle with care.

Also, fix clearing a bunch in new-format-map (=Lunatic) build.

When encountering a non-empty statement inside braces, emit "do" ... "end".

Also, allow (implicit) actor index -1 to 'sound' like in C-CON and fix MULTIMODE gamevar definition (was 0, not 1).