What changed in EDuke32, build by build

Also, clean up the saving/loading logic a bit: - On load failure, display message with purple color. - Take over the current file name ('boardfilename') only on success. - Check SaveBoard() return values in various places.

In other words, for a test rectangular sector, a sprite would be inside the sector in on all 4 edges and all 4 corners. Previously, it would have been the lower right portion only (*excluding* LL and UR corners), which led to map editing issues.

The main thing to note is the "half-open" nature of the x/y range checks.

- 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

Also, an external 'minitext' with optional shade and pal. args and documentation for ps:padecol().

They don't get registered on Windows for some reason, and mapstate debugging is best carried out using scripting code, anyway.

- Handle local gamevars. - Restore gamevars from require('end_gamevars').

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

(This is the module that implements much of the "hard-coded" functionality formerly on the C side.)

Add a test case in test_tileoffsets.map.

Don't (yet?) commit the generated HTML.

However, from the command line, reverse the situation: dirseps must be passed as '/', dots are forbidden (except in the trailing ".lua").

It is a 32-bit signed integer. No version bump necessary, although CON code accessing this new member will not work with earlier revisions (obviously).

Also from Lunatic, make these members read-only and provide methods that allow setting them to either -1 or a number in [0..MAX{TILES,SOUNDS}-1].

(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.

That is, the gamevars named WEAPONx_* in CON will now have the remapped value if they were not overridden from CON ('gamevar' at file scope). For C-CON, everything except signaling an override from the CON parser is in place.

Also add some recent keywords to the list in con_lang.lua which I had forgotten all along.

Also, make sector[].*stat a bitint type. Now, a piece of code could look like this: local sec = sector[i] local ceil = sec.ceiling ceil.statx:flip(sector.STAT.SMOOSH)

The previous behavior was to translate them as global gamevars, since LunaCON currently has no support for multiplayer. However, then some errors would be missed where such gamevars are accessed in no-player context (e.g. EVENT_ENTERLEVEL). On by default, disabled with -fno-playervar.

G_PrintGameText(), minitext_(), G_DrawTXDigiNumZ(), and menutext_() now wrap G_ScreenText(). G_GameTextLen() now wraps G_ScreenTextSize(). G_DrawDigiNum_() now wraps G_DrawTXDigiNumZ().

It should be transparent even with the meter disabled.