
EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#4231 Posted 30 January 2014 - 06:35 AM
#4232 Posted 31 January 2014 - 05:54 AM
#4233 Posted 31 January 2014 - 07:25 AM
Fox, on 31 January 2014 - 05:54 AM, said:
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:
Maybe his parents don't think his hobby is worth anything?
#4234 Posted 31 January 2014 - 08:06 AM
onevent EVENT_DISPLAYREST getuserdef[THISACTOR].statusbarscale temp endevent
#4235 Posted 31 January 2014 - 10:07 AM
#4236 Posted 31 January 2014 - 10:29 AM
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:
I will update the Wiki.
This post has been edited by Fox: 31 January 2014 - 10:31 AM
#4237 Posted 31 January 2014 - 11:21 AM
TerminX, on 31 January 2014 - 10:07 AM, said:
Could temp be inheriting a value from its previous use?
#4238 Posted 31 January 2014 - 11:31 AM
This post has been edited by Fox: 31 January 2014 - 11:31 AM
#4239 Posted 31 January 2014 - 01:35 PM
TerminX, on 31 January 2014 - 10:07 AM, said:
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
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:
Fox, on 31 January 2014 - 11:31 AM, said:
That's consistent with what TX said. After pressing [K], screenpeek isn't equal to myconnectindex, and any userdef access is a logical error.
#4240 Posted 31 January 2014 - 01:44 PM
Helixhorned, on 31 January 2014 - 01:35 PM, said:
So it still requires you to type something where the index should go? I think I will go with getuserdef[].xxx then.
This post has been edited by Fox: 31 January 2014 - 03:58 PM
#4241 Posted 01 February 2014 - 02:11 AM
Fox, on 31 January 2014 - 01:44 PM, said:
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
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
You can go with just "getuserdef .xxx". The space is important.
#4242 Posted 01 February 2014 - 05:30 AM
#4243 Posted 01 February 2014 - 12:09 PM
#4245 Posted 01 February 2014 - 01:03 PM
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!
#4246 Posted 02 February 2014 - 02:59 AM
#4247 Posted 02 February 2014 - 02:11 PM
Edit: nm, found it.
#4248 Posted 06 February 2014 - 11:22 AM
This post has been edited by Fox: 06 February 2014 - 11:23 AM
#4249 Posted 06 February 2014 - 11:45 AM
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?
#4250 Posted 06 February 2014 - 12:35 PM
#4251 Posted 06 February 2014 - 02:07 PM
Hendricks266, on 06 February 2014 - 11:45 AM, 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.
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. :(
#4252 Posted 06 February 2014 - 02:32 PM
TerminX, on 06 February 2014 - 02:07 PM, said:
Please provide a pratical example, I want to understand how that will work.
#4253 Posted 06 February 2014 - 02:52 PM
This post has been edited by James: 06 February 2014 - 02:53 PM
#4254 Posted 06 February 2014 - 04:55 PM
TerminX, on 06 February 2014 - 02:07 PM, said:
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.
#4255 Posted 10 February 2014 - 02:28 AM
Fox, on 06 February 2014 - 11:22 AM, said:
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:
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...)
#4256 Posted 10 February 2014 - 10:11 AM
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.
This post has been edited by Fox: 10 February 2014 - 10:11 AM
#4257 Posted 10 February 2014 - 08:45 PM
Hendricks266, on 06 February 2014 - 04:55 PM, said:
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.
#4258 Posted 11 February 2014 - 11:29 AM
#4259 Posted 12 February 2014 - 01:22 AM
This post has been edited by Fox: 12 February 2014 - 03:25 AM