[Plagman]

Fixed!

[Fox]

Any chance of having sloped sprites in the future? Or is it just too complicated?

[Diaz]

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

This means an enemy (or any other sprite) with a different palette (for example the grey cultists I ripped from Blood, which are brown cultists with pal 13) will lose its pal if it's in a fogged sector. In the example I mentioned, now all grey cultists are brown.

Is this the new expected behavior or a bug?

Thanks.

[blizzart]

Diaz, on 01 June 2014 - 11:04 PM, said:

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

This means an enemy (or any other sprite) with a different palette (for example the grey cultists I ripped from Blood, which are brown cultists with pal 13) will lose its pal if it's in a fogged sector. In the example I mentioned, now all grey cultists are brown.

Is this the new expected behavior or a bug?

Thanks.

Try to press 'N' on those sprites, so that they keep their own shade and pal should work here.

[Micky C]

N doesn't ale them keep their pal, only their shade. Although I believe that it should make them keep their pal as well.

Diaz, there's a new fogpal feature for openGL which allows you to set a sector's fogpal independently of pal, using a previously unused sector tag. Can't remember which one though. Press F7 and see if there's anything new.

[Mike Norvak]

Diaz, on 01 June 2014 - 11:04 PM, said:

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

This means an enemy (or any other sprite) with a different palette (for example the grey cultists I ripped from Blood, which are brown cultists with pal 13) will lose its pal if it's in a fogged sector. In the example I mentioned, now all grey cultists are brown.

Is this the new expected behavior or a bug?

Thanks.

Yeah, I noticed it as well, on WGR there are pal 17 petrified enemies that don't look like gray stone on fogged sectors. It is definitely a bug.

[Diaz]

Mickey C, that's nice, but does that mean I have to go through all of my maps to change sector tags?

Though m32script could do the trick.. the new feature shouldn't break old maps/mods though, and it currently does.

[Kyanos]

Mike Norvak, on 02 June 2014 - 06:07 AM, said:

Yeah, I noticed it as well, on WGR there are pal 17 petrified enemies that don't look like gray stone on fogged sectors. It is definitely a bug.

That forgettable map foothold had lots of alt pal enemies in fog.

I've been beta testing some maps, and wanted to record screenshots of my level stats but it won't take a pic of the text, just the background sprite gets captured. (rev-4482) Not sure if it's a bug or even a big deal but I know Megaton lets me do it.

[Diaz]

I'm new to m32script, and this doesn't seem to work (to implement the new fogpal system in existing maps):

gamevar i 0 0
gamevar paltemp 0 0
gamevar isparallax 0 0


for i allsectors 
{
    ifge sector[i].floorpal 30
    {
        setvarvar isparallax sector[i].ceilingstat
        ifvarand isparallax 1 
        {
        }
        else
        {
            setvarvar paltemp sector[i].floorpal
            set sector[i].fogpal paltemp
            set sector[i].floorpal 0 
            set sector[i].ceilingpal 0
        }
    }
}

any idea why?

thanks!

[Helixhorned]

Diaz, on 01 June 2014 - 11:04 PM, said:

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

(...)

Is this the new expected behavior or a bug?

It's kind of a bug. It has nothing to do with the introduction of sector[].fogpal, but is a consequence r4335: the predicate that tells whether a sprite should take over the floor pal of its sector was changed with a then-unforeseen side effect. It only concerns nonzero pals that are not the default fog pals (26 .. 29 for the vanilla LOOKUP.DAT). More on that later.

Diaz, on 02 June 2014 - 07:23 AM, said:

I'm new to m32script, and this doesn't seem to work (to implement the new fogpal system in existing maps):

Please post the error output. It should be written out to mapster32.log.

[Diaz]

No error output, but the sectors are keeping their original palette and looks like the .fogpal member is not being written.

BTW, the sprites do keep their palette "internally" - pal 13 enemies behave like pal 13 enemies in CON code, for example. They just revert to pal 0 visually.

[Helixhorned]

Diaz, on 02 June 2014 - 08:23 AM, said:

No error output, but the sectors are keeping their original palette and looks like the .fogpal member is not being written.

If you're running Polymer, make sure you have ART mapping disabled: r_pr_artmapping 0. There, visibility/fog is done by looking up the shade table of each pal, there's no additional GL fog.

[Fox]

Is it possible to do something about the effect of linear filter in repeating textures? Flat sprites won't blend with the wall texture:

Spoiler

I believe that flat sprites should have the same default behavior as the level architecture. This won't look good in some cases like blood splats but it's the same for masked walls. This is also a problem for rotatesprite.

Maybe it could detected if one of the corners is transparent, at least it's a hack that would work for Duke 3D textures. But we should have the ability to define it for each texture individually.

[Hendricks266]

Why wouldn't you just use a masked wall there?

[Fox]

That's not the point, this is an hypothetical example.

[MetHy]

Version 4500 doesn't ask you whether or not you want to load your latest save when you die; it just loads it.

[Kyanos]

Also saves don't name themselves as the map name anymore... If I don't name a save it comes up empty and overwrites the old save with nothing.

added
So, I go back to the game and now the saves do exist but they are all named user map.

[Hendricks266]

Damn, and I thought the new save menus were all ironed out. Keep the bug reports coming.

[Fox]

Can you make saved games created with save command to be hidden? I.e. create an autosav#.esv file.

[Hendricks266]

No, because the point is that you're saving a game in a slot in the savegame menu.

[Jblade]

Would it be possible to determine if a player has line of sight with any part of a sector? Basically right now in the AMC TC I've got a system to manually deactivate the skybox whenever the player triggers a sector, for performance reasons. That's ok for maps which aren't too connected together, but there's a large map with lots of views to the outside and if there would be a way to find out if the player can see the skybox sectors (or maybe specifically the skybox texture?) it would be pretty cool.

Or in other words, if there was a way to determine if a specific texture was in the player's point of view, I could enable/disable the skybox based on that rather than the manual system we've got going now.

[Fox]

How the game determines if a sector is "visible" or not is a bit more complicated.

But are you using a regular skybox, or using rotatesprite/showview?

[Jblade]

I'm using the showview method.

[Fox]

It would require some new rendering time variable/event.

[MusicallyInspired]

Is there a place to download EDuke32 for Android yet? Can't seem to find it.

[Hendricks266]

It hasn't been released yet, but you can PM TX and Beloko for beta access.

[Hendricks266]

I have a bit of a "that's too damn bad!" change announcement today because it really needed correcting and it's recent enough that anyone affected could update their mod.

Quote

Add the following LOGO_FLAGS:
LOGO_NOE1ENDSCREEN
LOGO_NOE2ENDSCREEN
LOGO_NOE3RADLOGO
LOGO_NODUKETEAMTEXT
LOGO_NODUKETEAMPIC

As part of this, the LOGO_NOE*BONUSSCENE flags no longer remove the entire end sequence in one go. They now only remove the primary cinematic. If you want their previous effect, you'll have to add these additional bits.

LeoD, on 07 May 2014 - 04:13 PM, said:

Yup! make OPTOPT=-ffat-lto-objects does the trick for the time being!

This should be automatically provided now when GCC 4.9 is detected. CUSTOMOPT is also fixed.

[Daedolon]

F12 doesn't work in BONUSSCREEN.
Console won't be drawn on top of ANM.
Alt-tabbing out and back in during a 1-frame ANM (DUKETEAM, etc.) results in a blank screen (displays whatever Windows has below the game screen).

[Jblade]

How does the base game's AI work? is there an article or something somewhere? I mean obviously not the CON code stuff, but more like what exactly seekplayer and all that stuff does from the code's point of view. is it literally just "look in the player's direction and move towards it with random adjustments" or is it more complex? It's still a pain in the ass to get proper friendly AI going on (and visa versa) compared to Doom (I know that has got built in enemy vs enemy stuff due to the infighting)

Also, when exactly am I supposed to be applying Htflag 2048? (SFLAG_NOCLIP) because I'm applying it in the actor code and it's not working. I tried using the spriteflags command and that didn't seem to have any affect either.

[Mblackwell]

IIRC it doesn't make a noclip actor exactly. It skips a check internally (basically equivalent to setting clipmask to 0) which speeds things up for objects that the inaccuracy/ability to pass through blocking sprites won't matter for like particles.