[TerminX]

 Helixhorned, on 13 January 2014 - 01:42 PM, said:

Yes! It's like you two were speaking right out of my mind!



VOLUME and LEVEL are merely read-only aliases to the respective userdefs members. The general pattern is that you want to set these to affect commands that behave conditionally on them. So the real solution is to make the commands (in Lunatic: functions, for example in 'gv' if there's no better place for them) accept these conditioning values as arguments. For example, the Lunatic interface could (and probably will) look like that:

gv.currentLevel()  -- will be one-based, I think. It's just more natural that way because it's how everyone thinks of these
gv.currentEpisode()
gv.currentMapName([ep, lev])  -- this one returns the current map name if passed no args, or that of E<ep>L<lev>

I think having those be one-based is weird. What's the point of breaking from the established functionality and operation here? It seems like you're going out of your way to make a programming language seem less like a programming language and the result is merely another sticking point on the list of differences between Lunatic and CON. Why? I mean, we aren't shifting all the tile numbers up by one and calling tile 0 tile 1 because logically it's the "first" tile...

[Micky C]

Is it normal to be able to see masked walls through floor aligned sprites?

[Fox]

No, that's some bug with Eduke32. Unless the floor-aligned sprite is actually cut by the masked wall.

[Micky C]

It's not cutting the sprite. So it's a bug then, confirmed with the latest eduke32. I'd post a picture but it'd be a pretty big spoiler for what I'm working on.

Also since I updated to r 4240 (for all I know it could have started earlier), and it's still happening with 4260, sometimes when selecting a tile from the tile screen that shows already-used tiles, it actually uses the next tile up. E.g if I chose tile 245, it'll place tile 246 in game.

[Helixhorned]

 TerminX, on 15 January 2014 - 05:58 PM, said:

I think having those be one-based is weird. What's the point of breaking from the established functionality and operation here? It seems like you're going out of your way to make a programming language seem less like a programming language and the result is merely another sticking point on the list of differences between Lunatic and CON. Why? I mean, we aren't shifting all the tile numbers up by one and calling tile 0 tile 1 because logically it's the "first" tile...

There are some diffences between volume/level numbers and tile numbers. The former are usually (but not always) referred to using one as the base, as in "E1L1", while tile numberstiles are always unambiguously numbered. The thing is, if you're dealing with CON directives/commands that take the former, there are already inconsistencies, for example: definelevelname takes a 0-based episode index, music takes it 1-based. This already leads to confusion -- so scripting coders have to know which base a particular command uses anyway in the case of volume numbers.

I don't think such "cosmetic" tweaks make Lunatic more or less of a programming language. Look at it that way: if the tweak allows users to write shorter and/or clearer code, I consider it a good one. With E/L numbers, I guess that the two major use cases are 1) retrieving them for sticking them into another command (like the one getting the name of the current level, no difference in user code length) and 2) getting them for printing and comparison, like "local ep, lev = gv.currentEpisode(), gv.currentLevel(); if (ep==1 and lev==1) then ...". In the second example, I bet that most users unaware of ambiguities such as the definelevelname/music one would read this as "if the current level is E1L1", not "E2L2".

[Helixhorned]

 Plain Simple Garek, on 15 January 2014 - 09:24 PM, said:

I'd post a picture but it'd be a pretty big spoiler for what I'm working on.

Can't you extract only the relevant part? It's always good style to give developers minimal, or at least not too big test cases for reproducing a particular bug.

Edit: Also, is that in classic or in one of the GL renderers? Interestingly, better mask (i.e. sprite and masked wall) sorting is on Ken's list and that's also something I'd eventually be interested in tackling.

[Micky C]

Classic. I just sent you a PM. I'm afraid it is a pretty big test case, but then it only seems to happen after a certain distance.

[Helixhorned]

 Helixhorned, on 16 January 2014 - 03:46 AM, said:

Edit: Also, is that in classic or in one of the GL renderers? Interestingly, better mask (i.e. sprite and masked wall) sorting is on Ken's list and that's also something I'd eventually be interested in tackling.

Oops, I shouldn't have been so fast to blame Ken. The example you PM'd me displays perfectly fine in Duke3D 1.5!

[Helixhorned]

Alright... remember this bug with masked walls? Well, it turns out the "fix" I did for that one makes your issue appear! Now I have no excuse to hand it down to someone else (although everyone's invited to share their thoughts, of course).

Edit: continued here

[Jblade]

kind of a silly question, but there's no limit on the amount of 'redefinequotes' or 'quotes' we can use is there? I was thinking of adding sub-titles for ingame speech but just wanted to see if there's some limits around (actually is there a page holding all of the game's limits of stuff? The obvious ones like sectors are easily findable but I don't think there's anywhere that says the max amount of vars or arrays apart from the log files)

[Helixhorned]

We have

#define MAXQUOTES 16384  // The last couple of hundred are reserved for internal use! Let's say, 0..15999 is for users.
#define MAXGAMEVARS 2048
#define MAXGAMEARRAYS (MAXGAMEVARS>>2)  // i.e. 512

[Jblade]

But there's no limit on redefinequote then I guess? or things like actor defines .etc .etc

[Hendricks266]

There is no limit on "redefinequotes" though, since there is no limit to compiled CON size.

[Hendricks266]

The limit on labels is MAXSPRITES*sizeof(spritetype)/64. For the raised V8 limits, it is 11264, and for the V7 old limits, it is 2816.

sizeof(spritetype) == 44

I don't know why this particular limit is in place.

[Helixhorned]

Hendricks266, on 18 January 2014 - 04:35 AM, said:

The limit on labels is MAXSPRITES*sizeof(spritetype)/64. For the raised V8 limits, it is 11264, and for the V7 old limits, it is 2816.

sizeof(spritetype) == 44

I don't know why this particular limit is in place.

It's because C-CON uses sprite[] as temporary storage for the labels instead of allocating its own memory. Such "memory-saving tricks" probably mattered back then, but it's problematic as it makes the limit depend on how EDuke32 is built: I remember zykov eddy actually stumbling into it on Wii, with his Sonic 3D mod. If you let me do a bit advertising, LunaCON doesn't have an arbitrary limit on the number of defined labels.

[Jblade]

Alright, so forgive my ignorance here but what is a label ingame exactly? Is it giving an actor a name via a define or something? or using an action?

[Fox]

A label is when you use define command.

Edit:



I can only make the loading bar work if the value is exposed in CON. =/

[Jblade]

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.

[Helixhorned]

James, on 18 January 2014 - 05:00 AM, said:

Alright, so forgive my ignorance here but what is a label ingame exactly? Is it giving an actor a name via a define or something? or using an action?

A label is merely a means of giving names integer values at CON translation time. By the time the game runs, they're not "present" any more: the bytecode contains the numbers literally. In other words, they're purely a convenience feature for humans; every CON code can be rewritten to equivalent code without using define at all. Moves and actions are different: they're mappings of a name to a tuple of numbers, and there's no syntax for literal ones (except that 0 and 1 are legal and are occasionally used for initialization purposes).

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