[Danukem]

I think you would have to disable the normal hardcoded function of the goggles entirely and code your own effect from scratch. I don't think there is a simple way to separate the overall palette change from the sprites appearing to be pal 6. You could try using setgamepalette to 0 (or 1 if you happen to be under water at that moment) to counteract the goggle palette, but like I said I think that would also make the sprites look normal.

[thisbecasper]

Danukem, on 10 February 2021 - 01:08 PM, said:

I think you would have to disable the normal hardcoded function of the goggles entirely and code your own effect from scratch. I don't think there is a simple way to separate the overall palette change from the sprites appearing to be pal 6. You could try using setgamepalette to 0 (or 1 if you happen to be under water at that moment) to counteract the goggle palette, but like I said I think that would also make the sprites look normal.

Damn, that was EXACTLY what I needed. Everything looks so normal I was confused the first time I turned them on. Looking at players in dark areas lights them up tho, and tripmines on mode 2 are visible too. Thanks!

[Danukem]

That's fortunate -- I thought that the brightness of the sprites would be linked to the changed game palette but apparently not. Do you have the palette switches working correctly under water?

[thisbecasper]

Danukem, on 11 February 2021 - 12:18 PM, said:

That's fortunate -- I thought that the brightness of the sprites would be linked to the changed game palette but apparently not. Do you have the palette switches working correctly under water?

Haven't thoroughly tested, we ain't DM'ing on maps with water. A 1 minute test, however, showed that setgamepalette 1 will probably make everything look normal underwater, but special stuff like players and tripmine lasers will still light up when goggles are on (just like above water/setgamepalette 0). In general, setgamepalette works properly on everything except the few things that has a special interaction with the goggles (if the goggles are on) - in other words: nothing looks weird.

Question: How do I "redefine" certain actors to do stuff I want? For example when I spawn OOZFILTER (1079) ingame I see nothing, but if I spawn 1080 (also oozfilter but without animation) it appears in the game. In my CON file I have a simple block: actor 1079 { do stuff... } enda. Some actors seem to be reserved but they are usually the more interesting ones...

[jimbob]

thisbecasper, on 12 February 2021 - 10:54 AM, said:

Haven't thoroughly tested, we ain't DM'ing on maps with water. A 1 minute test, however, showed that setgamepalette 1 will probably make everything look normal underwater, but special stuff like players and tripmine lasers will still light up when goggles are on (just like above water/setgamepalette 0). In general, setgamepalette works properly on everything except the few things that has a special interaction with the goggles (if the goggles are on) - in other words: nothing looks weird.

Question: How do I "redefine" certain actors to do stuff I want? For example when I spawn OOZFILTER (1079) ingame I see nothing, but if I spawn 1080 (also oozfilter but without animation) it appears in the game. In my CON file I have a simple block: actor 1079 { do stuff... } enda. Some actors seem to be reserved but they are usually the more interesting ones...

why would you want to repurpose existing actors? you can use useractor for new actors unless you are using duke1.3 wich i consider obsolete.

[thisbecasper]

jimbob, on 13 February 2021 - 09:21 AM, said:

why would you want to repurpose existing actors? you can use useractor for new actors unless you are using duke1.3 wich i consider obsolete.

Some existing actors are ones we wont encounter when playing DM, but have nice animations (e.g. OOZFILTER could be a new item to be picked up). Should I understand your reply as it can't be done, or how would I go about overwriting OOZFILTER? I've also not experimented with creating actors with animation myself, but the tiles that can make up an animation are usually an existing actor - I don't know if my point came across very well...

Maybe I am misunderstanding, does it make any difference having "useractor OOZFILTER ..." instead of "actor OOZFILTER ..."?

[Danukem]

To answer his question: A lot of sprites do not have a default coded size, and so when they are spawned they spawn with size 0 0. As a result, they are too small to see and usually they get deleted right away. With oozfilter and many other sprites, you have to either place them in the map, or you have to add code to make them have a certain size when they are spawned.

[thisbecasper]

Danukem, on 13 February 2021 - 09:46 AM, said:

To answer his question: A lot of sprites do not have a default coded size, and so when they are spawned they spawn with size 0 0. As a result, they are too small to see and usually they get deleted right away. With oozfilter and many other sprites, you have to either place them in the map, or you have to add code to make them have a certain size when they are spawned.

The first thing I do in the block is sizeat 24 24, and it works with tile 1080 (OOZFILTER being 1079). So sizeat does not help me when actor is tile #1079.

[Danukem]

thisbecasper, on 13 February 2021 - 09:55 AM, said:

The first thing I do in the block is sizeat 24 24, and it works with tile 1080 (OOZFILTER being 1079). So sizeat does not help me when actor is tile #1079.

Not sure what you mean by "the block" but OOZFILTER is hardcoded, it is not a scripted actor. So the correct approach if you want that size would be something like this:

appendevent EVENT_EGS

ifactor OOZFILTER sizeat 24 24

endevent

[thisbecasper]

Danukem, on 13 February 2021 - 10:02 AM, said:

Not sure what you mean by "the block" but OOZFILTER is hardcoded, it is not a scripted actor. So the correct approach if you want that size would be something like this:

appendevent EVENT_EGS

ifactor OOZFILTER sizeat 24 24

endevent

Does this mean that all my code regarding OOZFILTER has to go into the events, and that my "actor OOZFILTER ... enda" block is ignored completely because, as you said, OOZFILTER is hardcoded?

[Danukem]

thisbecasper, on 13 February 2021 - 10:05 AM, said:

Does this mean that all my code regarding OOZFILTER has to go into the events, and that my "actor OOZFILTER ... enda" block is ignored completely because, as you said, OOZFILTER is hardcoded?

It might be ignored completely, yeah. But I can tell you for certain that code I posted above works. If you want it to use your code instead you would probably need to change the statnum to 1.

[jimbob]

thisbecasper, on 13 February 2021 - 09:45 AM, said:

Some existing actors are ones we wont encounter when playing DM, but have nice animations (e.g. OOZFILTER could be a new item to be picked up). Should I understand your reply as it can't be done, or how would I go about overwriting OOZFILTER? I've also not experimented with creating actors with animation myself, but the tiles that can make up an animation are usually an existing actor - I don't know if my point came across very well...

Maybe I am misunderstanding, does it make any difference having "useractor OOZFILTER ..." instead of "actor OOZFILTER ..."?

i still dont quite get what you want to do, if you want a new pickup, but use the oozefilter' animation you could create a new actor, make some rudimentary art for it ( doesnt matter how ugle, you wont see it ) and set the action to the value of your actor - the first animation frame of the oozefilter and set up the rest accordingly ( if it has 4 animation frames set it up as such ) and then add your code for picking the item up like you would on any other pickup.

so for example, you create a new useractor like

define MYPICKUPACTOR **** where **** is the arttile you import

action MYPICKUPANIMATION ***** - 1079 for oozefilter, so say my art is 3000, then 3000 - 1079 = 1921, so the first frame has an offset of -1921
and your all set, the animation is 'hardcoded'

so

define MYPICKUPACTOR ****
action MYPICKUPANIMATION *****

useractor notenemy MYPICKUPACTOR 0 MYPICKUPANIMATION
sizeat X X
fall // if you want it to fall, if not dont use this command
  ifmove RESPAWN_ACTOR_FLAG
    state respawnit
  else
    ifp pshrunk nullop
    else
      ifp palive
        ifcount 6
          ifpdistl RETRIEVEDISTANCE
            ifcanseetarget
      {
        addammo PISTOL_WEAPON PISTOLAMMOAMOUNT 
        quote 65
        ifspawnedby AMMO
          state getcode
        else
          state quikget
      }
enda

[thisbecasper]

Is there a way to access nicknames used in multiplayer? The name property seems to be useless.

[thisbecasper]

thisbecasper, on 19 February 2021 - 10:41 AM, said:

Is there a way to access nicknames used in multiplayer? The name property seems to be useless.

Is it possible to know what weapon is hitting you/killed you? For example, if SHOTSPARK1 kills me, can I determine in some way whether it was the pistol, shotgun or chaingun?

[Danukem]

thisbecasper, on 21 February 2021 - 03:07 PM, said:

Is it possible to know what weapon is hitting you/killed you? For example, if SHOTSPARK1 kills me, can I determine in some way whether it was the pistol, shotgun or chaingun?

There might be a simpler way, but the way I know how is to inspect the yvel member of the SHOTSPARK1 actor and also the relevant htg_t 8 of that actor. The former will tell you what type of bullet it is, the latter will give you the ID of the sprite it hit, if any. With the sprite ID known, you can then set htpicnum on the victim to a different value to reflect the exact type of bullet. Numerous examples of this kind of manipulation can be seen in my released mods.

[thisbecasper]

Danukem, on 22 February 2021 - 03:00 AM, said:

There might be a simpler way, but the way I know how is to inspect the yvel member of the SHOTSPARK1 actor and also the relevant htg_t 8 of that actor. The former will tell you what type of bullet it is, the latter will give you the ID of the sprite it hit, if any. With the sprite ID known, you can then set htpicnum on the victim to a different value to reflect the exact type of bullet. Numerous examples of this kind of manipulation can be seen in my released mods.

How would I go about "finding" the shotspark actor? Should it be done in event_game? I was thinking more like when the player dies I can in the aplayer actor code check what actor killed him (shotspark, rpg, shrinkblast, etc...) and then make further checks to see what weapon shot the shotspark, or what weapon caused the blastradius to kill the player. Inspecting the yvel member of shotspark gives me shotspark (2595) so am I misunderstanding something here?

onevent EVENT_GAME {
    ifactor SHOTSPARK1 {
	 getactor[THISACTOR].yvel tempone
	 addlogvar tempone
    }
endevent

//output
CONLOGVAR: L=1165 tempone  (Global) =2595
CONLOGVAR: L=1165 tempone  (Global) =2595
CONLOGVAR: L=1165 tempone  (Global) =2595
CONLOGVAR: L=1165 tempone  (Global) =2595
CONLOGVAR: L=1165 tempone  (Global) =2595
CONLOGVAR: L=1165 tempone  (Global) =2595
CONLOGVAR: L=1165 tempone  (Global) =2595

Also, how would I check what actor/projectile killed the player, and not just the picnum?

[Danukem]

It's literally an actor. As in "actor SHOTSPARK1" in your GAME.CON or whatever your main script file is named.

And yes yvel will be 2595 if the actor is spawned by "shoot SHOTSPARK1". But if it is spawned by "shoot CHAINGUN", then yvel should be CHAINGUN (whatever number that is)


https://wiki.eduke32.com/wiki/Yvel

[jimbob]

thisbecasper, on 13 February 2021 - 09:45 AM, said:

Some existing actors are ones we wont encounter when playing DM, but have nice animations (e.g. OOZFILTER could be a new item to be picked up). Should I understand your reply as it can't be done, or how would I go about overwriting OOZFILTER? I've also not experimented with creating actors with animation myself, but the tiles that can make up an animation are usually an existing actor - I don't know if my point came across very well...

Maybe I am misunderstanding, does it make any difference having "useractor OOZFILTER ..." instead of "actor OOZFILTER ..."?

what i mean is that the oozefilter actor is a 'c9' explosive actor that could potentially be used in original duke nukem 3d maps, if you alter the code of the actor itself you might break the game, my method is a workaround so you can use the items sprite and animation, but with your own code attached without worrying it wil break anything in the original games or user maps.

the difference between actors and useractors is in the name really, actors are pre-defined actors from the original game, and where limited you could not add a new actor only repurpose existing ones, with version 1.4 and later the useractor became available and you could add as many actors as you'd want through the useractor function.

[thisbecasper]

So I've got shotsparks working, thanks! - But I've honestly no idea of how to set the htpicnum on a player when a RADIUSEXPLOSION hits them, or when my custom FIRELASER projectile hits them. I've tried alter the actor code for firelaser and also accessed it event_game but it seems htg_t 8 is never being set for that actor....

[Danukem]

thisbecasper, on 22 February 2021 - 01:03 PM, said:

So I've got shotsparks working, thanks! - But I've honestly no idea of how to set the htpicnum on a player when a RADIUSEXPLOSION hits them, or when my custom FIRELASER projectile hits them. I've tried alter the actor code for firelaser and also accessed it event_game but it seems htg_t 8 is never being set for that actor....

For non-hitscan projectiles, you shouldn't need to do anything special other than define the projectile properly. For ones that do splash damage add 65536 to the workslike value and the projectile should automatically set htpicnum when causing damage. https://wiki.eduke32...efineprojectile

[Danukem]

jimbob, on 22 February 2021 - 11:11 AM, said:

the difference between actors and useractors is in the name really,

useractor has the enemy, notenemy, and enemystayput options

[thisbecasper]

Danukem, on 22 February 2021 - 04:38 PM, said:

For non-hitscan projectiles, you shouldn't need to do anything special other than define the projectile properly. For ones that do splash damage add 65536 to the workslike value and the projectile should automatically set htpicnum when causing damage. https://wiki.eduke32...efineprojectile

Awesome, I missed that one. However, can I add to the workslike of pipes and trips without changing anything else about them? I suspect also that trips works a bit different. I can't seem to figure out how to determine whether I died from a pipe explosion or tripbomb explosion. Just being able to differ between the two will suffice, any ideas? I should clarify that htpicnum of pipes is not pipebomb but radiusexplosion, and the same goes for trips... I've not touched them. htg_t 8 is always 0 for these exploding things.

[Danukem]

Tripbombs and pipebombs are not part of the custom projectile system, in fact they are not even projectiles. You have to fight against the way the game wants to work to do what you want -- typical Duke modding BS in other words.

Here's a hack that _might_ work, but might require adjustment:

gamevar xydist 0 0

appendevent EVENT_EGS

ifactor EXPLOSION2
ife sprite[player[].i].htpicnum RADIUSEXPLOSION
{
    findplayer xydist

    ifspawnedby HEAVYHBOMB
    ifle xydist PIPEBOMBRADIUS
       seta[player[].i].htpicnum HEAVYHBOMB

    ifspawnedby TRIPBOMB
    ifle xydist TRIPBOMBBLASTRADIUS
       seta[player[].i].htpicnum TRIPBOMB
}
endevent

Some version of that code will work, but it makes several assumptions and I don't have time to test it. EVENT_EGS occurs whenever a sprite spawns into the map, and only with sprites that are not present in the map when the game starts. The code says, "If the player sprite thinks it is taking generic radius damage at the instant that an explosion sprite spawns, and if that explosion is spawned by a pipe or trip and within the blast radius of those, then assume the damage was caused by the pipe or trip and reset the player's damage type accordingly." If you want this to work for actors other than the player, then it would need a loop on statnum 1 sprites instead of using findplayer.

[thisbecasper]

Danukem, on 23 February 2021 - 11:37 AM, said:

Tripbombs and pipebombs are not part of the custom projectile system, in fact they are not even projectiles. You have to fight against the way the game wants to work to do what you want -- typical Duke modding BS in other words.

Here's a hack that _might_ work, but might require adjustment:

gamevar xydist 0 0

appendevent EVENT_EGS

ifactor EXPLOSION2
ife sprite[player[].i].htpicnum RADIUSEXPLOSION
{
    findplayer xydist

    ifspawnedby HEAVYHBOMB
    ifle xydist PIPEBOMBRADIUS
       seta[player[].i].htpicnum HEAVYHBOMB

    ifspawnedby TRIPBOMB
    ifle xydist TRIPBOMBBLASTRADIUS
       seta[player[].i].htpicnum TRIPBOMB
}
endevent

Some version of that code will work, but it makes several assumptions and I don't have time to test it. EVENT_EGS occurs whenever a sprite spawns into the map, and only with sprites that are not present in the map when the game starts. The code says, "If the player sprite thinks it is taking generic radius damage at the instant that an explosion sprite spawns, and if that explosion is spawned by a pipe or trip and within the blast radius of those, then assume the damage was caused by the pipe or trip and reset the player's damage type accordingly." If you want this to work for actors other than the player, then it would need a loop on statnum 1 sprites instead of using findplayer.

I'm coding for eduk32-oldmp so that syntax is a bit too fancy for me. I managed to rewrite it though, and it works. Thank you so so much, now we (me and the boys) can begin to use my site properly: https://ckal.hopto.org/duke/home (take a quick look if you have the time, quite cool if I should say so myself). Again, thank you so much!

[jimbob]

is there an way to zoom the FPS view, like say using binoculars or a sniper scope?

[Danukem]

jimbob, on 26 February 2021 - 11:33 AM, said:

is there an way to zoom the FPS view, like say using binoculars or a sniper scope?

[jimbob]

thats pretty much what i need, im trying to turn the NV goggles into functional binoculars, i'll look at that mod and see how its done.
maybe add a way to call in airstrikes too, could be usefull.

[Danukem]

jimbob, on 26 February 2021 - 12:15 PM, said:

thats pretty much what i need, im trying to turn the NV goggles into functional binoculars, i'll look at that mod and see how its done.
maybe add a way to call in airstrikes too, could be usefull.

Long story short you use the setaspect command which is documented on the wiki. helixhorned wrote the core functional code for me some years ago and I have tweaked it since then, versions of it are in the recently released WGR: Demon Throne and of course also Alien Armageddon. AMC TC also has zoom but you would have to ask Jblade about that; at one point it used a different method but its probalby changed over to the setaspect method by now.

[Danukem]

Airstrikes is a good idea. I think what you'll want to do is have preset airstrike points designated in the maps by invisible sprites, which are then highlighted only when viewed via the goggles. I have thought about such a feature myself, but most of the maps I am using are vanilla and either not suitable for airstrikes or only specific areas in them would work and trying to write code to figure out whether a spot is viable for an airstrike does not sound fun.

[jimbob]

Danukem, on 26 February 2021 - 02:42 PM, said:

Long story short you use the setaspect command which is documented on the wiki. helixhorned wrote the core functional code for me some years ago and I have tweaked it since then, versions of it are in the recently released WGR: Demon Throne and of course also Alien Armageddon. AMC TC also has zoom but you would have to ask Jblade about that; at one point it used a different method but its probalby changed over to the setaspect method by now.

setaspect, hah and i waded though the wiki and every possible variation of camera :') that should make finding the apropriate code in AA much easier so i can see how it is set up, good idea on that pre determined locations, airstrikes are very powerfull and could potentially be spammed/abused making things way too easy.

This is the first time i'll be altering the actual inventory functionallity, got to think of some other things aswell, maybe landmines for an incomming atack wave.