User:Krudat

Hmm, new scripting language, eh?

A lot of what's given here is ... "structurally sensitive"? Specifically, I get the impression Zaphod would like to delay some feature additions until a new scripting language arrives (and Argh might agree, I think). More generally, what's the easy fix or implementation might not be the best structurally (even before the level of finding some weird replacement for COB).

Implementing a change is easy. Doing it right, particularly in the eyes of the admins, is another matter.

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

=== #00105: FizWizz: FPS aiming === (Mantis)

Here's one for the compiler trivia books. The (original) GetHAndPFromVector (in myMath.h - WebSVN doesn't like links across file moves) crashed in one quarter (under Linux only!). However, I bet the call to COBFN_AimPrimary in CWeapon::Update was working fine, despite using similar code, and probably wanting the same results.

Commenting out the code to ask the FPU to choke immediately probably made it exhibit something like the current behaviour, I can't remember.

(Called at the top of Game/Game.cpp::Update.)

GetHAndPFromVector is only used in one place, for the direct-control stuff.

=== #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.

#000119: Argh: Feature Request: "Free Repulsor".

Note: The beam laser projectile does the drawing; you'll find the damage ("explosion"!) is done when the weapon ::Fire()s.

If I pin down the math for a ray reflection, it'll get used two different ways in two places; once in the reflector to give laser bolts a new heading, and again in BeamLaser to bounce off repulsors (with an extra projectile per reflection) 'till something gets hit.

=== #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

Hmm. I could almost sketch out a design for a new "ISound" with these requirements...

• SetSoundVolume(id, volume) so users can quiet down their artillery
• PlayUnitNotificationSound(id, unit, volume) so we can toggle between sound at unit and sound at player
• Some sort of IVolumeCalculator or something, so you can have
  • the cameras setting different sound models: a near-2D sound system, immune to zooming out, for overhead view and an at-camera all-3D sound system for FPS-type views, see the above threads.
  • Not to mention the different functions and fudge factors for how the volumes fall off with location.
• Perhaps add a sound priority (int) to all the PlaySounds so the LLTs don't replace the Vulcans' sounds, or possibly vice versa. Currently, the OpenAL system has a ring-buffer of 16 simultaneous sounds, maybe. I haven't looked at that too closely...
• A mute(bool) method.

=== Zero Damage === (Mantis: 1, 2)

(Damage and health are floats! For the sake of players, please assume Spring will only ever show whole-number amounts... In any case, this means you only need ridiculous amounts of smallarms fire to significantly damage a tank.)

Issues (so far...):

Explosion graphics:

CStdExplosionGraphics

inverse square root, for smoke particle velocity

default damage: damages[0].

Should 0 default damage produce a Peewee-sized smokepuff, or nothing at all?

Unsupervised target choice:

CGameHelper::GenerateTargets

the damage that would be to the particular candidate unit, for ... rating targets, somehow.

Applicable damage type: damages[(*potential_target)->armorType].

The function is only called by CWeapon::SlowUpdate(), probably to look for a nearby enemy to attack. The target rating isn't used.

Knockback and deformation:

GameHelper->Explosion

impulse and crater-making

default damage: damages[0].

Currently: Default damage is used to calculate knockback, and impulsefactor is a multiplier; a weapon that does no damage can never knock things around, and can never produce craters.