[Danukem]

EmericaSkater, on Nov 20 2009, 08:20 AM, said:

using cstat commands beneath the APLAYER line didn't do anything...

That's because the sprite you see in F7 mode is not the player sprite. It's a member of the tsprite array which is used only for display purposes. To access that array, use EVENT_ANIMATESPRITES. Only sprites with the 16 bit set in their mdflags member will be processed in that event, so do that first:

actor APLAYER MAXPLAYERHEALTH PSTAND 0 0

getactor[THISACTOR].mdflags temp
orvar temp 16
setactor[THISACTOR].mdflags temp

Then, since only player tsprites will be processed and you want them to have cstat 0, do this:

onevent EVENT_ANIMATESPRITES
settspr[THISACTOR].tsprcstat 0
endevent

[CruX]

DeeperThought, on Nov 20 2009, 09:34 AM, said:

That's because the sprite you see in F7 mode is not the player sprite. It's a member of the tsprite array which is used only for display purposes. To access that array, use EVENT_ANIMATESPRITES. Only sprites with the 16 bit set in their mdflags member will be processed in that event, so do that first:

actor APLAYER MAXPLAYERHEALTH PSTAND 0 0

getactor[THISACTOR].mdflags temp
orvar temp 16
setactor[THISACTOR].mdflags temp

Then, since only player tsprites will be processed and you want them to have cstat 0, do this:

onevent EVENT_ANIMATESPRITES
settspr[THISACTOR].tsprcstat 0
endevent

Works great. I had the feeling the sprite in 3rd person wasn't actually a player sprite since it would never show up without turning over_shoulder_on to 1 (no matter where I had the camera positioned). Tsprites were probably the one thing I never looked that much into . Thanks abunch, DT

[Fox]

It is the player sprite itself, only the cstat is special set-up.

They use that because otherwise other player would see a transparent player, which they shoudln't.

It's the same as a sprite standing in a colored sector, it has another tspr palette in a normal sprite.

Note: take care to not change the cstat of player shadow using tspr.

[m210®]

Help me with cansee command!

	setvar spriteid 0
	setvar minimum 16777216
	setvar minid -1
	whilevarn spriteid 16384
	{
		getactor[spriteid].picnum picnum
		switch picnum
		case LIZTROOP
		{
			getactor[spriteid].x mx
			getactor[spriteid].y my
			getactor[spriteid].z mz
			getactor[spriteid].extra extra
			getactor[THISACTOR].x x
			getactor[THISACTOR].y y
			getactor[THISACTOR].z z
			subvarvar mx x
			subvarvar my y
			getangle mang mx my
					getactor[THISACTOR].ang ang
			getincangle mang mang ang
			ifvarg extra 0
			ifvarg mang -256 ifvarl mang 256
			{
				dist tmp THISACTOR spriteid
				ifvarvarl tmp minimum { setvarvar minimum tmp }
				ifvarvare tmp minimum ifvarvarn spriteid THISACTOR setvarvar minid spriteid
			}
		}
		break
		endswitch
		addvar spriteid 1
	}
	
	ifvarn minid -1
	{	
		getactor[minid].x mx
		getactor[minid].y my
		getactor[minid].z mz
		getactor[minid].sectnum sect2

		cansee camerax cameray cameraz camerasect mx my mz sect2 see
		addlogvar see
			}

In case at picture see variable equal is 0, why?
canseespr isn't works correctly and have more cases when see variable = 0

Help me to fix this problem! please

Attached File(s)

•  duke0000.bmp (769.05K)
  Number of downloads: 209

[Danukem]

M210, on Dec 5 2009, 07:36 AM, said:

In case at picture see variable equal is 0, why?

Canseespr wasn't working because you didn't raise the sprites up before checking. This is a very common problem and there should be something in the wiki about it (I'll add it to canseespr if it isn't there yet). canseespr determines visibility from the base of the sprites (the bottom of their feet) which is a poor position to see from. You made the same mistake with cansee. Try using subvar mz 8192 right before the cansee command.

[m210®]

Thanks, but it hasn't helped
Screenshot, see = 0

Attached File(s)

•  Untitled_1.bmp (873.8K)
  Number of downloads: 212

[Danukem]

M210, on Dec 5 2009, 09:35 AM, said:

Thanks, but it hasn't helped
Screenshot, see = 0

The change I suggested is necessary, so if it didn't help it's because some other part of your code is not working (probably that getincangle part). You should test the different components of your code separately. Make sure each component is working correctly before you put them together.

EDIT: I just ready throgh your code for the first time, and it's really weird. Who is THISACTOR? Is that the player? You have some sprite looping through all the sprites in the game, and when it gets to a LIZTROOP it checks whether it is facing it. But if the sprite running the code isn't the player, then there's no reason to believe there should be visibility in the screenshot. But if it is the player, then there is no reason to check ifvarvarn spriteid THISACTOR (since we already know the player isn't a LIZTROOP).

[m210®]

Other part of my code works true, because I tried to use ifcansee command and it worked, but this command gave variable = 1 even if actor was behind a wall.

Well, I try to delete getincangle part but it will not helped

[Danukem]

M210, on Dec 5 2009, 10:17 AM, said:

Other part of my code works true, because I tried to use ifcansee command and it worked, but this command gave variable = 1 even if actor was behind a wall.

Well, I try to delete getincangle part but it will not helped

Read my edit above.

[m210®]

Quote

EDIT: I just ready throgh your code for the first time, and it's really weird. Who is THISACTOR? Is that the player? You have some sprite looping through all the sprites in the game, and when it gets to a LIZTROOP it checks whether it is facing it. But if the sprite running the code isn't the player, then there's no reason to believe there should be visibility in the screenshot. But if it is the player, then there is no reason to check ifvarvarn spriteid THISACTOR (since we already know the player isn't a LIZTROOP).

I just deleted all the cases in the switch, and this switch had all the enemies including APLAYER as cases!
Yes, THISACTOR is PLAYER and "ifvarvarn spriteid THISACTOR" check is performed because other players exist in multiplayer and Voodoo weapon will do damage to THISACTOR APLAYER if not to check it.

		case LIZTROOP
		case OCTABRAIN
		case COMMANDER
		case PIGCOP
		case LIZMAN
		case GREENSLIME
		case NEWBEAST
		case BOSS1
		case BOSS2
		case BOSS3
		case BOSS4
		//case APLAYER

I think I have found an error.
With case APLAYER deleted this code works correctly, but why the code doesn't work with "case APLAYER"?

[Fox]

I want to add a change at already defined [[Definegametype]] modes. Although I don't know the default values of the original modes. I can guess them, but I can't trust that method.

Anyone has a list?

[Simon_Croes]

Hey guys, I got a little request about the muzzle flash of the chaingun. Well you know that the tile only got 1 animated flame. But it's copied 3 times (for the 3 barrels).
Here is a screenshot to make my question more clear.

Is it possble to delete/change it with con coding and replace/hange it with one muzzleflash?

Thanks in advance guys.

Attached thumbnail(s)

• 

[Fox]

You should experiment drawing weapons onscreen. That one should not be hard, you would replace the normal muzzle tile with a blank one, and them draw in event_drawweapon a new muzzle.

[Danukem]

Ilovefoxes, on Dec 6 2009, 03:58 PM, said:

You should experiment drawing weapons onscreen. That one should not be hard, you would replace the normal muzzle tile with a blank one, and them draw in event_drawweapon a new muzzle.

Yes it would be hard, because he would have to cancel the hardcoded drawing of the weapon and draw it and the muzzleflashes using rotatesprite. With positioning, weapon bob, shading etc. to worry about, that's a lot of work if you don't already have code for it or know how to do it.

[Fox]

Yes. But he don't need to cancel the Chaingun code, since rotatesprite will draw below the default weapons.

[Chip]

How would I make actors including the player detect when they are hit by RADIUSEXPLOSION?
That attack doesn't seem to write into the .htextra and instead bypasses it completely and goes straight to subbing it from the actor's extra thus foiling my plan of simply having it check htextra for positive values.

[Danukem]

Chip, on Dec 7 2009, 08:37 AM, said:

How would I make actors including the player detect when they are hit by RADIUSEXPLOSION?
That attack doesn't seem to write into the .htextra and instead bypasses it completely and goes straight to subbing it from the actor's extra thus foiling my plan of simply having it check htextra for positive values.

I didn't know it worked that way. It still sets .htpicnum, but if what you say is true then I don't know you could tell how much damage was caused. You don't have to use hitradius, though. You could use an invisible custom projectile that blows up immediately.

[Chip]

The same thing also happens with floor damage which the player takes from such flooring as HURTRAIL, FLOORPLASMA etc.
I'm not too sure what method I may use to counter these. Also I'm unsure what exactly you mean by spawning invisible projectiles since they'll have to make contact with an actor to inflict damage else it'll be a hitradius and having the exposion shoot invisible projectiles to fulfill a radius will causes problems (some actors get hit more than once some may not be hit, and there will need to be alot around in a 360 bubble to hit actors higher then the blast)

Another failed ploy was to have actors constantly seek invisible actors dedicated for explosion radiuses but using findnearactor can only get ahold of one meaning actors in a barrage of explosons only get hit once. Using the oh so popular "cycle through all sprites" thing will cause lag since my actors will be doing this all the time. Unless I reverse it so only the damaging inflicting object seeks through all sprites of what it may hit but it'll still cause lag when multiple explosions are going off.

[XThX2]

I think you can use, which is what I use for my random damaging projectiles, detect the htpicnum of the invisible projectile and make it deal damage to player in APLAYER code. You can generalize it with a switch too, it's pretty customizable that way.

About the floor, you can do the same thing, except this time you would check the sector's picnum, deal some damage every tic the player is on the sector. (But when not jumping)

[Fox]

I have heard around there that findnearsprite consumes too much processing. Does "cycle through all sprites" using headspritestat and whilevarn consumes less than it?

[Danukem]

Ilovefoxes, on Dec 8 2009, 05:15 PM, said:

I have heard around there that findnearsprite consumes too much processing. Does "cycle through all sprites" using headspritestat and whilevarn consumes less than it?

If you know that the statnum of the sprite you are looking for is 1, then findnearactor would be more efficient than looping with headspritestat/whilevarn, unless you have some other reason to use a loop. If the statnum is 0, then using headspritestat/whilevarn is probably faster than findnearsprite, because the loop would only be checking the statnum 0 sprites.

[Milo]

Quick newbie guestion: Where are the weapons defined in the CON files? I don't mean the tile definitions, but the actual code for the weapons. I was planning on copy-pasting to get started on some custom weapons but can't find it anywhere...

[Jimmy]

Weapons are hardcoded, its not present in the confiles.

[Fox]

You can, otherwise, start checking this page: http://wiki.eduke32....pdated_gamevars

[Milo]

I've read all through what I think is the right stuff about creating weapons, but still have no clue as to how to actually do it... If someone could post a simple example script for a weapon, even recreating the pistol in CON coding that would be an enormous help and I'd be fine from then on.

[The Commander]

It may be easier if you could tell us if you want to replace an existing weapon or add new ones to the ones already available.

The first option is easier, has the existing weapons can be modified to work the way you want your new weapon to.

[Milo]

Replacing the existing weapons. I can replace them graphically easily enough but only by changing around the tiles, not adding new frames or anything.

[NerdZilla]

Milo, on Dec 29 2009, 03:01 PM, said:

Replacing the existing weapons. I can replace them graphically easily enough but only by changing around the tiles, not adding new frames or anything.

weapons are just about the only thing i've learned at this point. i mite help aboul to you. im attemping to make a goldeneye style reload. a simple, gun drops off screen (sounds FXs) gun come back on screen...

for the most part im begining to realise the math behind the game is alot like N64 games. the Skycar is only a few more codes away from something like Starfox 64 in all range mode.
nintendo did some really well thought out programing for there day on N64... look into it, you'll see. what thay where working with and what thay did... its down right amazing insperation to a newbie like me. even, though i dont think i'll get that good at it.

[Jimmy]

insane_metalhead, on Dec 6 2009, 01:06 PM, said:

Hey guys, I got a little request about the muzzle flash of the chaingun. Well you know that the tile only got 1 animated flame. But it's copied 3 times (for the 3 barrels).
Here is a screenshot to make my question more clear.

Is it possble to delete/change it with con coding and replace/hange it with one muzzleflash?

Thanks in advance guys.

Simple, all you have to do is make the muzzle flash a null tile. Then you can add your muzzle flash onto the shooting frames of whatever weapon you want, like the pistol art. It's what was done before all this new fancy confangled coding we got now.

[Milo]

NerdZilla, on Dec 30 2009, 03:26 AM, said:

weapons are just about the only thing i've learned at this point. i mite help aboul to you. im attemping to make a goldeneye style reload. a simple, gun drops off screen (sounds FXs) gun come back on screen...

for the most part im begining to realise the math behind the game is alot like N64 games. the Skycar is only a few more codes away from something like Starfox 64 in all range mode.
nintendo did some really well thought out programing for there day on N64... look into it, you'll see. what thay where working with and what thay did... its down right amazing insperation to a newbie like me. even, though i dont think i'll get that good at it.

Any help at all would be appreciated!