[Danukem]

thisbecasper, on 28 May 2018 - 04:31 PM, said:

Or when I look at them? I really have a hard time of figuring out how to get the sprite ID or whatever of what I'm interacting with...

What I do in my mods is constantly have the player hitscan and save the sprite id each tic so I know what is currently being scanned. But sometimes you are "looking at" an enemy even though it is not hitscanned (e.g. the hitscan is missing the enemy a little to the left or right). One way to address that issue is by having enemies set themselves as the looking target when the hitscan target is empty and certain conditions are met (ifcansee ifp pfacing...)

[thisbecasper]

Trooper Dan, on 28 May 2018 - 07:24 PM, said:

What I do in my mods is constantly have the player hitscan and save the sprite id each tic so I know what is currently being scanned.

I'm really sorry, but I have no clue what you mean by this. I would really like to get access to the data of the actor I'm looking at, I just don't know how it works in the code....

[Salvation]

It worked! Many thanks! I have spend many hours of getting that thing worked but i didn't get it. Now it works.

RichardStorm, on 28 May 2018 - 11:20 AM, said:

I use time variables which keep for how much time a key is pressed, and the desired function is triggered or toggled when the timer is equal to 1:

gamevar  turnaround_keytime 0 1
gamevar  sight_on 0 1
...

ifvarand TEMP4  268435456
   { addvar turnaround_keytime 1 }
  else
   { setvar  turnaround_keytime 0 }

ifvare turnaround_keytime 1
   { xorvar sight_on 1 }

ifvare sight_on 1
  { /* your code here */ }
....

[thisbecasper]

thisbecasper, on 29 May 2018 - 05:29 AM, said:

I'm really sorry, but I have no clue what you mean by this. I would really like to get access to the data of the actor I'm looking at, I just don't know how it works in the code....

Maybe a concrete example can help:

onevent EVENT_GAME
  ifp pfacing
    getactor[THISACTOR].extra actorhp
endevent

Would this show the hp of the enemy I'm looking at. Does THISACTOR refer to the sprite ID of the actor duke is facing, because it is in a pfacing branch?

[thisbecasper]

I've got the healthbar to work, kinda - so thank you!

REMOVED

[Zaxtor]

You know the SE Lotag 49 is Point Light and SE lotag 50 is Spotlight.
50 - makes spotlight that casts a shadow.
49 - point light (do not cast shadow)


But is there any def or con codes to make sprites act like that?
To make sprites emitting light radius like projectiles etc does.
I'm sure in projectile is hard coded.
Same for fires, atomic health etc.

[Danukem]

 Zaxtor, on 21 July 2018 - 07:28 PM, said:

But is there any def or con codes to make sprites act like that?

The only way I know how to do it is spawn a new SE, set it up appropriately, and then link it to the actor and make it fixed to the actor's coordinates. And don't forget to make the SE go away if the sprite dies or is deleted.

An example of this is shown in a video I linked in the very first post of the EDuke32 2.0 and Polymer thread back in 2009:

[Zaxtor]

I see, kinda a customized SE-like sprite like AMC mod has?

[Danukem]

 Zaxtor, on 21 July 2018 - 08:11 PM, said:

I see, kinda a customized SE-like sprite like AMC mod has?

It's literally an SE that is constantly being set to the location of the sprite which you want to glow. I'm guessing that AMC uses the same idea.

[Zaxtor]

Sprite I wanna make glow doesn't move and nor die.
Is a portal.

[Danukem]

If your mod has multiple playable characters and you want them all to have Duke's full functionality, then each character needs its own set of tiles for fists and such. I don't want Duke's fist displaying to hit the nuke button if I am using Bombshell. But, as far as I know, I can't just swap out his fist tile for a different one when Bombshell is selected. If I could just swap in a different tile (e.g. by just setting a variable for the tile in EVENT_DISPLAYFIST) that would be amazing, and that feature would come in handy (no pun intended) for many things, like stomping enemies, swiping a keycard, and more. Alas, what I end up doing is writing new display code for the other character's sprites to emulate the Duke version.

Currently I contemplate doing that for hitting the nuke button. I found this in the source for Duke:

 int const fistY       = klabs(pPlayer->look_ang) / 9;
    int const fistZoom    = clamp(65536 - (sintable[(512 + (fistInc << 6)) & 2047] << 2), 40920, 90612);
    int const fistYOffset = 194 + (sintable[((6 + fistInc) << 7) & 2047] >> 9);
    int const fistPal     = P_GetHudPal(pPlayer);
    int       wx[2]       = { windowxy1.x, windowxy2.x };

    rotatesprite((-fistInc + 222 + (fix16_to_int(g_player[screenpeek].inputBits->q16avel) >> 5)) << 16, (fistY + fistYOffset) << 16,
                 fistZoom, 0, FIST, fistShade, fistPal, 2, wx[0], windowxy1.y, wx[1], windowxy2.y);

I'm not sure how to translate that into CON code. I could eventually do it, with some learning and trial and error, but maybe there is someone around here who could do it much more easily than I. If so, I would really appreciate it!

[Mblackwell]

 Trooper Dan, on 22 July 2018 - 06:19 PM, said:

If your mod has multiple playable characters and you want them all to have Duke's full functionality, then each character needs its own set of tiles for fists and such. I don't want Duke's fist displaying to hit the nuke button if I am using Bombshell. But, as far as I know, I can't just swap out his fist tile for a different one when Bombshell is selected. If I could just swap in a different tile (e.g. by just setting a variable for the tile in EVENT_DISPLAYFIST) that would be amazing, and that feature would come in handy (no pun intended) for many things, like stomping enemies, swiping a keycard, and more. Alas, what I end up doing is writing new display code for the other character's sprites to emulate the Duke version.

Currently I contemplate doing that for hitting the nuke button. I found this in the source for Duke:

 int const fistY       = klabs(pPlayer->look_ang) / 9;
    int const fistZoom    = clamp(65536 - (sintable[(512 + (fistInc << 6)) & 2047] << 2), 40920, 90612);
    int const fistYOffset = 194 + (sintable[((6 + fistInc) << 7) & 2047] >> 9);
    int const fistPal     = P_GetHudPal(pPlayer);
    int       wx[2]       = { windowxy1.x, windowxy2.x };

    rotatesprite((-fistInc + 222 + (fix16_to_int(g_player[screenpeek].inputBits->q16avel) >> 5)) << 16, (fistY + fistYOffset) << 16,
                 fistZoom, 0, FIST, fistShade, fistPal, 2, wx[0], windowxy1.y, wx[1], windowxy2.y);

I'm not sure how to translate that into CON code. I could eventually do it, with some learning and trial and error, but maybe there is someone around here who could do it much more easily than I. If so, I would really appreciate it!

It's late so forgive any errors, but this should be about right if I didn't fall asleep while typing (it is possible!):

set y1 player[].look_ang
div y1 9
abs y1

set z1 65536
set z2 player[].fist_incs
shiftl z2 6
add z2 512
and z2 2047
sin z2 z2
sub z1 z2
clamp z1 40920 90612


set y2 player[].fist_incs
add y2 6
shiftl y2 7
and y2 2047
sin y2 y2
shiftr y2 9
add y2 194

set x1 input[].q16avel
shiftr x1 5
set x2 player[].fist_incs
inv x2
add x2 222
add x1 x2
shiftl x1 16

add y1 y2
shiftl y1 16

rotatesprite x1 y1 z1 0 FIST gs actor[player[].i].pal 2050 windowx1 windowy1 windowx2 windowy2

[Danukem]

It works perfectly! There was an extra backswing at first, because I forgot to include the line which caps the movement at fist_incs 32, but otherwise it worked correctly right out of the box. Thanks a million!

By the way, the following commands you used above are not listed at all in the Eduke32 wiki "full command list":

abs
clamp
inv

EDIT: There is one little thing...the avel stuff is no bueno. If you factor in input.q16avel, all that does is make the fist disappear when the player is pressing movement keys (I guess because it is throwing off the coordinates big time and causing it to draw off screen). But it works fine if the input isn't included. I wonder why the heck that is in the source.

Final code in my project ended up like this:

appendevent EVENT_DISPLAYFIST

ife pchar 1
{
	set RETURN -1
	// thanks to Mblackwell for fist CON code, adapted from Duke source
	set y player[].look_ang
	div y 9
	abs y

	set z 65536
	set z2 player[].fist_incs
	ifg z2 32 set z2 32
	shiftl z2 6
	add z2 512
	and z2 2047
	sin z2 z2
	sub z z2
	clamp z 40920 90612

	set y2 player[].fist_incs
	ifg y2 32 set y2 32
	add y2 6
	shiftl y2 7
	and y2 2047
	sin y2 y2
	shiftr y2 9
	add y2 194

	set x player[].fist_incs
	ifg x 32 set x 32
	inv x
	add x 222
	shiftl x 16
	add y y2
	shiftl y 16

	rotatesprite x y z 0 SHELLYFIST gs sprite[player[].i].pal 2050 0 0 xdim ydim
}
endevent

[Mblackwell]

Glad you got it working. Coolness.

[thisbecasper]

How do I get the holoduke (or any other item) to execute its code even though duke hasn't seen the item? I want it to spawn monsters, but it only does so after Ive walked up to it (not preferable).

[Danukem]

 thisbecasper, on 14 August 2018 - 11:10 AM, said:

How do I get the holoduke (or any other item) to execute its code even though duke hasn't seen the item? I want it to spawn monsters, but it only does so after Ive walked up to it (not preferable).

This should work:

appendevent EVENT_GAME

     ifactor HOLODUKE ifn sprite[].statnum 1 changespritestat THISACTOR 1

endevent

[thisbecasper]

 Trooper Dan, on 14 August 2018 - 11:16 AM, said:

This should work:

appendevent EVENT_GAME

     ifactor HOLODUKE ifn sprite[].statnum 1 changespritestat THISACTOR 1

endevent

I should say that I'm using the eduke old-mp build, and maybe that's why it wont run your code.

GAME.CON: In event `EVENT_GAME':
GAME.CON:37: error: expected a keyword but found `ifn'.
GAME.CON:37: error: expected a keyword but found `sprite'.
GAME.CON:37: error: expected a keyword but found `.statnum'.
GAME.CON:37: error: expected a keyword but found `1'.

EDIT: I've got it to work - but thanks! I was basically doing the same thing, but under actor holoduke (and that just doesn't work :-P )

[Danukem]

Yeah, changing the statnum to 1 in the actor code is pointless since the actor code doesn't run unless the statnum is already 1.

[thisbecasper]

Now another thing: I want the spawners to only spawn a monster by a chance, but it seems the spawn pattern is the same (I have multiple spawners, and each has a 50% chance to spawn a monster every fifth second). Somehow it makes sense, that the rng is doing the same exact thing every run, but I really need some "real" randomness...

[Danukem]

 thisbecasper, on 14 August 2018 - 02:42 PM, said:

Now another thing: I want the spawners to only spawn a monster by a chance, but it seems the spawn pattern is the same (I have multiple spawners, and each has a 50% chance to spawn a monster every fifth second). Somehow it makes sense, that the rng is doing the same exact thing every run, but I really need some "real" randomness...

The only way I know how to "fix" that also breaks sync in multiplayer.

[thisbecasper]

Is there a way for duke to be ignored by monsters? In this coop game mode, when one dies, he will stay on the ground, dead, waiting for someone to revive him. I'd like the monsters to switch from the duke they killed to the other player naturally...

[thisbecasper]

And lastly, the FFIRE doesn't do what it should I think... I set it to 0, but I can still kill my bot in coop mode. Doesn't "friendly fire off" work on bots, or am I doing something wrong here?

[Danukem]

 thisbecasper, on 15 August 2018 - 05:38 PM, said:

Is there a way for duke to be ignored by monsters? In this coop game mode, when one dies, he will stay on the ground, dead, waiting for someone to revive him. I'd like the monsters to switch from the duke they killed to the other player naturally...

The difficulty is that all of the monster movement commands are oriented to the nearest player, even if the player is dead. A properly coded monster will check for "ifp palive" before firing, but they will generally still seek the nearest player regardless.

I guess the easiest way would be to insert some code into the monsters via EVENT_GAME. The code would check for if the nearest player is dead, and if so would change the angle of the monster so that it moved in a more appropriate direction. Depending on how much work you wanted to put into it, you could do something simple like make the monster walk off in a random direction, or you could write your own pathfinding code.

Here's a very simple and untested attempt at what I'm talking about:

move ENEMYWANDERVELS 160

appendevent EVENT_GAME

switch sprite[].picnum
case LIZTROOP
case PIGCOP
case LIZMAN
// keep adding cases...
     ifp palive nullop
     else ifmultiplayer
     {
           ifmove ENEMYWANDERVELS nullop else
              move ENEMYWANDERVELS randomangle
     }
     break
endswitch
endevent

Note: you may need to make adjustments if you are using an old version of EDuke32 that doesn't allow the abbreviated CON commands

[thisbecasper]

Thank you very much for your replies so far, I've been working on this survival mod a lot lately, and I have to get the basic elements working properly before I add more "features", so I haven't added your code yet, but looks good... I'm having a rather odd problem here: My monsters spawn from the keycard actor. Different places on the map, several keycards has been placed so that monsters come from all directions. My problem is, that even though the keycards are placed at least 2400 mapster units away from forcefield/cieling door, they go right through it and gets stuck there, making it impossible to complete the round, because the monsters are trapped in a place that can only be unlocked later in the game. It seems that when the monsters spawn, they immediately walk towards a player, and doesn't get stopped by a door or forcefield. Any ideas to prevent this nonsense? I've tried to move the spawners further and further away from the doors and forcefields, but that's not helping either...

[Mark]

This may be a dumb suggestion but as a coding noob what popped into my head was... As a test I would tie the spawn to a different actor just to rule out the slim possibility that there is some hidden hardcoding for the keycard that is interfering. Probably not but I would want to rule out the chance.

[Danukem]

It's likely that the monsters are starting where they are supposed to but then are clipping right through the barrier. It's possible that something in your custom monster code is causing that, but it's also possible that it's just happening because Build. And that's no attack on Build -- if you were making a Fallout 4 mod you could have the same issue (monsters end up in strange places in Creation engine...)

If you make a gametype that requires killing all the monsters, you really need to put in safeguards. When I have coded invasion gameplay in the past, I have made all the monsters count the amount of time they have no contact with the player. If the count goes high enough, they get teleported somewhere -- their original start position might be a good choice, or some location that you know the player can get to. If that sound hard or bewildering then you may be in over your head and you may need to change your plans until you have a better grasp of the engine and scripting system.

[thisbecasper]

 Trooper Dan, on 19 August 2018 - 12:32 PM, said:

It's likely that the monsters are starting where they are supposed to but then are clipping right through the barrier. It's possible that something in your custom monster code is causing that, but it's also possible that it's just happening because Build. And that's no attack on Build -- if you were making a Fallout 4 mod you could have the same issue (monsters end up in strange places in Creation engine...)

If you make a gametype that requires killing all the monsters, you really need to put in safeguards. When I have coded invasion gameplay in the past, I have made all the monsters count the amount of time they have no contact with the player. If the count goes high enough, they get teleported somewhere -- their original start position might be a good choice, or some location that you know the player can get to. If that sound hard or bewildering then you may be in over your head and you may need to change your plans until you have a better grasp of the engine and scripting system.

Yeah, after some testing I've found that they clip through "doors" that are less than 256 units wide. I've considered what you are suggesting with the teleporting, but for now the map just have huge doors (they still try to clip it, but gets squished instead (mission accomplished?)).

A whole other thing, and I'm kinda embarrased to ask this but: What's the most elegant or simplest way to have a switch for things in general? Let me give an example: Monsters drop this crystalammo from time to time, and when the player picks it up, all monsters run a block of code. So what I'm currently doing is setting a global gamevar = 1 in the crystalammo code when the player picks it up while having the monsters check for this gamevar. Then I would like the gamevar to be set back to 0 when all monsters (actors, really) have been iterated once. I've come up with all kind of weird methods, but in the end they doesn't seem logical...

[Danukem]

 thisbecasper, on 19 August 2018 - 02:18 PM, said:

A whole other thing, and I'm kinda embarrased to ask this but: What's the most elegant or simplest way to have a switch for things in general? Let me give an example: Monsters drop this crystalammo from time to time, and when the player picks it up, all monsters run a block of code.

What does the block of code actually do? My first reaction would be to make the crystalammo run the code instead, by looping through all the monsters. I think this would be less confusing to read, as well.

EDIT:
On a related note, you should probably have a per-actor gamevar set to a certain value on all of the "monsters" when they initialize, so that you can easily identify them.

[thisbecasper]

 Trooper Dan, on 19 August 2018 - 02:30 PM, said:

What does the block of code actually do? My first reaction would be to make the crystalammo run the code instead, by looping through all the monsters. I think this would be less confusing to read, as well.

EDIT:
On a related note, you should probably have a per-actor gamevar set to a certain value on all of the "monsters" when they initialize, so that you can easily identify them.

The code will do different things depending on the item the player picks up (but in this case it kills them), but stuff has to happen to the player too, but I guess that could be done by looping too. Only reason to why I'm not looping, is because I haven't learned it yet! Is there anything on the wiki about looping though actors?

[Danukem]

You want to look up whilevarn and headspritestat/nextspritestat

There's lots of examples of looping through sprites in published mods, such as pretty much any of mine.