[Fox]

I heard Eduke supports texture-based mirrors. How I do that?

Edit: nevermind

[Helixhorned]

What do you mean by that? Mirrors that are overlaid with some translucent texture? Can't that be done with just having a one-sided masked wall (Shift+[M], not to be confused with 1-sided wall, key [1]) slightly displaced from the mirror wall? To my knowledge, the mirror wall must always have overpicnum MIRROR, since that's how it's marked as being one.

Edit: Oh, you mean reflective surfaces like in the famous Polymer screenshot? Well, that feature lacks an interface, i.e. how to specify that property in terms of Build structure members.

[Micky C]

Why doesn't alignment work on 'bottom texture swapped' textures? In some cases this can create a lot of manual work.

And I can't remember if I've said this before but is it normal behavior that when there are multiple cracks with the same hitag and you blow one crack up, the others aren't collapsed? It doesn't make much sense and can be impractical whereas I can't see any benefits to keeping this behavior.

[Helixhorned]

Plain Simple Garek, on 23 January 2014 - 10:36 PM, said:

Why doesn't alignment work on 'bottom texture swapped' textures? In some cases this can create a lot of manual work.

Noone asked; implemented without much testing in r4265.

[Jblade]

Just a little thing, would it be possible to tweak the sound/music options so that hitting the use button or whatever on them will turn them on and off? They were replaced with sliding bars at some point which means if you want to turn one off you gotta crank it all the way to the left and back again when you need to re-activate it, whereas the old way you could just hit the music or sound on button and be done in like less than a second.

[TerminX]

I don't think that behavior is really conducive to the expected operation of a slider... however, there are snd_enabled and mus_enabled cvars that still exist along with a "toggle" console command. Just set up a key bind to turn them on and off at will.

[LeoD]

make USE_OPENGL=0 fails to build (again):

Spoiler

src/engine.c: In function 'drawmasks':ine.o...
src/engine.c:9257:18: error: 'modelp' undeclared (first use in this function)
             if (!modelp)
                  ^
src/engine.c:9257:18: note: each undeclared identifier is reported only once for each function it appears in
src/engine.c: In function 'E_MapArt_Clear':
src/engine.c:9923:5: error: implicit declaration of function 'gltexinvalidatetype' [-Werror=implicit-function-declaration]
     gltexinvalidatetype(INVALIDATE_ART);
     ^
src/engine.c:9923:25: error: 'INVALIDATE_ART' undeclared (first use in this function)
     gltexinvalidatetype(INVALIDATE_ART);
                         ^
src/engine.c: In function 'E_MapArt_Setup':
src/engine.c:9981:25: error: 'INVALIDATE_ART' undeclared (first use in this function)
     gltexinvalidatetype(INVALIDATE_ART);
                         ^
cc1.exe: some warnings being treated as errors
Failed building ../source/eobj_win/engine.o from src/engine.c!
make[1]: *** [../source/eobj_win/engine.o] Error 1
make: *** [enginelib] Error 2

[Micky C]

I'd just like to congratulate the eduke devs on Megaton's current shading system. It looks like it's using eduke's polymost usetileshades method but whatever the case it looks fantastic and natural.

[TerminX]

Yeah, they paid Hendricks to merge my code for that in after I and a few others were vocal enough about it. It's important for maps to look the same in different renderers across different ports. It uses some variant of r_usenewshading as well.

[MusicallyInspired]

Nice!

[Fox]

TerminX, on 29 January 2014 - 06:19 PM, said:

they paid Hendricks to

I feel like that's kinda weird, but at least it's a slap in the face of his parents.

[Hendricks266]

I sent some of it along to TX and Helix.

[Fox]

Hendricks266, on 11 January 2014 - 03:13 AM, said:

Userdef isn't transmitted over the network. It stays local to the current machine. If there's anything you need to transmit, you'll have to roll your own playervars and/or signal system. Also keep in mind that client-server architecture means that only the server has an actual copy of the game logic running, while the clients just have visuals.

May I ask, how exactly does that work? At least using Bots I have noticed several instances of the game returning or modifying the userdef of another player (with unfortunate results).

Here is a case of use:

onevent EVENT_DISPLAYREST
  getuserdef[THISACTOR].statusbarscale temp
endevent

If you press K to view another player screen, it doesn't work as expected.

[TerminX]

Getuserdef doesn't take anything within braces (there is only one local player, so there is nothing to index). The expected operation is that you would get the same result no matter where getuserdef was used. It's equivalent to copying data out of a global gamevar.

[Fox]

Yes, that's how I expected it worked, like a global variable with questionable multiplayer synchronization. But that's not the result I am having with the bots.

[Radar]

Fox, on 29 January 2014 - 11:40 PM, said:

I feel like that's kinda weird, but at least it's a slap in the face of his parents.

Why is that a good thing?

[TerminX]

Fox, on 31 January 2014 - 05:54 AM, said:

Yes, that's how I expected it worked, like a global variable with questionable multiplayer synchronization. But that's not the result I am having with the bots.

It's the only result you can get if your code using it is correct.

Pinkamena Diane Pie, on 31 January 2014 - 06:06 AM, said:

Why is that a good thing?

Maybe his parents don't think his hobby is worth anything?

[Fox]

What am I doing wrong then?

onevent EVENT_DISPLAYREST
  getuserdef[THISACTOR].statusbarscale temp
endevent

[TerminX]

For one, the syntax is wrong... it's just getuserdef.statusbarscale, no braces of any kind recognized or supported... ANYTHING between "getuserdef" and the period separating it and the member is completely ignored. Anything further than that and I'd have to look at how you're actually using the value. Keep in mind that it only works in events (or actors... I guess) with a player context and only when that player context matches the local machine. Anything else is like nullop.

[Fox]

Here is the context:

onevent EVENT_DISPLAYREST
  getuserdef[THISACTOR].statusbarscale temp
  redefinequote 0 %ld
  qsprintf 0 0 temp
  gametext STARTALPHANUM 10 10 0 0 0 0 0 0 xdim ydim
endevent

It prints the value at top left of the screen. For some reason it is not correct when you press K to show other player view.

TerminX, on 31 January 2014 - 10:07 AM, said:

For one, the syntax is wrong... it's just getuserdef.statusbarscale, no braces of any kind recognized or supported...

I will update the Wiki.

[Hendricks266]

TerminX, on 31 January 2014 - 10:07 AM, said:

Anything else is like nullop.

Could temp be inheriting a value from its previous use?

[Fox]

That's what it appears.

[Helixhorned]

TerminX, on 31 January 2014 - 10:07 AM, said:

Keep in mind that it only works in events (or actors... I guess) with a player context and only when that player context matches the local machine. Anything else is like nullop.

Interesting, I missed that tidbit in LunaCON. Now, it errors when trying to access userdef with a non-local current player. I think that's more useful to a CON coder than silently doing nothing.

Quote

For one, the syntax is wrong... it's just getuserdef.statusbarscale, no braces of any kind recognized or supported... ANYTHING between "getuserdef" and the period separating it and the member is completely ignored.

One small note: there must be whitespace between 'getuserdef' and '.xxx'.
The index is ignored, but it's accepted (even if misleading) syntax.

Hendricks266, on 31 January 2014 - 11:21 AM, said:

Could temp be inheriting a value from its previous use?

Fox, on 31 January 2014 - 11:31 AM, said:

That's what it appears.

That's consistent with what TX said. After pressing [K], screenpeek isn't equal to myconnectindex, and any userdef access is a logical error.

[Fox]

Well, it shouldn't. It makes userdef works like a global variable that is unavailable under certain circumstances. In this case, the HUD cannot be properly displayed when showing another player view.

Helixhorned, on 31 January 2014 - 01:35 PM, said:

One small note: there must be whitespace between 'getuserdef' and '.xxx'.

So it still requires you to type something where the index should go? I think I will go with getuserdef[].xxx then.

[Helixhorned]

Fox, on 31 January 2014 - 01:44 PM, said:

Well, it shouldn't. It makes userdef works like a global variable

Userdef is global. Go to the EDuke32 source and jump to the definition of 'ud'.

user_defs ud;

Jumping to the definition of the 'user_defs' type then,

typedef struct {
#if !defined LUNATIC
    vec3_t camerapos;
#endif
    int32_t const_visibility,uw_framerate;
(...)
    struct {
        int32_t UseJoystick;
(...)
        int32_t useprecache;
    } config;
(...)
    char show_level_text;
} user_defs;

There's nowhere an array of length MAXPLAYERS to be seen. Userdefs is just that: a container for various settings for the local player. As noted earlier, it throws together unrelated stuff and could have been organized better.

Quote

that is unavailable under certain circumstances. In this case, the HUD cannot be properly displayed when showing another player view.

Arguably, the current behavior is too strict. For example, you can't read ud.level_number or ud.volume_number then, even though they're always identical on all peers and can be obtained with LEVEL and VOLUME without restriction.
I can revert the check in LunaCON and make it always accessible like before. The strict behavior would then be enabled with something like -Werror-nonlocal-userdef.

Quote

So it still requires you to type something where the index should go? I think I will go with getuserdef[].xxx then.

You can go with just "getuserdef .xxx". The space is important.

[Fox]

Then most of the problems I was having while testing fake multiplayer with Duke 64 Mod was because of this. I don't really see a reason why userdef should be unavailable in some cases if it is, well, global.

[Helixhorned]

Alright, for LunaCON, I settled to having the error enabled by default, but with the possibility of unrestricted read access using -fno-error-nonlocal-userdef.

[Fox]

What about C-CON?

[TerminX]

I guess it would make sense to turn it into a console-spamming warning instead of just silently failing like it does now.

Helixhorned, why is precache noted as "of questionable use" in the LunaCON documentation? It's pretty much required if you want to make a mod with a bunch of flashy hi-res effect sprites and don't want the player lagging the first time the effect triggers on their machine. It's not programmed very well (it's within the limitations of CON and existing Duke modding conventions) but it is certainly useful!

[Helixhorned]

When I wrote that, I found that 'precache' was too much "looking into the guts of EDuke32" and that the game should figure out the tiles to precache itself. But you're right, that's not feasible, since which tiles get spawned can depend on arbitrarily complex scripting code. The case you describe (picnum wasn't there in the initial map) is probably the #1 reason for hightile loads happening when you're already playing.