User:Krudat

Meben's Code Parade

You know when they say "Use the Source, Luke"? It's a suprising amount of work - and that's for someone who can almost read C++. Many times, when someone adds a bug in Mantis or posts in the forums, I read the code closely and try and find the relevant bits. I figured since I write it down, I might as well write it down where I can find it again, and where someone else might find it useful.

Rules: don't touch the lobby client, no snide commentary. Just code references.

(WebSVN doesn't give per-line anchors. So much for code references.)

=== #00048: Ferromancer: Unit Behavior: Construction units on patrol claim resources when not needed. === (Mantis)

Add a check around CBuilderCAI:452.

=== #00050: Ferromancer: Ground construction units attempt to repair air units while in flight === (Mantis)

I think CMD_PATROL is a point rather than a path. (And why does it push a copy of itself?) (And it's been that way since ancient SF CVS.) (Oh, and deque semantics are a pain - the docs don't define them very well. I hope commandQue.push_front(co) means commandQue[0] == co ...) [TODO Whoever made templated network messages can start on commands now. :P]

I'd still need to figure out how to tell if the current repair job is the fault of a patrol command, and how to abort it.

The policy question is how and when the con-bot decides to give up on the air unit and do something else. (How far is 'too far' from the patrol position?)

=== #00052: Bug Hunter: Units acknoledge enemy "bugger of" === (Mantis)

Perhaps Bug Hunter picked the phrase "bugger off" because that's what it's called in code. You can even do it from COB.

If you couldn't, I'd just get helper->BuggerOff to check team or ally relationships (or whatever it is). But for all I know, units only clear factory buildpads because the factory script asks them to.

---

ColCheckH and ColCheckV in groundmovetype.cpp tell fellow ground-pounders to get out of the way on close collision. I'd guess this is the code that prevents anyone ever making a nice neat line of units. =) Including, in this case, the enemy. Unfortunately, the rest of the file, at a glance, looks like Spring's ever-fragile ground pather.

=== #00066: Argh: S3O Explosion Behavior === (Mantis)

It shouldn't be impossible to let s3o pieces explode without SHATTER. Making s3os shatterable would take a little longer since we've got arrays of verticies rather than 3do-style faces.

However, in Feb. 2006, someone said something about writing a model-type abstraction that would include Ogre meshes, whatever those are. Again in March, someone's tinkering with unit textures.

=== #00068: Argh: Behavior of FALL scripting event === (Mantis)

Unfortunately, I don't have the source for the AA Vulcan, which features ejecting cases.

There's an ancient note that all such fragments must FALL otherwise they'll never go away.

I'd have to fire up OTA to get the correct behaviour.

(PieceProjectiles do exactly 50 damage.)

=== #00116: NOiZE: Cloakcosts are doubled === (Mantis)

Metal generation, energy use and idle regeneration are handled in CUnit::SlowUpdate().

Metal and energy gain and a couple of other per-unit-time values are divided in half in there, but the cloak energy cost isn't.

You can even see the 'half-cost' of things when you, say, turn a metalmaker, or a cloak, on or off.

=== #00118: Argh: Feature Request: "Free Interceptor" behavior. === (Mantis)

How they work now

The base Weapon inherit like it's willing to point any weapon at an incoming projectile (::CheckIntercept, called by CWeapon::Update). There's even a couple of interceptor-specific checks in it. However, only Starburst-type indirect-fire missiles have the right callbacks for being both interceptable and interceptors.

CStarburstLauncher::Fire tells CInterceptHandler about the new projectile, if it's weaponDef->targetable.

Only CStarburstProjectile takes an interceptTarget. In its ::Update, it checks if the nuke is 'close'. If so, it tells first the nuke then itself that they've hit something, which makes both of them blow up (helper->Explosion).

(It looks like the reason why the nuke's airburst doesn't do significant damage is because, on Small Divide, they travel higher than aircraft.)

Unpinning the behaviour

I haven't tried it, but it would be relatively easy to have an anti-nuke, say, Vulcan. (... It's the only salvoing unit who's projectile class I've looked up.)

• (Might need to change CWeapon::Update()'s call to CheckIntercept() to wait until the salvo ends, so the entire salvo points at the nuke. I haven't tested this.)
• Add the interceptTarget argument to CCannon and parameter to CExplosiveProjectile.
• Copy the range-to-nuke check to CExplosiveProjectile::Update() from StarburstProjectile.

This is nice and easy 'cause each interceptor round only needs to check one projectile (probably every frame). This presumes that more nukes than interceptors never happens - if not, then you'll get to see the volley of Vulcan fire take out one nuke, but probably mysteriously fail to destroy the other.

If I want to see a hail of laser fire from the Smasher completely defuse a volley from the Raven, I'd have a problem. Either:

• I do it the simple way and have every interceptor check every interceptable. I'd guess it'd be bad for performance. (Mustn't forget to check the ally-teams of the projectiles. ... Wait, they don't have any. :S)

• Someone who understands how the QuadField works extends it (re-fac-tor!) to record interceptable projectiles. Sadly, it mentions SQUARE_SIZE, which is my current cue to find some other aspect of Spring to read.

=== #000123: Decimator: Laser weapons will not even attempt to shoot through trees === (Mantis)

... and have done so since SF CVS day dot (BeamLaser.cpp).

One, two, skip a few...

Unit	Target DT?	Trees?	Weapon's class	Call responsible
Annihilator			CBeamLaser	helper->LineFeatureCol
Ambusher	X	X	CCannon
Rocko	X	X	CMissileLauncher
Raven	X	X
HLT			CLaserCannon	helper->LineFeatureCol
Defender	X	X	CMissileLauncher
Merl	X	X	CStarburstLauncher
Zeus			CLightningCannon	helper->LineFeatureCol
Maverick	?	X

I think there's an MTR somewhere here, but I'm not entirely sure what it is.

Unit sounds and position

Something only occasionally noted is that individual unit-selected sounds play where the unit is, so if you're zoomed out or off-screen, you can't hear them.

• Sound
• Making sounds audible again
• Soundvolume is too low when zoomed out
• volume vs distance

(MTR! *ahem* Maybe not.)

And some random sound-related posts

• Using play-sound in Spring, and how StartMoving() is called "exactly a bazillion times per second in first person view", like AimPrimary() apparently is. I'm not sure if I could try to fix it, and I am sure I'd add another strand of spaghetti to Spring on my first few attempts.
• please make the berthasound more quiet!. For the record, the DGun's sound has a specific volume nerf (CUnitLoader::LoadWeapon, near the bottom). It also suggests modder-settable sound-specific volume nerfs, or something.
• Sound effects still played if you have no LoS

]