[jimbob]

Danukem, on 02 May 2021 - 10:32 AM, said:

Are you sure you removed flag 2, because that's the one that makes it glow according to the wiki:

https://wiki.eduke32...i/WEAPONx_FLAGS

If it still glows with flag 2 off, then I would try changing the workslike to a different weapon.

yes i did, but it seems it adds that flag through its hard code or something, changing the workslike would work i guess, but then it displays the wrong weapon art

Quote

For the other problem, have you tried changing the projectile's offset? https://wiki.eduke32...efineprojectile It's horribly unintuitive and you pretty much have to guess at what value to use, but you can make a projectile spawn anywhere to the left or right with the correct offset. If it is spawning too low, raise it up in EVENT_EGS.

man, i forgot about offset, i tried messing with it once and didnt get the results i liked so i abandoned it, but with some trial and error i now have the projectile spawning on the right spot, now to adjust the height.

for whatever reason, using move to move something on event EGS does nothing

[Danukem]

jimbob, on 02 May 2021 - 12:26 PM, said:

yes i did, but it seems it adds that flag through its hard code or something, changing the workslike would work i guess, but then it displays the wrong weapon art

I just assumed you were using EVENT_DRAWWWEAPON or EVENT_DISPLAYWEAPON to cancel the hardcoded art and draw your own. If you are depending on the game displaying the tiles that are currently on the shrinker tiles, then yes that would be a problem. But you really should be drawing your own, otherwise you are limited to the number of tiles and the timing of them being the way it was in vanilla.

jimbob, on 02 May 2021 - 12:26 PM, said:

for whatever reason, using move to move something on event EGS does nothing

No I mean you change the coords of the spawned sprite to move it instantly, like:

geta[].z z, sub z 2048, seta[].z z

[RichardStorm]

I wonder if anyone has a list of the conditions that check if a TRIPOMB can be "shot" or not onto a wall, when you press fire.

I mean, i'm sure that something similar to ifawayfromwall and/or hitscan is involved, but there is also something that checks if that wall is part of a moving sector, and i don't know there is any mean to detect this via CON.

[Danukem]

RichardStorm, on 03 May 2021 - 05:03 AM, said:

I wonder if anyone has a list of the conditions that check if a TRIPOMB can be "shot" or not onto a wall, when you press fire.

I mean, i'm sure that something similar to ifawayfromwall and/or hitscan is involved, but there is also something that checks if that wall is part of a moving sector, and i don't know there is any mean to detect this via CON.

First I would make my own thrown tripbomb actor with a regular move command on it. While moving through the air, you can check for whether it hits wall like this:

ifnotmoving
{
        setvarvar temp sprite[].htmovflag
	andvar temp 49152
	ifvare temp 32768
	{
		// hit a wall

Second here is the source code the game uses to determine if the wall is valid for placement. It places if PlaceMine gets set to 1

case HANDHOLDINGLASER__STATIC:
        {
            int const zOffset     = (playerNum >= 0) ? g_player[playerNum].ps->pyoff : 0;
            Zvel                  = (playerNum >= 0) ? fix16_to_int(F16(100) - pPlayer->q16horiz - pPlayer->q16horizoff) * 32 : 0;

            startPos.z -= zOffset;
            Proj_DoHitscan(spriteNum, 0, &startPos, Zvel, shootAng, &hitData);
            startPos.z += zOffset;

            int placeMine = 0;
            if (hitData.sprite >= 0)
                break;

            if (hitData.wall >= 0 && hitData.sect >= 0)
            {
                uint32_t xdiff_sq = (hitData.pos.x - startPos.x) * (hitData.pos.x - startPos.x);
                uint32_t ydiff_sq = (hitData.pos.y - startPos.y) * (hitData.pos.y - startPos.y);
                if (xdiff_sq + ydiff_sq < (290 * 290))
                {
                    // ST_2_UNDERWATER
                    if (wall[hitData.wall].nextsector >= 0)
                    {
                        if (sector[wall[hitData.wall].nextsector].lotag <= 2 && sector[hitData.sect].lotag <= 2)
                            placeMine = 1;
                    }
                    else if (sector[hitData.sect].lotag <= 2)
                        placeMine = 1;
                }

            }

[jimbob]

Danukem, on 02 May 2021 - 01:39 PM, said:

I just assumed you were using EVENT_DRAWWWEAPON or EVENT_DISPLAYWEAPON to cancel the hardcoded art and draw your own. If you are depending on the game displaying the tiles that are currently on the shrinker tiles, then yes that would be a problem. But you really should be drawing your own, otherwise you are limited to the number of tiles and the timing of them being the way it was in vanilla.



No I mean you change the coords of the spawned sprite to move it instantly, like:

geta[].z z, sub z 2048, seta[].z z

i am using event_drawweapon,, wich is the odd thing. for both weapons actually, the shrinker and expander both have thier own new art located on different tilenums than the originals, but if i set weapon6_workslike 11 it displays the art for weapon 11

i'll try that method of moving the projectile in a minute

[Danukem]

jimbob, on 04 May 2021 - 11:33 AM, said:

i am using event_drawweapon,, wich is the odd thing. for both weapons actually, the shrinker and expander both have thier own new art located on different tilenums than the originals, but if i set weapon6_workslike 11 it displays the art for weapon 11

Make sure your display code checks player[].curr_weapon and not currentweapon; the former is the actual weapon the player is holding while the latter is the weapon being displayed. If you change workslike it does change the hardcoded display to show a different weapon.

[jimbob]

i changed currentweapon to the other code, and that works, but the problem persists, even if i move it to another slot. by the looks of it, its not the glow flag, but it seems to be the combination of fully automatic, and projectile weapon, the weapon just turns dark ( and since im making a flamethrower this is the opposite of what i try to achieve ) it also seems to do this on enemy sprites firing the same projectile ( a fireball )

defineprojectile 3907 PROJ_WORKSLIKE 6210 
defineprojectile 3907 PROJ_VEL 700 // was 1000
defineprojectile 3907 PROJ_EXTRA 10
// defineprojectile 3907 PROJ_DROP -100 // was 150
defineprojectile 3907 PROJ_BOUNCES 0
defineprojectile 3907 PROJ_RANGE 20
defineprojectile 3907 PROJ_BSOUND 0
defineprojectile 3907 PROJ_SPAWNS FLAMESPAWNER
defineprojectile 3907 PROJ_SHADE 75
defineprojectile 3907 PROJ_XREPEAT 13 // was 15
defineprojectile 3907 PROJ_YREPEAT 10 // was 15
defineprojectile 3907 PROJ_FLASH_COLOR 33791
// defineprojectile 3907 PROJ_TRAIL FRAMEEFFECT1
// defineprojectile 3907 PROJ_CSTAT 2
defineprojectile 3907 PROJ_HITRADIUS 0
defineprojectile 3907 PROJ_OFFSET 200

[Danukem]

Well, shade 75 is completely black and you have that set as the projectile shade, so that's weird unless you want the projectile to be black (but in that case why not use pal 4?). Maybe you want it black regardless of the sector pal.

Also it looks like the flash color would be purple based on that value of 33791, but I doubt that would matter. I can't really tell what's going on though without looking at your display code, which you have not shown yet.

[RichardStorm]

Danukem, on 03 May 2021 - 11:47 AM, said:

First I would make my own thrown tripbomb actor with a regular move command on it. While moving through the air, you can check for whether it hits wall like this:

ifnotmoving
{
        setvarvar temp sprite[].htmovflag
	andvar temp 49152
	ifvare temp 32768
	{
		// hit a wall

Second here is the source code the game uses to determine if the wall is valid for placement. It places if PlaceMine gets set to 1

case HANDHOLDINGLASER__STATIC:
        {
            int const zOffset     = (playerNum >= 0) ? g_player[playerNum].ps->pyoff : 0;
            Zvel                  = (playerNum >= 0) ? fix16_to_int(F16(100) - pPlayer->q16horiz - pPlayer->q16horizoff) * 32 : 0;

            startPos.z -= zOffset;
            Proj_DoHitscan(spriteNum, 0, &startPos, Zvel, shootAng, &hitData);
            startPos.z += zOffset;

            int placeMine = 0;
            if (hitData.sprite >= 0)
                break;

            if (hitData.wall >= 0 && hitData.sect >= 0)
            {
                uint32_t xdiff_sq = (hitData.pos.x - startPos.x) * (hitData.pos.x - startPos.x);
                uint32_t ydiff_sq = (hitData.pos.y - startPos.y) * (hitData.pos.y - startPos.y);
                if (xdiff_sq + ydiff_sq < (290 * 290))
                {
                    // ST_2_UNDERWATER
                    if (wall[hitData.wall].nextsector >= 0)
                    {
                        if (sector[wall[hitData.wall].nextsector].lotag <= 2 && sector[hitData.sect].lotag <= 2)
                            placeMine = 1;
                    }
                    else if (sector[hitData.sect].lotag <= 2)
                        placeMine = 1;
                }

            }

Oh pretty nice, thank you !

Also little trivia, it's evident from here that tripbombs cannot be placed in secret rooms XD (lotag 32767, and not-yet-discovered rooms actually, as when you step in lotag is reverted to 0)

[Danukem]

RichardStorm, on 04 May 2021 - 07:31 PM, said:

Oh pretty nice, thank you !

Also little trivia, it's evident from here that tripbombs cannot be placed in secret rooms XD (lotag 32767, and not-yet-discovered rooms actually, as when you step in lotag is reverted to 0)

That wall detection code could be improved by getting the actual wall number out of htmovflag, and there are instructions for that here:

https://wiki.eduke32.../wiki/Htmovflag

[RichardStorm]

Well yes, it can be improved in many ways, but I was actually searching for the essential part and i also got how sector and nextsector are handled when a wall is involved (that was an undiscovered chapter for me).

[jimbob]

Danukem, on 04 May 2021 - 04:55 PM, said:

Well, shade 75 is completely black and you have that set as the projectile shade, so that's weird unless you want the projectile to be black (but in that case why not use pal 4?). Maybe you want it black regardless of the sector pal.

Also it looks like the flash color would be purple based on that value of 33791, but I doubt that would matter. I can't really tell what's going on though without looking at your display code, which you have not shown yet.

that might be it, i have set the shade to black ( should have been fullbright, probably forgot the - :facepalm: ) but also have spritenoshade/pal on that particular sprite, that seems to be the problem, the weapon aparently takes the shade of the projectile for a moment, it seems to work great now both on the weapon as on the enemy.
[edit] setting the Z value seems to work fine, i tried using the same line, on the y and x axis and see if i can get the shells to spawn slightly infront of the player, but it goes wonky if the player turns around, my shells spawn correctly and fly off to the side, but they dont show up in the players view, only in trace mode.

[jimbob]

is there a way to get the distance a sound is played at? what i want to do is use event_sound to change certain sounds when you are far away, like explosions sounding more muffled. ifpdistg 10240 doesnt seem to work propperly.

onevent EVENT_SOUND
switch RETURN
case FTFIRE ifinwater set RETURN GENERIC_AMBIENCE4
case WAMBIANCE3 ifpdistg 10240 set RETURN WAMBIANCE7 break
endswitch
endevent

it works fine with other ifp commands like inwater.

[Danukem]

In that event, THISACTOR refers to the sprite from which the sound originates (if applicable). So I would try using dist DISTVAR THISACTOR player[].i to get the distance to player into DISTVAR and then decide whether to replace sound based on that.

You might want to add a game mode check to verify that gameplay is happening though, because in some contexts (e.g. menu before game starts) the player does not exist and that will cause an error.

[jimbob]

so something like this seems to work

gamevar DISTVAR 0 1

onevent EVENT_SOUND
ifactor BAZOOKAROCKET dist DISTVAR THISACTOR player[].i 
switch RETURN
case WAMBIANCE3 ifvarg DISTVAR 10240 set RETURN WAMBIANCE7 break

it seems to ignore the change in menus maybe because there is no distance to calculate. if i run into trouble i could add a ifp palive check, if your dead you probably wont notice distand sounds anyway anymore

yes, that completely gave the effect i was aiming for i might use the same for gunshots if i have time

[Danukem]

With that code DISTVAR will be unchanged when "ifactor BAZOOKAROCKET" is false, so don't be surprised when RETURN changes "randomly"

[jimbob]

i added a few actor checks for other common sound 'generators' like my custom mortars, the bazookarocket and seenine, heavybomb and ill add others if i run into issues. its too bad you cant the sounds distance itself but have to rely on the actor that initiated the sound.

[spacekebab]

I'm trying to get FIREBARREL to spawn a SECTOREFFECTOR which then "flickers" the sector. probably not a feasible solution considering how big some of the sectors are (E1L2). Still, having fun with it. Question is - anyway to revert the lotag back to 0 outright kill it once the "parent" sprite is destroyed?

        
case SECTOREFFECTOR
            ifspawnedby FIREBARREL {
                seta[].lotag 4
                geta[].sectnum mysectortemp
                gets[mysectortemp].floorshade shadetemp
                sub shadetemp 2
                seta[].shade shadetemp
            }
        break

[Danukem]

A couple of things. I would make the FIREBARREL do a check for SEs already in the sector before it spawns one -- you don't want to spawn an SE if one is already there. Maybe also check some other things about the sector before spawning so you don't spawn the SE on a conveyer or something unsuitable. Also I would make the SE save the shade in a per actor var when it is spawned, then have it reset that shade when it dies. You can just use killit on SEs and AFAIK it doesn't cause any issues.

[spacekebab]

Didn't even consider checking for any of that. Thanks! took care of it.

[jimbob]

i am trying to make a rudimentary waypoint system that makes the AI face the general direction of the waypoint actor so he generally walks in that direction. the idea is that i place a few points across the map and the AI wanders towards it, and once he reaches it it adds one to the count so he 'aims' for the next sequential one and not backtrack.

state navigate // navigate to the waypoint. 
findnearactor WAYPOINT 20480 TEMP // piece of code straight from the eduke32 wiki. modified for a rudimentary waypoint system.
ifvarvare MHITAG COUNT // make sure the waypoint he is going to is the next sequential one, so he doesnt backtrack. 
ifvarn TEMP -1
{
        getactor[TEMP].x MX
        getactor[TEMP].y MY
        getactor[THISACTOR].x x
        getactor[THISACTOR].y y
        subvarvar MX x
        subvarvar MY y
        getangle ANGVAR MX MY
        setactor[THISACTOR].ang ANGVAR
}
// here starts my own changes to make the system do what i need. 
// if the actor is within the accepted distance from the waypoint, make him aim for the next one by adding one to the count. 
findnearactor WAYPOINT 512 TEMP
ifvarn TEMP -1
{
addvar COUNT 1 
}
ends

the actor runs state navigate every once in a while during his seek state where he tries to find the player, the waypoint or an enemy. it needs a lot of work though. just asking of im on the right track with this. it needs a lot of work to make it somewhat more sophisticated but right now its just used to make soldiers move in a general direction instead of rather randomly around the map, or follow the player a round like a line of lemmings.

[Danukem]

Since you are new at this, verify that you can make your actors walk towards a single waypoint before you worry about incrementing the waypoint number. Test each piece of code and verify it works before adding more, it will save you a lot of trouble later. When you have a proven library and a lot of experience, that's when you can start implementing many things simultaneously.

As for whether you are on the right track, you are kind of on the way to making looping waypoints like the pigcop recon cars. Make sure you read the tag off of the waypoint so that you can compare it to the enemy's counter.

[jimbob]

Danukem, on 16 August 2021 - 11:34 AM, said:

Since you are new at this, verify that you can make your actors walk towards a single waypoint before you worry about incrementing the waypoint number. Test each piece of code and verify it works before adding more, it will save you a lot of trouble later. When you have a proven library and a lot of experience, that's when you can start implementing many things simultaneously.

As for whether you are on the right track, you are kind of on the way to making looping waypoints like the pigcop recon cars. Make sure you read the tag off of the waypoint so that you can compare it to the enemy's counter.

i will make a simple useractor that will move towards the waypoint at all times to check if it works. and you're right. i should really try to get one thing working before adding too much at the same time.

[jimbob]

well, i have it working with an incremental pathfinding way, but it has a problem. once it reaches the destination it keeps on moving in the direction it came from until the distance from the point he was going first is greater than the distance to the point he is supposed to be going to. what i need is a way to completely ignore the point ( and all others ) that are nót the ones he is going to, in other words only regard the waypoint actor that has the correct hitag as the only actor he could find.

tate navigate // navigate to the waypoint. 
findnearactor WAYPOINT 409600 TEMP 
getactor[TEMP].hitag MHITAG // TEMP is in this case the waypoint actor. 
ifvarvare MHITAG COUNT  // make sure the waypoint he is going to is the next sequential one, so he doesnt backtrack. 
                                            // IE only find nearactor with a hightag the count currently has, one at a time.
	ifvarn TEMP -1 // the actor should only care about the waypoint if both statements return true. 
	{
       		 getactor[TEMP].x MX
       		 getactor[TEMP].y MY
       		 getactor[THISACTOR].x x
       		 getactor[THISACTOR].y y
       		 subvarvar MX x
       		 subvarvar MY y
       		 getangle ANGVAR MX MY
       		 setactor[THISACTOR].ang ANGVAR
	}

// here starts my own changes to make the system do what i need. 
// if the actor is within the accepted distance from the waypoint, make him aim for the next one by adding one to the count. 
findnearactor WAYPOINT 512 TEMP2
	getactor[TEMP].hitag MHITAG
	ifvarn TEMP2 -1
	ifvarvare MHITAG COUNT  // add 1 to count only if the current waypoint has the same value as the one where the player was moving towards, 
                                                    //  used to prevent a retrigger causing the count to rise 1 every tick the actor is within the set distance
	{
		addvar COUNT 1
		spawn EXPLOSION2 // just to check if he reaches the correct point, and does not re-trigger the count. set off fireworks one you reach your goal.
		break // force restart of the subroutine
	}

ends

i tried putting a ifvarvarn MHITAG COUNT { break } after the actual getting the angle code but that didnt seem to work, if i place a waypoint between the actor, and it has not the correct hitag the actor will then ignore the one that does have the correct hitag, this makes figure 8 forms impossible, wich is something i could live with, but surely there is a way around it.
i was thinking allong the lines of running a search through the spriteid's until it finds the correct one before proceeding.

but my actor does not follow a simple path i layed out start to finish, so thats a win.

[Danukem]

Regardless of how many instances of the actor are within the distance, findnearactor will always return one result, so you can't use it to sort through them. The only time I would use findnearactor is when it really doesn't matter which one you are finding as long as it is within the distance. For example, if I had a paper actor that I wanted to catch on fire if a fire actor was near, then I might make it use findnearactor to search for close fires and then start burning on a positive result.

For pathing, if you are going to do a search at all (which may not be necessary depending on how you set things up), then you should start the search using statnum with a loop using commands such as headspritestat/whilevarn/nextspritestat. In the loop you can check picnum, distance, tags, or whatever you want.

[jimbob]

i tried setting up a headsprite loop but i dont know how to set it up, so it probably did an infinite runs and locked the game.
how could i set up a pathing system without doing a search for the correct pathnode? afaik no matter wich way tou slice it you are going to have to do a check to see if there is a pathnode within range, get wich node it is and make sure that the AI is going to the next sequential one in order to avoid it backtracking or going the wrong direction. my reasoning was to do a check ( findnearactor ) then check if it is the correct pathnode ( does it have Hitag 0? ) and if so move to that. then increment the search for hitag value +1 once it reaches the correct pathnode ( ignoring others in its patch because they do not equal the hitag value, wich is important because the closest he just reached will need to be ignored so he can immediatly fixate on the next one. )

[Danukem]

jimbob, on 19 August 2021 - 06:47 AM, said:

i tried setting up a headsprite loop but i dont know how to set it up, so it probably did an infinite runs and locked the game.

When I get some time I will put an example on the wiki (remind me if the weekend goes by and its still not there). Otherwise, if I post some code for you here, it will just be lost in time like so many other code snippets.

EDIT: You could also start the loop with "for spritesofstatus 1" which might be easier for you to get your head around:

https://wiki.eduke32.com/wiki/For

[Danukem]

Here you go:

https://wiki.eduke32.../Headspritestat

My example shows how to set up the loop. But instead of counting, what you want to do is check picnum (for the waypoint actor), then check its tag. If your moving actor has already latched onto a waypoint, you don't need to keep running the loop unless it is close enough to require going to the next one, or in case something has gone wrong.

[jimbob]

Awesome, i’ll study that later today. Hardly slept so the info will probably not stick. Updating the wiki was a great idea, who knows what great nuggets of info are burried in this thread.

[Mark]

Probably not much from this year but here is a folder of con tips and tricks I gathered from posts over the years. I released it before but maybe you missed it. Its unorganized but still very useful.

Attached File(s)

•  con code tricks.7z (141.1K)
  Number of downloads: 295