Cosa è cambiato in EDuke32, build per build

Note: 'skill == 0' can be obtained from the command line by either * '-m': "monsters off", or * '-s0': 'ud.m_monsters_off' is *not* set

In 'GetCornerPoints()', fix condition for when to use 'get_floorspr_points()' to include sloped sprites as well.

(More precisely, in renderDrawMasks()'s check "does the maskwall separate the tsprite center from the camera?".) This provides more reasonable rendering order when the sprite (as drawn) is heavily biased to one side of the maskwall. Note [1]: mask/mask intersections are in general problematic since there is no further subdivision. For opaque objects, the OpenGL modes "work around" the issue thanks to the depth buffer. See: - 'mask_drawing_order.map', the STEAM sprites which by position are all on the other side of the right-hand side fence, but as drawn may or may not be more towards one particular side. (The topmost one with xoffset 50 is the first to be drawn behind it; note that 'picanm[STEAM].xofs == -47'.) - Issue #136, the first example screenshot. However, there, the fence intersects the STEAM sprite quite exactly in the middle (as drawn), so note [1] above applies.

We may have gotten an error message like: videoSetGamma(): Failed loading udev_device_get_action: (...)/libSDL2-2.0.so.0: undefined symbol: _udev_device_get_action But: 1. The "error" in question did actually happen earlier in SDL, but is harmless because SDL first tries to load a symbol using 'dlsym(RTLD_DEFAULT, ...)' and failing that (as it happens in my case), from an explicitly loaded libudev (which succeeds). 2. The message misleads a user into thinking that it may have something to do with gamma adjustment having no effect. (As is the case for me.)

See: https://github.com/zpl-c/zpl/pull/44 https://github.com/zpl-c/zpl/issues/45

This fixes a bug reported by Micky C on 2016-01-11 where too few points were marked to be inserted. See AMC TC SVN r2308.

The file descriptor was closed from Lua code, causing the subsequent kfilelength() to fail and attempt an allocation of (size_t)-1 bytes.

The block is taken over verbatim; 'vec3_t srcvect' is passed by value. The primary purpose of this is that it's easier to compare custom projectile behavior in A_ShootCustom() with the hardcoded one by reading the code of these two functions. For example, this may be of use to modders wishing to emulate a hardcoded projectile. DONT_BUILD.

Make it always one of the colors that the 2D color cycles to (base color + offset in [0 .. 4]) instead of <base color>-3, as that one might be in a different color ramp.

This makes it possible to set up editor colors at startup (from m32_autoexec.cfg). For example: script_expertmode 1 do for i range 256 ifge i 33 { set editorcolors[i] i } script_expertmode 0 Use this method in the description of how to get old-style 2D colors in tiles.cfg and suggest an alternative color index pair.

Without an argument, it prints the current state.

DONT_BUILD.

- bump MAX_TILE_GROUP_ENTRIES to MAXUSERTILES - in loadtilegroups(), only assign a tile color if it wasn't already assigned - allow "hidden" tile groups by omitting the hotkey - Tweak the description added to tiles.cfg

Meaning tilegroup's 'colors' directive. Also, to the packaged tiles.cfg, add a description of how to emulate the earlier Mapster32 sprite coloring for one tile group.

- draw ticks above the palette "ruler" - draw all editor colors (colors in editorcolor[])

<col> is the editorcolor[] starting index <idx> is the actual color index start <idxend> is the actual color index end So, editor colors from <col> onward will be mapped to [<idx> .. min(<idxend>, 255)]. Takes precedence over '2dcol'.

Also a similar stylistic tweak in parsetilegroups().

The problem is that it stays a few seconds afterwards, obscuring information on the status line.

Currently, this checks for effector sprites that are not face-aligned. See https://forums.duke4.net/topic/8324-icestation-colossus-map-broken

At the very least, this makes it easier to decide for one option ("Connect yellow ceiling w/ blue floor (1) or (v)ice versa?") when one of the differences is zero, which might have occurred from temporarily breaking TROR links.

The latter allows one to specify a color to keep, but with r5302 the fillsector() highlights are drawn with transparency, thus making it ineffective. Add an argument to toggle transparency to fillsector() (now fillsector_maybetrans()) and two wrapper functions.

This feature only makes sense with the complete de-selection of a set of sectors, i.e. when pressing RAlt to do this, not adding or removing sectors to/from the set of already highlighted ones.

For values that are displayed in hex. Patch by The Mechanic, with modifications.

Bug noticed and fix located by The Mechanic.

Similarly to how -5 and -7 and are accepted since r3859.

At program start, text input is enabled anyway and it does not seem to have any adverse effects. However, disabling it after e.g. game save leads to the OSD not working properly any more: normal keys are passed via handleevent_pollsdl's SDL_TEXTINPUT case.

See that function for a list of what these do in the OSD.

To demonstrate and test that it can be modified from outside, and that these changes are kept with savegame restores.

With 3 modes: 0: auto-correction and warning disabled 1: auto-correction enabled (default, current behavior) 2: auto-correction and warning enabled

Also add "zshoot -4096 BOUNCEMINE" to lunatic/test/weaponvars.con to demonstrate that bouncemines can be shot.

There's no point, really. Since the bouncemine is immobile, the tsprites will all be overlaid at one point and show the same picture, as far as I can see. Worse, since r4876, the generated sprites may draw on top of the actual one. The former have their shade always set to sprite[t->owner].shade though, and will then appear fully bright (shade -127, since BOUNCEMINE sets it like this). This fixes issue number 4 from http://forums.duke4.net/topic/8042-five-minor-problems-report/

See r5024 and the added comment.

Also, prettify some ps->fric-related code. DONT_BUILD.

Except: - missing braces around initializer [-Wmissing-braces]: due to union-in-struct vec3f_t - comparison between signed and unsigned integer expressions [-Wsign-compare]: in polymer.c

I didn't produce a case when this could actually have happened, but reading the code, in the case of variable 'j' it seems possible with an empty map.

That is, in m32_is2d3dmode(), also check if 2d and 3d mode resultions are the same. Otherwise, oob writes (e.g. via tileinfo_doprint()) and other thinkable niceties may ensue.