[XThX2]

Quote

Sound (#-1) not defined!

At random times, I get this notification on console. Why would this ever happen ? (The #-1 sound definition thing)

[Helixhorned]

High Treason, on Mar 14 2010, 01:44 PM, said:

This is gonna be a really, really stupid question , but can I make an event cause a completely different one to happen?

No, since events are just certain points in the game code where the EVENT_SOMETHING blocks get executed, and AFAIK there's no such command as "throw event".
However, couldn't you just duplicate the event code in a state and call that? There's probably some care to be taken with respect to variable bindings (per-player/per-actor), this always confuses the hell out of me .

[Fox]

DeeperThought, on Mar 10 2010, 03:40 AM, said:

I come up against a problem involving the map mirroring code that Plagman wrote. It chokes on a certain map, Legends2.map What happens is it gets into an infinite loop in this part of the mirroring code:

setvar I 0
whilevarvarn I NUMWALLS
{
	setvarvar A I
	getwall[I].point2 B
	setvarvar K I
	whilevarvarn A B
	{
		addvar K 1
		getwall[K].point2 B
	}

The whilevarvarn A B loop assumes that if you keep incrementing K (where K is some arbitrary wall number), then the point 2 of K will eventually loop back around and be equal to K's starting value (which is saved in A). This is true in every map I have encountered except for this one. Does that mean that the map is corrupt, or what? And how would I go about fixing the code? I can't just make it bail out because it has already swapped a lot of walls by the time it it goes infinite and the result of bailing would be a bizarre corrupted map.

EDIT: Here's what I did for now --

(...)

If on some I, K reaches an invalid wall number, it stops the loop and does not proceed with the wall swap for that I. However, it proceeds with the next I. So far it seems to work ok.

If I get it, all this massive code involving "point2" is to get all walls from a specific sector?

[m210®]

Help me to make rocketjump, which will be working in multiplayer
I tried to used movesprite-command for inertia of actors, like it

	getactor[THISACTOR].htextra htextra
	ifvarg htextra 0 setvarvar k_damage htextra
	  getactor[THISACTOR].htang a
	cos x a
	sin y a
	getactor[THISACTOR].htg_t 0 b 	// actor`s count - deacceleration
	mulvar b 8						
	setvarvar tmp k_damage		 // damage
	iffloordistl 10					// deaccelerate on ground
	subvarvar tmp b
	ifvarl tmp 0 setvar tmp 0	 // clamping multiplier
	mulvarvar x tmp				// roll force = damage - deacceleration
	mulvarvar y tmp
	shiftvarr x 12
	shiftvarr y 12
	setvar z 0
	ifwasweapon RADIUSEXPLOSION  // Additional up velosity from explossion
	{
		divvar x 3
		divvar y 3
		setvar z -100
		subvarvar tmp b
		mulvarvar z tmp
	}
	movesprite THISACTOR x y z CLIPMASK0 RETURN

But it had unsynchronization and had many bugs in multiplayer. Single game works fine.

[The Commander]

Try to place the code in an event and call it as a state for the actors.

I had issues with trying to move actors to where I wanted them to go after they had died and reset in MP till I made it as a state in a event.

[Danukem]

The Commander, on Mar 24 2010, 08:45 PM, said:

Try to place the code in an event and call it as a state for the actors.

I had issues with trying to move actors to where I wanted them to go after they had died and reset in MP till I made it as a state in a event.

The code should be a state or part of a state that is called by an actor when its htextra is > 0 or k_damage > 0 (I'm guessing that k_damage can be > 0 for a few tics after the actor has been hit, and there is additional code somewhere that is reducing k_damage over time)

[m210®]

Inertia of actors code is working for single game for any actors and player, but if used that code in multiplayer for player, after a while coordinates of the player don't coincide with coordinates sprite of the player, and to hit the player, it is need to shoot at air near to player. I think this problem have a movesprite command and need to use setplayer[].posx instead movesprite. But if just to change coordinates, the player can easily appear outside of map. That is problem too.
I'll trying test it again in multiplayer. May be I'll find the problem at my code.

And second question: I tried to use htbposx to player. Why this member repeats coordinates of the player?
I think it is need for make rocket-jump

[The Commander]

Don't use setplayer[].posx etc inside the APLAYER code for MP use. That's just going to give you trouble.

[The Commander]

What is the less code intensive (MP Wise) way to stop actors/player from flying different directions from "hitradius" infact, if I could remove the effect entirely all together would be great.

http://www.youtube.com/watch_private?v=Xy3...IMSfwYvhRVu1adg - 1:40 is what I am talking about.
Oddly enough, in MP clients ignore the movement effect but still suffer the damage from hitradius which is what I am after.

[m210®]

can you show the code?

[The Commander]

M210, on Mar 27 2010, 12:24 AM, said:

can you show the code?

code for what?
All actors do this when hit with hitradius

[Fox]

You want some actors to be immune to hitradius? If you check if actor.htpicnum equal to RADIUSEXPLOSION and them set actor.htextra to -1 it will be nullified. But it will also stop some generic explosions too, like Pipebomb I believe.

[The Commander]

Fox, on Mar 27 2010, 01:51 AM, said:

You want some actors to be immune to hitradius? If you check if actor.htpicnum equal to RADIUSEXPLOSION and them set actor.htextra to -1 it will be nullified. But it will also stop some generic explosions too, like Pipebomb I believe.

No, I am just trying to nullify the impact/movement you get from hitradius but still suffer the damage from the hitradius.

Your code would stop both would it not from a glance.

[Fox]

Well, you can "hack" it storing the actor.ang and actor.xvel from last tic and set it whenever the actor.hitradius is over not -1. I think you would need to take some care whenever you change the speed during that tic...

[Jan Satcitananda]

Guyz. The NUMSECTORS and NUMWALLS variables are treated as read-only. So, can't I generate new sectors during the game?

[williamjcm]

Hello again.

I played Call Of Duty 4: Modern Warfare a month ago and I noticed the health regen system.

I tried to code it into my mod. OK, works. But too fast (like 20 health points per second).

I want the HP to regen at 1hp per second if you manage to avoid shots for 3 seconds.

I might found the way for the 1hp per second :

// all APLAYER code above
if count 16 { addphealth 1 resetcount } // If one second isn't 16, tell me.
enda

But what about the 3 sec wait time. I am still unexperienced with the ifcount and similar commands.

[XThX2]

I think 26 tics is one second. Use that instead.

[Marcos]

I use this health system on my MOD!!
It's very cool!!

[XThX2]

So I have been messing with horiz member of player and got an interesting idea for a weapon, which I couldn't seem to pull off.

How can I make 3 projectiles be shot such that they form a vertical line and one of them is slightly above the crosshair (where the player is aiming), the other in the middle and the third slightly below the crosshair ? I was kind of hoping I could use horiz for this, but after lots of tries I guess I can't.

[CruX]

XThX2, on Apr 14 2010, 08:04 AM, said:

So I have been messing with horiz member of player and got an interesting idea for a weapon, which I couldn't seem to pull off.

How can I make 3 projectiles be shot such that they form a vertical line and one of them is slightly above the crosshair (where the player is aiming), the other in the middle and the third slightly below the crosshair ? I was kind of hoping I could use horiz for this, but after lots of tries I guess I can't.

Horiz has more to do with the camera than anything else, so no, I don't imagine it would be useful for what you're trying to do. I would probably just create the weapon from scratch, make three unique projectiles for each position, then have the player shoot them when the fire button is pressed. You could edit the z-position of each projectile in event EGS (or maybe use RETURN after they're shot and edit it right there on the spot). Of course, that's right off the top of my head, but it makes sense to me.

[XThX2]

I thought about it, but no it doesn't do me any good because I need the "angle the player is looking at Z" to have all 3 projectiles go to where the player aimed. That way, you can't do that, because the only varying factor is player's height.

[CruX]

XThX2, on Apr 14 2010, 09:34 AM, said:

I thought about it, but no it doesn't do me any good because I need the "angle the player is looking at Z" to have all 3 projectiles go to where the player aimed. That way, you can't do that, because the only varying factor is player's height.

Well, you can use horiz to check whether or not the player's aiming up/down, and change the projectile from there, it's just that horiz can't/isn't supposed to directly manipulate it.

[CruX]

I've been trying to code enemies to load into the map with a certain idle state shows all of their angles (whether they see the player or not). Now, I got that to work easily enough, but I also wanted them to pursue the player ONLY if he was in a certain field of vision, so I figured what I could do was get the angle difference between the player and the enemy (i.e, what angle the enemy would have to be at to be facing the player), then add and subtract a number from it, and only have the enemy go into it's seeking AI if it's angle fell between the two numbers that were produced.

ifai AIT1IDLE // if the bad guy is in his idle state
{ ifcansee {
getplayer[THISACTOR].posx PERPLAYER1 
getplayer[THISACTOR].posy PERPLAYER2
getactor[THISACTOR].x TEMP1
getactor[THISACTOR].y TEMP2
subvarvar TEMP1 PERPLAYER1
subvarvar TEMP2 PERPLAYER2
getangle TEMP3 TEMP1 TEMP2 // get the angle he'd have to be at to be facing the player
ifvarl TEMP3 0 { mulvar TEMP3 -1 } // and if that angle happens to be less than zero, multiply it by -1
setvarvar TEMP6 TEMP3
setvarvar TEMP7 TEMP3 // store that value in two separate vars for later use


getactor[THISACTOR].ang TEMP5 // get the actor's actual angle

subvar TEMP6 200 // subtract 200 from one of the stored values
addvar TEMP7 200 // and add 200 to another, so this should create an array of values between TEMP7 and TEMP6 where the enemy can see the player

ifvarvarl TEMP5 TEMP7  { ifvarvarg TEMP5 TEMP6 { ai AIT1WALK } } // if the bad guy's angle is greater than the minimum needed angle, but less than the maximum, have him seek the player

This code does, in some small capacity work. Only problem is, it isn't working from the angle I 'need' it to be working from. The bad guy only goes into his seeking AI if I'm behind ( and usually kind of off to the side of) him. If I'm in front of him, he just stands there. The only thing I thought could fix this problem was adding 1024 to the needed angles, thinking that'd flip the values around or something, but he didn't do anything at all when I did that. Can anyone tell me what I'm screwing up?

EDIT: Nevermind, I think I just got it to work. I don't know if the math was suppose to be like this, but I flipped it around to where the enemy's angle subtracts from the player's angle, and it's working like a charm now.

[Danukem]

I have working code for this somewhere. It goes like this:

1) Calculate the angle that would make the actor face the player (let's call this ANGLE1)

2) Use getincangle to calculate the difference between the actor's current angle and ANGLE1. The difference, which is the return var of the getincangle command, we will call DIFF.

3) If the absolute value of DIFF is less than 512 (or whatever number you deem appropriate) then the player is in the actor's cone of vision.

[CruX]

DeeperThought, on Jun 11 2010, 10:39 AM, said:

I have working code for this somewhere. It goes like this:

1) Calculate the angle that would make the actor face the player (let's call this ANGLE1)

2) Use getincangle to calculate the difference between the actor's current angle and ANGLE1. The difference, which is the return var of the getincangle command, we will call DIFF.

3) If the absolute value of DIFF is less than 512 (or whatever number you deem appropriate) then the player is in the actor's cone of vision.

Hmmm. I gave it a whirl and didn't have any luck, I may have misinterpreted something, though I've changed everything that might have caused it not to work, and the guy still switches into his seeking ai.

Quote

ifai AIT1IDLE
{ ifcansee {
getplayer[THISACTOR].posx PERPLAYER1
getplayer[THISACTOR].posy PERPLAYER2
getactor[THISACTOR].x TEMP1
getactor[THISACTOR].y TEMP2
subvarvar PERPLAYER1 TEMP1
subvarvar PERPLAYER2 TEMP2
getangle TEMP3 PERPLAYER1 PERPLAYER2 // get the angle he needs to face the player
ifvarl TEMP3 0 { mulvar TEMP3 -1 }
getactor[THISACTOR].ang TEMP5 // get his current angle
getincangle TEMP7 TEMP3 TEMP5 // get the difference between the two. When I first tried this, I had TEMP3 and TEMP5 swapped around, and he'd switch into his seeking ai as soon as I entered
// the room. With the variables like this, he doesn't do it immediately but he winds up doing it if I get to close, even though I haven't changed angles.

ifvarl TEMP7 512 { ai AIT1WALK break } // changing 512 to any other value doesn't seem to do anything


} }

I probably just royally screwed something up, but I've made all the changes I can think of.

[Danukem]

Do not mulvar TEMP3 -1, because that will mess up the result of getincangle

Instead, use ifvarl TEMP7 0 mulvar TEMP7 -1 after the getincangle

If you look at my previous post, you'll notice that I said to use the absolute value of the result of getincangle, not to change something to an absolute value before getincangle

I'm assuming you have your variables in the correct order for getangle etc.

[CruX]

DeeperThought, on Jun 11 2010, 11:52 AM, said:

Do not mulvar TEMP3 -1, because that will mess up the result of getincangle

Instead, use ifvarl TEMP7 0 mulvar TEMP7 -1 after the getincangle

If you look at my previous post, you'll notice that I said to use the absolute value of the result of getincangle, not to change something to an absolute value before getincangle

I'm assuming you have your variables in the correct order for getangle etc.

Yeah, that must've been what I did wrong, because I moved that line below the getincangle command and it works. So I've got two functional methods of doing this now, but I think I'll probably end up using yours because it's a bit less code-intensive and it looks like it can be manipulated to work with player distances a bit more easily as well. Thanks, DT.

[Chip]

Hello!

The other day I decided to make it so the palfrom "tint" that comes on screen when the player takes damage, to be controlled through gamevars and the .pals on the player strcture.
However, I can't see how to set the "tensity" using .pals and didn't see anything else that could control this. Without the tensity, even a colour of 64 is very faded.

So, how can I control the "tensity" of tints set through .pals.

[Danukem]

Chip, on Jul 3 2010, 04:55 AM, said:

Hello!

The other day I decided to make it so the palfrom "tint" that comes on screen when the player takes damage, to be controlled through gamevars and the .pals on the player strcture.
However, I can't see how to set the "tensity" using .pals and didn't see anything else that could control this. Without the tensity, even a colour of 64 is very faded.

So, how can I control the "tensity" of tints set through .pals.

Do you mean intensity? If so, then it's controlled by the pals_time member of the player struct. It's not stated in the description, but the greater the time left, the greater the intensity.

[Chip]

Yeah, I did mean intensity.

Thanks!