[Helixhorned]

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

The reality of the situation is that userdef is a hodgepodge of shit that doesn't belong in the same struct.

TerminX, on 11 January 2014 - 04:33 AM, said:

That right there is the problem with just exposing internal structures en masse without any sort of thought into a sane interface. The bits you've pointed out are good use cases (except for screen_size... more on that in a minute), but moreover they're things that probably don't belong in userdef in the first place. There's zero logic in having user preferences controlled by menu options right there next to internal variables that control game states and level progression.

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

Fox, on 11 January 2014 - 08:43 AM, said:

There are some userdef structures that I need to check or even set outside of unsynchronized events:
- player_skill
- god
- eog
- volume_number
- level_number
- noexits

Going by TerminX explanation a code that uses this would never work out in a real connection. The solution would be to add non-userdef alternatives like there are VOLUME or LEVEL variables?

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>

[Fox]

That's not how I am using it. Commands like starttrack or qgetsysstr are used in unsynchronized events, so setuserdef works just fine even if it was not meant to be used like that.

What I want to do is modify the end of level code. When the end of level is triggered, .gm is set to MODE_EOL, and it changes the values for .volume_number, .level_number and .eog. And to create my own end of level code I must undo all of these, which works fine for single-player but not multiplayer.

Edit: Well, I do need to set .eog so startlevel will end the game. It would require that command to accept -1 as an entry for the next level w/hich would end the game.

[Micky C]

I have a really messy situation in a map at the moment with some sprites and mapster script is by far the easiest way to clean it up. I have a super basic grasp of mapster script, e.g if I want to set a hitag for a bunch of selected sprites I'd write "do for i selsprites { set sprite[i].hitag XXX }" but how do I do it for only a certain tile number in the group of selected sprites? Also how do I change the angles? I can't seem to squeeze this information out of the script page on the wiki.

[Helixhorned]

Fox, on 13 January 2014 - 02:07 PM, said:

What I want to do is modify the end of level code. When the end of level is triggered, .gm is set to MODE_EOL, and it changes the values for .volume_number, .level_number and .eog. And to create my own end of level code I must undo all of these, (...)

See, that's the problem right there! You're not supposed to know all these internals details as a scripting coder! Rather, the scripting system should simply provide a function like "now, initiate the end of the level", and the hard-coded level ending should be cancelable in some way, maybe using an event, maybe something else. It's all about clear interfaces, good documentation and not exposing internals the user doesn't need to know about.

Quote

which works fine for single-player but not multiplayer.

Why to you even bother about multiplayer at this stage? It's not finished. The code you write now may cease to function as intended in the future. Similar issue here, really: it's not documented, so you can't really make any assumptions about it.

[Helixhorned]

Plain Simple Garek, on 14 January 2014 - 02:38 AM, said:

if I want to set a hitag for a bunch of selected sprites I'd write "do for i selsprites { set sprite[i].hitag XXX }" but how do I do it for only a certain tile number in the group of selected sprites?

do for i selsprites, ife .picum SOMEPIC, set .hitag XXX

Quote

Also how do I change the angles? I can't seem to squeeze this information out of the script page on the wiki.

The sprite member is called "ang". M32script descended from CON, so the it shares many aspects with it.

[Fox]

Helixhorned, on 14 January 2014 - 12:13 PM, said:

Why to you even bother about multiplayer at this stage? It's not finished. The code you write now may cease to function as intended in the future. Similar issue here, really: it's not documented, so you can't really make any assumptions about it.

I know, it's not a priority. But I hoped the game would at least work with fake multiplayer.

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