[spacekebab]

Trooper Dan, on 25 May 2020 - 11:37 AM, said:

Not sure what you mean. At first I thought you meant prevent them from hanging off of ledges, but now I doubt that.

That's exactly what I meant, sorry - didn't know how to word it.

[Danukem]

spacekebab, on 25 May 2020 - 07:15 PM, said:

That's exactly what I meant, sorry - didn't know how to word it.

There is hardcoding in the base game which prevents the standard BLOODPOOL from hanging over ledges. So one solution is to spawn BLOODPOOL, then in a game event (EVENT_WORLD may be your best choice) cactor BLOODPOOL into your own actor, and change size and pal if needed. Since BLOODPOOL is already in a verified good location, that should be fine (although it won't be if your sprite is much bigger).

If you want to use your own code then I would suggest a loop where you test out some nearby coordinates (nothing fancy, just add and subtract values to your sprites's x and y) and check to see if the floor height is the same if the tested coords are in a different sector. Also you can check for slopes. If checks indicate a bad situation, you can resize or delete your sprite as appropriate.

[Mark]

I have player weapons not flashing the screen during firing but haven't been able to do the same for the enemies. I didn't find anything with a quick browse thru the wiki. I'm using Polymer in case it makes a difference.

Maybe set PROJ_FLASH_COLOR to all 0's? Or is there a global command?

[Danukem]

What exactly are the enemies shooting that is making the screen flash?

[Mark]

pistol, shotgun, chaingun ( machine gun ) They are already custom coded from previous owner of the project. This might complicate your answer. I was hoping for a simple global command or similar.

[Danukem]

I can't tell from your description whether there are polymer lights being spawned when the projectiles fire, whether they are flashing the world in the old-fashioned way (setting global visibility for a moment), or whether they have been specially coded to literally flash the screen (via palfrom or equivalent).

The flash color thing might work if they are polymer lights.

[Mark]

I'll check again to be sure. I think its polymer. Be right back.

edit: Because of how large an area weapons light up in the map I thought it might be the usual sector based flashing. But switching to Polymost stopped any weapon flashing. So even though the mod is ancient, eduke32 is supplying the flash thru Polymer. Can I just set the PROJ_FLASH with a gamevar or is it an event thing? In all my years of coding I have never messed with weapons. I'm a noob once more.

[Danukem]

It's not a gamevar.

Find where there are "defineprojectile" for the projectiles in question. There should be a block of lines for each one of the projectiles. You want to add/replace with "defineprojectile PROJECTILENAME PROJ_FLASH_COLOR 0"

It might not work.

[Mark]

There is no defineprojectile commands in any of the defs or cons. So I guess its just using defaults. The only weapon related blocks of code I can find for each weapon are gamevars being set for a bunch of parameters.
// Shotgun
gamevar WEAPON2_WORKSLIKE 2 2
gamevar WEAPON2_CLIP 0 2
gamevar WEAPON2_RELOAD 13 2
gamevar WEAPON2_FIREDELAY 4 2
etc...

I guess I'll search around in other projects to see if I can find a chunk of defineprojectile code to learn from. But if its a whole lot of effort to make a projectile from scratch, I'll just live with the flash. Actually, I wouldn't mind keeping the flash but reduce it's size by at least 50-60 percent.

[Danukem]

^those gamevars only pertain to the player

You said they were "custom coded" so I assumed that meant they were custom projectiles. If the actors are using the regular hardcoded shots ("shoot SHOTGUN", "shoot CHAINGUN", "shoot SHOTSPARK1") then I don't know if there is any way to disable the lights they spawn in polymer. You could replace them with your own projectiles that don't emit light, though.

[Mark]

Sorry to mislead you. Its been a real treat to find and decipher someone elses old code. I knew there was weapon related code in there but didn't realise it was only player related. Thanks for trying. I'm assuming custom projectiles need math functions and other con functions I'm not familiar with so it will take a back seat to all the other issues I have to solve.

[Danukem]

Mark, on 29 August 2020 - 07:49 PM, said:

I'm assuming custom projectiles need math functions and other con functions I'm not familiar with so it will take a back seat to all the other issues I have to solve.

No, for hitscan they are incredibly simple. Pick an unused tile number (can be a blank one it doesn't matter), define it as hitscan and set damage, decal size and a few other things and you are good to go. No math, no fuss.

[Mark]

cool, I'll 'xperiment tomorrow. I see Dukeplus is loaded with custom projectiles for reference.

[Mark]

Its working and with no flashing. I just need to tweak parameters. Thanks again Danny boy.

Now I'm wondering if its possible/feasible to define and spawn my own SE light of a much smaller radius than the default flash was.

[Danukem]

You can, but it's hacky. Spawning an SE will crash the game, so you spawn a different picnum, then change the picnum to SE, change the statnum to 3, and give it lotag 49, hitag for distance, xvel/yvel/zvel 0-255 for the RGB color you want. Importantly, make sure it gets deleted after a few tics, and that means you have to mark it for deletion in some way, have it use a timer and then delete itself in EVENT_GAME.

[Reaper_Man]

Say I have ACTOR1 and want to check if ACTOR2 has a per-actor gamevar set to a certain value.

How would I read (or write) another actor's per-actor gamevar? This seems simple and I'm sure I'm overlooking something obvious.

[Danukem]

 Reaper_Man, on 22 September 2020 - 08:16 AM, said:

Say I have ACTOR1 and want to check if ACTOR2 has a per-actor gamevar set to a certain value.

How would I read (or write) another actor's per-actor gamevar? This seems simple and I'm sure I'm overlooking something obvious.

It is simple, but you have to have the sprite ID number of the other actor in a gamevar first. That's the only part that can be tricky, depending on the context. But let's say you have done that already, by using findnearactor or by searching sprites via a loop or whatever.

Assume that "SPRITE" is a var that is set to the ID of the other sprite, and "VAR1" is a per-actor var. Then, in the code of an actor, you could write:

getactorvar[SPRITE].VAR1 VAR1

The above line would copy the value of VAR1 from the sprite SPRITE to the VAR1 in the current sprite (THISACTOR).

setactorvar[SPRITE].VAR1 VAR1

That would write the current copy of VAR1 in THISACTOR to the copy of that var in SPRITE

You can also abbreviate those commands to getav and setav

[Mark]

never mind, dan beat me to it

[Reaper_Man]

Thanks guys, I had completely forgotten about get/setactorvar. I knew it was going to be something simple!

[Reaper_Man]

Is there a vertical clipdist member, or some other way that controls how "tall" the "hitbox" is of an Actor? Or is there some other way to recalculate their bounding box?

I am using the Player sprites for an actor that can stand and crouch, but when they crouch down, their collision remains the same dimensions as their standing sprite, so I can shoot them where their upper body existed, and when I stand on them there is a giant open space between me and the Actor since I am standing on what used to be their head. Hopefully this terrible image helps demonstrate the problem.

[Danukem]

Just do what I have always done and cactor into the shorter sprite when they are crouched, and cactor back to the taller actor when standing up or dying. It's pretty simple, you just have 2 different actors running the same code (make a state for the code and both actors call the state); the main thing to watch for is the actions of the shorter actor are adjusted for the starting tile number of base crouch tile.

I can't think of another way to do it, honestly.

[Reaper_Man]

Thanks as always Dan, I'll give that a try. I am guessing that's going to mess up my animation offsets, and I'll have to adjust the crouching ones for the new actor's tile position.

Still, that makes me wonder what structure member controls this, and why it can't be set programmatically.

[Danukem]

 Reaper_Man, on 30 September 2020 - 03:56 AM, said:

Thanks as always Dan, I'll give that a try. I am guessing that's going to mess up my animation offsets, and I'll have to adjust the crouching ones for the new actor's tile position.

Still, that makes me wonder what structure member controls this, and why it can't be set programmatically.

https://wiki.eduke32.com/wiki/Htg_t

Current frame offset should be in htg_t 3

I try not to mess with those, though. Redefining the actions only takes a minute.

[December Man]

Hey,
how do you change the palette of Greenslime's guts after it's been killed? I know that it's hardcoded to be spritepal 6.

[Danukem]

First thing I would try:

appendevent EVENT_SPAWN ifspawnedby GREENSLIME spritepal 0 endevent

That should change everything it spawns to pal 0.

[December Man]

 Danukem, on 06 October 2020 - 12:38 AM, said:

First thing I would try:

appendevent EVENT_SPAWN ifspawnedby GREENSLIME spritepal 0 endevent

That should change everything it spawns to pal 0.

Unfortunately this does not work

[Danukem]

How good are you with CON? My next step would be to use either SPAWN or EGS events, use the log function and see if anything has the htpicnum of GREENSLIME when you kill them. Sometimes this game is weird and for hardcoded reasons the jibs might not say they are spawned by it. It could also be that the pal is being changed after spawn, in which case you could try the same thing with EVENT_GAME.

[December Man]

Ok, switching EVENT_SPAWN to EVENT_GAME did the trick. Thanks!

[Danukem]

 December Man, on 06 October 2020 - 11:31 PM, said:

Ok, switching EVENT_SPAWN to EVENT_GAME did the trick. Thanks!

That confirms the reason the EVENT_SPAWN version didn't work is the pal hadn't been set yet. The bad thing about putting that code in EVENT_GAME is that every single sprite in the game will run that line of code 30 times per second, even though it won't do anything unless the sprite is spawned by a slimer. That's very unlikely to cause you any issues but it's not optimal. If you had a big complex project with lots of code it would be worth improving.

[Reaper_Man]

Out of curiosity, what would be a preferable alternative? The wiki says EVENT_EGS executes before EVENT_SPAWN, but if the palette isn't set in SPAWN then certainly that means it still won't be set at EGS, right? I would think that EGS would be preferable here as it runs for actors that are spawned at runtime, and it seems that SPAWN only runs for actors that exist on map load.