[Hendricks266]

I guess with the introduction of MapArt, I need to start work on my ART tool.

[Helixhorned]

James, on 18 January 2014 - 12:53 PM, said:

Just found a bug - the art files stop working if you save and load a map (apart from that though it's really handy, thanks for taking the time to do this)

The following works for me, assuming the folowing files are present in ~/.eduke32/0usermaps/02013: Torment.map, Torment_00.art:

- Start the Torment.map user map. The path by which it is known to the engine will be /0usermaps/02013/Torment.map (on Linux, ~/.eduke32 is added to the search path automatically unless -usecwd is provided).
- That map shows up fine.
- Save the game.
- Start E1L1.
- Load the savegame with Torment.map.
- Still shows up fine...

So: how exactly do they "stop working" in your case? Where are the files located (file system, GRP, ZIP)? What's the cache1-path of the usermap you're trying this on? It's the fading one shown at startup.

[Jblade]

It's all in the same directory, you have access to the AMC TC SVN so you can check it out to see for yourself. I save a game in the fish.map level looking at the custom art, load the save (without changing level) and it's gone.

Attached thumbnail(s)

• 

[Helixhorned]

I see. The issue here is that FISH.map isn't recognized as a user map in AMC TC because it's registered as "proper" map with definelevelname. As a consequence, the map name doesn't get saved in savegames, and when it's loaded again, the engine doesn't know the basename to suffix the '_XX.art' onto. I agree that it's kind of a bug and that at least FISH_00.art shouldn't be loaded in the first place.

However, I think you don't need MapArt at all if your maps will only ever be distributed with AMC TC. There's plenty of tile indices, so just use the normal ART files to your liking. For example, it's entirely possible to have one TILESxxx.ART for each map's unique art without MapArt: just give it an unused 'xxx' number (020 .. 199, but you should start from the lower numbers). As Hendricks said, the 'xxx' numbers relate to the tile numbers contained in an ART file only by convention. Nothing forces you to have TILES<i>.ART contain tiles [256*i .. 256*i+255] -- in fact, it can be any valid range of tile indices. Another way to structure your ART files would be by theme, for maybe easier mapping.

So, in essence, MapArt is mostly designed to ease "installation" of stand-alone user maps containing custom ART, namely to do away with it entirely. Only in the case of already released maps users have to rename shipped TILESxxx.ART to <mapname>_XX.art.

[Jblade]

Fair enough, that makes sense. It seemed like a useful thing to have for tiles that would only appear once or twice in the TC, but I can make do with adding them to the default art tiles proper.

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