EDuke32 Scripting "CON coding help"
#1261 Posted 27 April 2013 - 11:58 AM
#1262 Posted 29 April 2013 - 11:53 AM
First I used the hitscan code that is on the wiki:
gamevar MY_X 0 1 gamevar MY_Y 0 1 gamevar MY_Z 0 1 gamevar MY_SECTOR 0 1 gamevar MY_ANGLE 0 1 gamevar MY_ZDIST 0 1 gamevar MY_COS 0 1 gamevar MY_SIN 0 1 gamevar HITSECTOR 0 1 gamevar HITWALL 0 1 gamevar HITSPRITE 0 1 gamevar HITX 0 1 gamevar HITY 0 1 gamevar HITZ 0 1 state checkhitscan getplayer[THISACTOR].posx MY_X getplayer[THISACTOR].posy MY_Y getplayer[THISACTOR].posz MY_Z getplayer[THISACTOR].cursectnum MY_SECTOR getplayer[THISACTOR].ang MY_ANGLE getplayer[THISACTOR].horiz MY_ZDIST subvar MY_ZDIST 100 mulvar MY_ZDIST -2048 cos MY_COS MY_ANGLE sin MY_SIN MY_ANGLE hitscan MY_X MY_Y MY_Z MY_SECTOR MY_COS MY_SIN MY_ZDIST HITSECTOR HITWALL HITSPRITE HITX HITY HITZ CLIPMASK1 ends
State checkhitscan is called constantly from within the APLAYER actor. Then I create an actor for the models:
spritenoshade 4577 eventloadactor 4577 getactor[THISACTOR].cstat TEMP5 ifvarand TEMP5 16 { getactor[THISACTOR].sectnum TEMP getsector[TEMP].floorpal TEMP7 setactor[THISACTOR].pal TEMP7 getactor[THISACTOR].shade ACTORFLOORSHADE getactor[THISACTOR].x TEMP2 getactor[THISACTOR].y TEMP3 getactor[THISACTOR].z TEMP4 } else { getactor[THISACTOR].sectnum TEMP getsector[TEMP].floorshade ACTORFLOORSHADE setactor[THISACTOR].shade ACTORFLOORSHADE getsector[TEMP].floorpal TEMP7 setactor[THISACTOR].pal TEMP7 getactor[THISACTOR].x TEMP2 getactor[THISACTOR].y TEMP3 getactor[THISACTOR].z TEMP4 } enda useractor notenemy 4577 // Stone column ldist TEMP6 THISACTOR player[THISACTOR].i ifvarl TEMP6 24000 { ifvarn HITSECTOR -1 ifvarn sector[HITSECTOR].lotag 2 changespritesect THISACTOR HITSECTOR setactor[THISACTOR].shade ACTORFLOORSHADE setactor[THISACTOR].pal TEMP7 setactor[THISACTOR].x TEMP2 setactor[THISACTOR].y TEMP3 setactor[THISACTOR].z TEMP4 } enda
So the sprite's sectnum is always the sector the player is looking at, and thus it won't disappear. I have to save and restore x,y,z, pal and shade or weird things will happen.
Let me know what you think - this hack may not be optimal but I've noticed no slowdowns or undesirable effects so far....
EDIT: There is indeed slowdown with a large number of actors running this code. So I have to limit the distance, and I think I will make the "fix" toggleable with some gamevar, so it can be turned off if flickering/disappearing models don't bother you.
This post has been edited by Diaz: 29 April 2013 - 02:27 PM
#1263 Posted 29 April 2013 - 12:05 PM
Besides you should never change the actor sectnum (risk of map corruption), use the tsprsectnum instead.
This post has been edited by Fox: 29 April 2013 - 12:06 PM
#1264 Posted 29 April 2013 - 12:27 PM
And using camerasect caused the actors to completely disappear from the map for some reason
The HITSECTOR value seems to be very reliable, and I was already using the hitscan state for other things anyways. The clipmask is set to blockable sprites though, might want to change that to sectors only for this case.
This post has been edited by Diaz: 29 April 2013 - 12:38 PM
#1265 Posted 29 April 2013 - 02:23 PM
Also camerasect is the current view point's sector. So from first person it's the player's current sector generally... so not what you want.
#1266 Posted 29 April 2013 - 02:38 PM
It's useful for big models that don't need collision.
This post has been edited by Diaz: 29 April 2013 - 02:39 PM
#1267 Posted 29 April 2013 - 02:52 PM
This post has been edited by Mark.: 29 April 2013 - 02:55 PM
#1268 Posted 29 April 2013 - 02:57 PM
This post has been edited by Diaz: 29 April 2013 - 02:57 PM
#1269 Posted 29 April 2013 - 03:25 PM
Diaz, on 29 April 2013 - 02:38 PM, said:
So you are actually changing the sectors and not setting it back? That's some massive fuckery since many functions depends on the sectnum.
This post has been edited by Fox: 29 April 2013 - 03:25 PM
#1270 Posted 29 April 2013 - 03:28 PM
But it would make no sense to reset the sectnum right after changing it - that would cause the code to have no effect at all.
#1271 Posted 29 April 2013 - 06:29 PM
This post has been edited by Fox: 29 April 2013 - 06:30 PM
#1273 Posted 30 April 2013 - 01:28 AM
I think I'm reverting to changing sectnums in actor code - after all, these are just static decoration models with no collision. I doubt changing their sectnum will do any harm.
#1274 Posted 30 April 2013 - 05:29 AM
Diaz, on 30 April 2013 - 01:28 AM, said:
I think I'm reverting to changing sectnums in actor code - after all, these are just static decoration models with no collision. I doubt changing their sectnum will do any harm.
You should give them a unique statnum and do it in a loop that runs every few frames from the player code. Not turning those sprites into actors will save you fps.
#1275 Posted 30 April 2013 - 07:04 AM
Diaz, on 30 April 2013 - 01:28 AM, said:
I think I'm reverting to changing sectnums in actor code - after all, these are just static decoration models with no collision. I doubt changing their sectnum will do any harm.
You may be making the hitscan check for each sprite?
#1276 Posted 30 April 2013 - 08:40 AM
Still, any loop is not really the most fps-effective solution - any reason I really shouldn't use the actor's code to change sectnums? It only happens within a range of 16000 units (original sectnum is restored outside that range), the actors are just static models with no collision or any other form of code, and the mod is Polymer only. I've noticed no side effects whatsoever, even after running the game for a long time, saving, reloading games, etc.
This post has been edited by Diaz: 30 April 2013 - 08:54 AM
#1277 Posted 30 April 2013 - 03:07 PM
#1278 Posted 01 May 2013 - 07:45 AM
So I guess it's working in an optimal way now. Thanks guys!
#1279 Posted 01 May 2013 - 10:19 AM
Fox, on 26 April 2013 - 03:59 PM, said:
include this line somewhere before your actor code...
gamevar TEMP 0 2
Where you see the command "fall" in your actor, replace with:
ifvare sector[THISACTOR].lotag 1 { iffloordistl 8 setactor[THISACTOR].zvel 0 getsector[THISACTOR].lotag TEMP setsector[THISACTOR].lotag 0 fall setsector[THISACTOR].lotag TEMP } else fall
The proposed hack is pretty good, but the advice to copy-paste a dozen of lines of code is not. One should always aim at reducing redundancy. In this particular case, it's easy: just put these lines into a CON state.
Trooper Dan, on 26 April 2013 - 10:58 PM, said:
These two refer to different aspects of water: Fox's hack would prevent wading in water and your proposal would stop teleporting the actor. I haven't tested either of them, though.
#1280 Posted 01 May 2013 - 06:48 PM
onevent EVENT_GAME setprojectile[KNEE].extra 100 endevent
Why?
#1281 Posted 01 May 2013 - 06:56 PM
#1282 Posted 01 May 2013 - 09:45 PM
Fox, on 01 May 2013 - 06:56 PM, said:
Correct, but he can mod it the old fashioned way.
In USER.CON, find:
define KNEE_WEAPON_STRENGTH 10
and change the value to 100
#1283 Posted 02 May 2013 - 12:03 PM
Trooper Dan, on 01 May 2013 - 09:45 PM, said:
In USER.CON, find:
define KNEE_WEAPON_STRENGTH 10
and change the value to 100
That isn't desirable because my mod is a collection of mutators. In the end, I just defined a new projectile.
#1284 Posted 02 May 2013 - 12:34 PM
actor KNEE <strength> enda
Of course an alternative is to redefine the KNEE using defineprojectile, but that way it would loose some hard-coded features, such as increasing the strength if you are using Steroids.
#1285 Posted 16 May 2013 - 12:00 AM
ifvare PERSONEL_RESEARCH[8] 2 // player has thermal weaving? reduce damage by 20% { setvarvar TEMP7 TEMP8 mulvar TEMP7 10 subvarvar TEMP7 TEMP8 subvarvar TEMP7 TEMP8 divvar TEMP7 10 setvarvar TEMP8 TEMP7 }
That should reduce it by 20% right?
#1286 Posted 16 May 2013 - 06:18 AM
#1287 Posted 16 May 2013 - 06:31 AM
#1289 Posted 16 May 2013 - 06:01 PM
So to add 20% you'd do X = (5 * 120) / 100
#1290 Posted 24 May 2013 - 08:57 AM
What bit 1024 is likely supposed to do is to prevent resetting the gamevar's value to the default/initial one on various occasions such as starting a new game. For global and per-player gamevars, it could be e.g. used to hold information about gained mod-wide achievements.[1] However, currently, the value of such gamevars would still be (always) restored by savegames or (if NORESET is clear) when restoring mapstates.
While I'm not sure whether to call it a bug (there was never a specification), I still think it's not the desired behavior. Suppose you kill the final boss and win $ 106 as an award, but because you liked the final fight so much, you load up the last savegame and attempt to beat it once more. This time, you fail though, and all your money is lost .
What I intend to do in LunaCON is to make NODEFAULT gamevars persist during the entire duration of a session, with the only option of restoring it being via readgamevar. (I'm not yet sure how the interaction with NORESET should be.) Because this is an externally visible change to gamevar behavior, I'll probably also backport it to C-CON. Are there any objections to this plan? It should be noted that in all the mods that I'm batch-testing CON-compilation on, there are only a total of four uses of that bit.
----------
[1]For per-actor gamevars, it has a somewhat technical use, the original one being rather meaningless. It can be set to prevent actor variables being reset on spawn (this includes the initial one from premap), so that they can be manipulated before: e.g. from eventloadactor code.