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

[jimbob]

well, got the zoom to work, now to get the overlay working, holstering the weapon, and give it infinite inventory amount somehow and remove that nasty green NV effect from sprites.

as for the airstrike, the sprite can run a check to see if the player is currently using the goggles, and if so set the cstat from hidden to not hidden, but that would make using them rather awkward i guess, somehow an indicator needs to be there so the player know he can actually use the binoculars to signal an airs/artillery strike. something im going to think about next.
[edit]
have the binocular overlay working using EVEN_DRAWROOMSEND, maybe not the best way but it works so im happy for now. now to tell the game to lower the weapon when using the binocular, and end using the binoculars when hitting the fire key.

[edit]
fixed the player being able to fire during the use of binoculars, firing wil set the NV goggles to 0

now to holster the weapon, tried setting setplayer[THISACTOR].holster_weapon to 0 but that breaks the weapons
but its a start, art needs to be updated, this is just something i threw together for the time being

Attached thumbnail(s)

• 
• 

[jimbob]

fixed the holster gun issue, setting setplayer[THISACTOR].weapon_pos 20 when the NV is on lowers it, and whats nice is that it still lets you switch the gun while on the binoculars.

[Danukem]

If you want you could also cancel weapon drawing when the goggles are on by setting RETURN to -1 in EVENT_DISPLAYWEAPON and EVENT_DRAWWEAPON if player[THISACTOR].heat_on YES

[jimbob]

 Danukem, on 28 February 2021 - 10:44 AM, said:

If you want you could also cancel weapon drawing when the goggles are on by setting RETURN to -1 in EVENT_DISPLAYWEAPON and EVENT_DRAWWEAPON if player[THISACTOR].heat_on YES

if that also prevents the weapon firing that might also work, i choose for holster because its a more realistic way of handeling things, you cant hold a 2 handed weapon, ánd a binocular at the same time so holstering seemed like a logical way to handle it. maybe that would be usefull for a sniper rifle, if i decide to add one.

how do i remove the enemy spritepal wen using the NV goggles, tried several things but it seems pretty persistent.

as for the airstrike, i recon making the marker a switch that triggers an activator, but can only be switched on when looking through the binoculars, and perhaps you would also have to be near a radioman, i could use a FPS view of a handy talky but programming that is a bit too advanced for me.

i have found a way to keep the binoculars at 100%
so i figure using it to call an airstrike would immediatly deplete it to 0 to prevent multiple uses, and then recharge it over time and being able to call a new one once it reaches 100%.


been thinking about the other inventory items, and the steroids might just stay as they are, but also add a temporary health boost. thinking about changin it to panzerchocolade, chocolat bars the germans used laced with pervitin ( meth ) so a temporary stat boost combined with a witty comment and a screenpal like purple to simulate a rush.

but im thinking out loud again

[edit] changed the pal to purple for the pervitin, and added some fire for optimal effect, it would be fun if you are on steroids, you can kick someone and send them flying back, or explode like in doom.

[edit]

whats the correct command to initiate the loogie animation? i want to use it to say, draw blood on the screen if the player is under a certain amount of health
found that setting numloogs and loogcnt does display loogies, but does not animate the way they normally do in the game :/

Attached thumbnail(s)

• 

[jimbob]

ugh, have the artystrike working for like 80% the way i want it, but im going codeblind, for whatever reason the timing does not do what i want it to do, i have set up a action for loading, just a 1 frame action with a delay so i can use ifactioncount x to switch to a new action, wich is the fire mode, this spawns a line that moves in a random direction and spawns a morter on a semi random interval, but no matter how i set it up the timing is off and the actions seem to work in reverse, and the ifcount 300 killit also does not seem to work, ugh.
ideally i would like to set it up that i can controll exactly how many mortars it shoots, and the timing inbetween actuall shots. this is dirty, but for now it does function, albeit indefinatly.\
looking at it, i suspect resetactioncount also resets count so it never reaches 300, but i need it to reset the angle to random evertime it is about to spawn a mortarline.

action USMORTARFIRE 0 1 1 1 8
action USMORTARLOADING 0 1 1 1 16

useractor notenemy USMORTARSPAWN 0 USMORTARLOADING
cstat 32768
ifaction USMORTARFIRE
ifcount 300 killit
{ 
ifactioncount 2
	{
 	move 0 0 randomangle
	spawn USMORTARLINE
	resetactioncount
	} 

}

ifaction USMORTARLOADING 
ifactioncount 120 // when done loading, fire away
			{
				action USMORTARFIRE // the firing state
			}
enda

[edit] resetactioncount seemed to be the culprit, now it starts and stops, though the starting does not respond to the delay i want to set

action USMORTARFIRE 0 1 1 1 16
action USMORTARLOADING 0 1 1 1 16
 

useractor notenemy USMORTARSPAWN 0 USMORTARLOADING
cstat 32768
ifaction USMORTARFIRE
ifcount 150 killit
{ 
ifactioncount 2
	{
 	move 0 0 randomangle
	ifrnd 64 spawn USMORTARLINE
	ifactioncount 40 killit
	} 

}

ifaction USMORTARLOADING
ifactioncount 120 // when done loading, fire away
			{
				action USMORTARFIRE // the firing state
			}
enda

[Danukem]

Resetactioncount does NOT reset count.

However, any move command applied DOES reset count. So each time you apply "move 0 0 randomangle" that resets the count.

Count is how many tics have passed since the actor got its current move.