[Helixhorned]

James, on 18 January 2014 - 09:11 AM, said:

I just tried using the art tile replacement feature recently added - if I'm reading this right, it's saying you need to add from tiles00 to the number you're using, otherwise it'll abort? Because I tried to start from tiles018 and it didn't work, but when I replaced tiles000 it did work (the filenames are correct) I can't see how that's right if it's working as intended.

You have to name the ART file like the map base name, suffixed with '_00.art', '_01.art', etc. The first time a file in this sequence is not found, loading is aborted. That is, if you have MYMAP_00.art and MYMAP_02.art, only the first one gets loaded.

[Kyanos]

Helixhorned, on 18 January 2014 - 09:58 AM, said:

You have to name the ART file like the map base name, suffixed with '_00.art', '_01.art', etc. The first time a file in this sequence is not found, loading is aborted. That is, if you have MYMAP_00.art and MYMAP_02.art, only the first one gets loaded.

That's not how I expected it to work either. Most user maps with new art usually just come with a replacement for tiles014.art and tiles015.art, maybe some higher .art files too. Why does this system need every art tile to be loaded replaced per user map if most maps only replace those few?

[Jblade]

As drek said, I'm a bit confused here. I got tiles00 working ok as I said, but right now it looks like you need to go from 00 to whatever tile you want to replace (in my case 18, but in most usermaps it's 14/15)

[Hendricks266]

The number in the ART file name is independent from the starting tilenum. The starting tilenum is actually stored in binary inside the file. So if your myhouse.map had tiles014.art and tiles015.art, you would name it myhouse_00.art and myhouse_01.art.

[Jblade]

Oh sweet, yeah now that makes sense and it works. It's a fantastic feature but the blurb in the changelog didn't make that part too clear - I think the SDK could do with a example art tile with a map (just have a single new tile so the filesize is small)

[Jblade]

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)

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