[Mark]

Its been a few years but I seem to remember the animation plays automatically at level end if you create it in .ivf format and name it cineov2.ivf and I placed it in the root folder in my project. If you want sound, the file needs to be triggered at the same time. This info is online somewhere because thats where I got it from. I'm assuming the original .anm format still works too.

edit:
https://wiki.eduke32...%3ASearch&go=Go

[jimbob]

The problem.is that episode 1 doesnt use an anm file but hardcoded tiles, so i cant just replace the anm/ifv file unfortunatly.

[Mark]

Ah, maybe I defined my level to episode 2 so I could use cineov2.ivf

I just checked. Thats what I did.

[Danukem]

If this is a major sticking point, you could make episode 1 a tutorial level or a credits level, then make episode 2 your actual episode.

[jimbob]

that seems like the easy way to do it, i'll probably do that

[jimbob]

meh, how do i remove the nasty glow effect from the shrinker, it seems persistent no matter how i configure the weapon6_flags i get it working without the glow when i remove automatic weapon functions like flag 8 and 16, but i need those.
the expander does not seem to do this.
on a related question, i have a custom projectile, but it seems to originate from the players bottom center, the RPG seems to originate from the weapons actual position, how do i get my custom projectile to originate from the actual weapon position? or, if atleast spawn somewhat infront of the player

[Danukem]

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.

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.

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