Killed()

[Argh]

Try a turn or move. That's where I've run into problems. Moreover, the value of time == 6... something is very borked there, it should be 206, based on what the code says. Or... ah, it's 200 / 30, so 6. Meh. It's not even returning the value back in milliseconds. Interesting.

[Peet]

Try a turn or move. That's where I've run into problems. Moreover, the value of time == 6... something is very borked there, it should be 206, based on what the code says. Or... ah, it's 200 / 30, so 6. Meh. It's not even returning the value back in milliseconds. Interesting.

Any sleep is rounded to the next frame...that's not the point of his test. Nothing else was occurring between the get PRINTs.

[Argh]

I realize that

But, as I stated, I'm not testing with PRINT. The problems have been with move / turn instructions. Meh, it's probably not the fundamental problem here anyhow- that's a side issue, and if it's been fixed, great, but it doesn't change the fact that something borked is occurring.

So, is there any chance that this is something in FireballProjectile, which is the only Weaponprojectile that can be used right now for "rubble"? The bit about "sparks" looks like multiple projectiles are being created... is that correct, or is that just a particle effect?

[KDR_11k]

I tried interspersing turn commands. No difference, tested both speed and now. Do you mean wait-for-turn?

[Argh]

Nope, was talking about turn-now and move-now.

That's excellent news! Turn-now issues in previous versions of Spring prevented me from doing a few things that should now be possible.

Unfortunately, it's still a side issue. So... looking at cannon.cpp... hmm... if I specify OnlyForward and feed it a dir, maybe it'll do something useful, instead of shooting straight up...

[Argh]

<tests>

Drat. There really isn't any way to force Cannon WeaponTypes to force-fire and inherit dir. I'll set it up as a LaserCannon, instead. Trying to test theory that DGun might be the real problem, btw...

[Argh]

<tests>

Nope, it's not DGun. LaserCannon acts the same way.

It's something else, either in the code that force-fires stuff, or in Killed(). However, I don't see what it could be in Killed(), now that I've read through it, and the issues of return, etc. are now clear... hmm...

[Argh]

Ok, here's the code for emit-sfx 2048, which may be where the problem is. Note that it's mixing sync / unsync stuff...

Code: Select all

			else if (type & 2048)  //make a weapon fire from the piece
			{
				unsigned index = type - 2048;
				if (index >= unit->weapons.size() || unit->weapons[index] == NULL) {
					GCobEngine.ShowScriptError("Invalid weapon index for emit-sfx");
					break;
				}
				//this is very hackish and probably has a lot of side effects, but might be usefull for something
				//float3 relDir =-unit->localmodel->GetPieceDirection(piece);
				float3 dir = unit->frontdir * relDir.z + unit->updir * relDir.y + unit->rightdir * relDir.x;
				dir.Normalize();

				float3 targetPos = unit->weapons[index]->targetPos;
				float3 weaponMuzzlePos = unit->weapons[index]->weaponMuzzlePos;

				unit->weapons[index]->targetPos = pos+dir;
				unit->weapons[index]->weaponMuzzlePos = pos;

				unit->weapons[index]->Fire();

				unit->weapons[index]->targetPos = targetPos;
				unit->weapons[index]->weaponMuzzlePos = weaponMuzzlePos;
			}

[EDIT]

There's nothing right there that should cause this. I'm a bit curious about why Cannon can't get the weaponMuzzlePos, and is targetPos even necessary? We're force-firing stuff, we aren't supplying a target, period. That's probably why Cannon doesn't work- it expects a target, doesn't get one, and fails.

[Argh]

Ah, now we're getting somewhere!

Accuracy (the variable) is being ignored! If I specify a Sprayangle, then voila, I get different vectors, however I get 4 projectiles, whereas one is being called.

Methinks maybe ... hmm ... KDR, didn't you write some code that can create multiple projectiles from one point on one frame? <goes to look>

[Argh]

Hmm. I can't seem to find where these projectiles are being created. Time to test...

Nope, it doesn't work. Anybody have any other ideas? It doesn't look like it's happening due to COB, at least, not directly. It's not something specific about DGun. I don't see anything in the emit-sfx code that could be responsible, since it looks like it just calls one time there.

And I can't seem to find any reference to "projectilespershot", the integer variable, except in WeaponDef.cpp.

That's about the only missing link... that, and why emit-sfx 2048 requires a value for sprayangle before it'll actually spew at angles. But that's a side issue... oh well, I'll just set stuff up, and hope that eventually this gets fixed...

[imbaczek]

projectiles get spawned in Fire/FireInternal IIRC. BTW remember to look around in Weapon.cpp.

[lurker]

Can you compile spring? If you give me the unitname I'll make you a cob debug build that will output everything it does for that unit to be sure if it's cob or not.

[Argh]

I can't compile Spring, haven't done so in ages, would probably be hell in a handbasket getting it to compile again. As for unitname, it'd be RadarTank- that's what I'm using for testing...

Looked at Weapon.cpp, and it looks very straightforwards- if salvoLeft > 0, projectilesPerShot > 0, then create projectiles.

However, I've tested, and setting both to 0 in my weapons does not result in the weapon not firing.

I'll try to find the Fire() bit and go from there...

[KDR_11k]

The tag is just "projectiles" BTW. Emit-sfx ignores quite a few things.

[Snipawolf]

I have a no sleep emit weapon/sfx that does it up to 3 times.

Yes, this seems to be a problem. I don't need a single vehicle throwing out 20 pieces of debris @_@

Either I was really really tired then, or I was doin it wrong then, either way, I have Killed()'s that work perfectly fine in rev 5047.