Duke4.net Forums: EDuke32 Scripting - Duke4.net Forums

Jump to content

  • 108 Pages +
  • « First
  • 90
  • 91
  • 92
  • 93
  • 94
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 Scripting  "CON coding help"

User is offline   jimbob 

#2731

View PostDanukem, 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 :o

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 :(

This post has been edited by jimbob: 02 May 2021 - 12:41 PM

0

User is offline   Danukem 

  • Duke Plus Developer

#2732

View Postjimbob, 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 :o


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.

View Postjimbob, 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
0

#2733

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

User is offline   Danukem 

  • Duke Plus Developer

#2734

View PostRichardStorm, 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;
                }

            }

1

User is offline   jimbob 

#2735

View PostDanukem, 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
0

User is offline   Danukem 

  • Duke Plus Developer

#2736

View Postjimbob, 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.
0

User is offline   jimbob 

#2737

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


This post has been edited by jimbob: 04 May 2021 - 01:34 PM

0

User is offline   Danukem 

  • Duke Plus Developer

#2738

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

#2739

View PostDanukem, 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)
0

User is offline   Danukem 

  • Duke Plus Developer

#2740

View PostRichardStorm, 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
0

#2741

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).
0

User is offline   jimbob 

#2742

View PostDanukem, 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.

This post has been edited by jimbob: 05 May 2021 - 02:55 AM

0

User is offline   jimbob 

#2743

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

User is offline   Danukem 

  • Duke Plus Developer

#2744

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

User is offline   jimbob 

#2745

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 :P

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

This post has been edited by jimbob: 22 May 2021 - 11:59 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#2746

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

User is offline   jimbob 

#2747

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

User is offline   spacekebab 

#2748

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

0

User is offline   Danukem 

  • Duke Plus Developer

#2749

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

User is offline   spacekebab 

#2750

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

User is offline   jimbob 

#2751

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

User is offline   Danukem 

  • Duke Plus Developer

#2752

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

User is offline   jimbob 

#2753

View PostDanukem, 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.
0

User is offline   jimbob 

#2754

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.

This post has been edited by jimbob: 17 August 2021 - 02:41 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#2755

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

User is offline   jimbob 

#2756

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. )
0

User is offline   Danukem 

  • Duke Plus Developer

#2757

View Postjimbob, 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

This post has been edited by Danukem: 19 August 2021 - 12:55 PM

0

User is offline   Danukem 

  • Duke Plus Developer

#2758

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

User is offline   jimbob 

#2759

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

User is offline   Mark 

#2760

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)


1

Share this topic:


  • 108 Pages +
  • « First
  • 90
  • 91
  • 92
  • 93
  • 94
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options