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

[TerminX]

Something between 4280 and 4284 is breaking yellow keycard locks, haven't had a chance to really diagnose it yet.

Edit: nm, found it.

[Fox]

For the sake of saving some memory, shouldn't the game not compile gamevars (not pre-defined) if they aren't used in the CON? Of course all unused gamevars should be removed from CONs as of now, but this optimization wouldn't hurt.

[Hendricks266]

I was already contemplating an optimization pass to cover

1. demoting per-actor and per-player gamevars to global when it can be determined their per-actor/player status is unused
2. automatically identifying whether individual gamevars need to be transmitted over the network or not

so unused variable removal would fit right in. Anything else you can think of?

[Fox]

I had like to have a new command to define gamevars that can specify the size. It's common to use a gamevar for a simply yes or no check, and 32-bits is a waste...

[TerminX]

Hendricks266, on 06 February 2014 - 11:45 AM, said:

2. automatically identifying whether individual gamevars need to be transmitted over the network or not

Negative on that one... clients will not be executing CON code in the same way the server does at all, so there's not much identification to be done. Clients will run display events but it's not logically going to work to just flag every variable accessed within a display event. People programming multiplayer mods will be expected to organize their game state data in such a way that small bits can be passed to the client as hints to guide the client's simulation of the server state.

Shit, it's almost like people will be expected to utilize actual programming techniques where EDuke32 doesn't hold your hand and just doing whatever you want will give poor results.

[Fox]

TerminX, on 06 February 2014 - 02:07 PM, said:

clients will not be executing CON code in the same way the server does at all, so there's not much identification to be done.

Please provide a pratical example, I want to understand how that will work.

[Jblade]

It doesn't sound much different from the sync days where it just required testing to get things to work properly. We'd play a game of the AMC TC, it would sync out at some point, we'd try and recreate it and then I'd go in and fix it. It's a pain but if you want to code multiplayer than you'll need someone else...and I imagine it's not worth working on till the new multiplayer is actually here (apart from common practices like keeping display variables seperate from gameplay stuff, .etc)

[Hendricks266]

TerminX, on 06 February 2014 - 02:07 PM, said:

Negative on that one... clients will not be executing CON code in the same way the server does at all, so there's not much identification to be done. Clients will run display events but it's not logically going to work to just flag every variable accessed within a display event. People programming multiplayer mods will be expected to organize their game state data in such a way that small bits can be passed to the client as hints to guide the client's simulation of the server state.

I insist you hear me out.

The identification would happen on the server side. The identification code for network transmission would work much like my idea for per-actor-->global demotion. By default, the transmit status of all gamevars would be false. Gamevars used in display events would be marked true. Then, any gamevar for which its first use in all delimited blocks discards the current value (like a get<struct> or setvar command) is marked false.

I assume the primary issue is keeping the size of packets as small as possible. To that end, gamevars would get a tracker system much like what the map structs have so that they are only transmitted when modified.

If the CON scripts have a fuckton of variables that never change (the ubiquitous make variables for every parameter passed to rotatesprite) then said constants would only be transmitted one time, when gamevars are initialized, even though they would be flagged as "transmit".

A secondary issue is that network transmission may not be sufficient for certain variables, such as weaponcount. However, addressing this issue is separate from automatic gamevar network transmission.

The only circumstance that I can see where my idea would be outright "negative" would be if client screen implementation was redesigned in such a way as to require all-new CON structure (requiring updates for ALL display mods to function over the network), such as an event where variables like weaponcount can be augmented whenever the client performs a "fake" game tic (basically a cut-down "onevent EVENT_GAME ifactor APLAYER { } endevent"), and therefore any and all existing gamevars would be useless to transmit over the network.

[Helixhorned]

Fox, on 06 February 2014 - 11:22 AM, said:

For the sake of saving some memory, shouldn't the game not compile gamevars (not pre-defined) if they aren't used in the CON? Of course all unused gamevars should be removed from CONs as of now, but this optimization wouldn't hurt.

Good idea with finding these. Starting with r4299, LunaCON adds two new warnings, -Wnever-used-gamevar and -Wnever-read-gamevar. They are not enabled by default: many CON mods in the wild contain a spamgenic amount of these gamevars. Also, they are not automatically removed from the code: memory-wise, what matters most are per-actor gamevars in C-CON. In LunaCON, they're implemented in a sparse fashion, meaning that they only use an amount of memory roughy proportional to the number of non-default values stored in it.

Fox, on 06 February 2014 - 12:35 PM, said:

I had like to have a new command to define gamevars that can specify the size. It's common to use a gamevar for a simply yes or no check, and 32-bits is a waste...

For the occasional global gamevar, you shouldn't feel bad using a 32-bit int even if it's only used in a boolean sense; the memory "waste" is negligibe. Again, if you want an array of booleans, using a CON gamearray (or per-something gamevar) is suboptimal. However, there's a simple trick: just consolidate up to 32 variables into one by using bit-wise operations. Like this:

gamevar tmp 0 0
gamevar actorprop 0 2  // various per-actor boolean properties

define APROP_ISAPIG 1
define APROP_CANFLY 2
define APROP_VERYDANGEROUS 4

useractor PIGCOP // ...
    getactorvar[THISACTOR].actorprop tmp
    orvar tmp APROP_ISAPIG
    ifvare sprite[THISACTOR].pal 21
        orvar tmp APROP_CANFLY
    setactorvar[THISACTOR].actorprop tmp
enda

(Untested, but you get the idea...)

[Fox]

I already use that trick, but there are cases at which it is not possible. Also it's not just with booleans, for example there are gamevars to store an actor owner or tags which don't require 32-bits.

But I do realize now a problem with what I was asking, here is an example:

  getplayer[THISACTOR].random_club_frame shade
  andvar shade 2047
  sin shade shade
  mulvar shade -1
  addvar shade 16384
  divvar shade 1024

This is the code I use to make the Shrinker / Expander crystal glowing... while at first I would assume shade is a gamevar that would only require 8-bits, on practice I use it for some calculation that overcome that limit for the sake of not using temporary variables. So the limit on gamevars should be reinforced only at the end of the actor / event, and I am not sure how feasible that is.

[TerminX]

Hendricks266, on 06 February 2014 - 04:55 PM, said:

The only circumstance that I can see where my idea would be outright "negative" would be if client screen implementation was redesigned in such a way as to require all-new CON structure (requiring updates for ALL display mods to function over the network), such as an event where variables like weaponcount can be augmented whenever the client performs a "fake" game tic (basically a cut-down "onevent EVENT_GAME ifactor APLAYER { } endevent"), and therefore any and all existing gamevars would be useless to transmit over the network.

This is pretty much the case. Nearly every mod will require updates to be usable with EDuke32 multiplayer... it just is what it is. None of them are programmed with any of the restrictions in mind that apply to a client/server setup where updates are actually transmitted, instead of events simply being expected to occur in an identical fashion on all players. Some of the stuff CON lets you do is just not going to be compatible with this.

[Jblade]

Where do we get a lunatic build of mapster? The things on the synthesis only have the eduke32 exe and the normal SDK doesn't contain any kind of lunatic mapster.

[Fox]

So I noticed that now the bonus screen says "N/A" if there are none (or negative?) enemies left. Wouldn't it be better to fix the whole messed up kill count instead? I see, it's the Damn I'm Good skill.

[Jblade]

Just asking again, where do we get a mapster32 build with lunatic? The zips on the synthesis don't contain any mapster32 exes.

[Micky C]

There are separate lunatic zips in each synthesis folder. I don't blame you for missing it because quite frankly it's hard to navigate that thing with all those file names that are virtually identical but with slight differences.

[Jblade]

Micky C, on 12 February 2014 - 03:07 AM, said:

There are separate lunatic zips in each synthesis folder. I don't blame you for missing it because quite frankly it's hard to navigate that thing with all those file names that are virtually identical but with slight differences.

The only lunatic zips I see are 32bit and 64bit versions, with no mention of a mapster32 version. If there's a direct link I'd love to have it, since if this new additive/blending modes still work with CON than it'll be invaluable.

[Micky C]

You're right, there is no mapster32.

I have to say, the whole separated-out structure of the SVN is a real mess at the moment, there has to be a better way to organize/present it. There are loads of people on the megaton forums asking "where's mapster32?" since it's not included any more, and there's no indication there's a separate zip(s) on the eduke32 website.

[Nukey]

Separating mapster32 at all was a bad idea.

[The Commander]

Micky C, on 12 February 2014 - 03:51 AM, said:

You're right, there is no mapster32.

I have to say, the whole separated-out structure of the SVN is a real mess at the moment, there has to be a better way to organize/present it. There are loads of people on the megaton forums asking "where's mapster32?" since it's not included any more, and there's no indication there's a separate zip(s) on the eduke32 website.

Nukey, on 12 February 2014 - 09:05 AM, said:

Separating mapster32 at all was a bad idea.