|
|
| Line 1: |
Line 1: |
| == Hmm, new scripting language, eh? == | | == 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 [http://taspring.clan-sy.com/phpbb/viewtopic.php?p=65295&highlight=executes#65295 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). | | 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 [http://taspring.clan-sy.com/phpbb/viewtopic.php?p=65295 |
| | |
| 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 [http://spring.clan-sy.com/mantis 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. === ([http://taspring.clan-sy.com/mantis/view.php?id=48 Mantis])
| |
| | |
| Add a check around [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Units/CommandAI/BuilderCAI.cpp?op=blame&rev=963&sc=0 CBuilderCAI]:452.
| |
| | |
| === #00050: Ferromancer: Ground construction units attempt to repair air units while in flight === ([http://taspring.clan-sy.com/mantis/view.php?id=50 Mantis])
| |
| | |
| I ''think'' <code>CMD_PATROL</code> 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'' <tt>commandQue.push_front(co) means commandQue[0] == co</tt> ...)
| |
| <nowiki>[TODO Whoever made templated network messages can start on commands now. :P]</nowiki>
| |
| | |
| 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" === ([http://taspring.clan-sy.com/mantis/view.php?id=52 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 [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Game/GameHelper.cpp?op=file&rev=0&sc=0 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 [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Units/MoveTypes/groundmovetype.cpp?op=file&rev=0&sc=0 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 === ([http://taspring.clan-sy.com/mantis/view.php?id=66 Mantis])
| |
| | |
| It shouldn't be ''impossible'' to let s3o ''pieces'' explode without
| |
| <tt>SHATTER</tt>. 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 === ([http://taspring.clan-sy.com/mantis/view.php?id=68 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 <code>FALL</code> 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 === ([http://taspring.clan-sy.com/mantis/view.php?id=105 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 [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Weapons/Weapon.cpp?op=file&rev=0&sc=0 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 === ([http://taspring.clan-sy.com/mantis/view.php?id=116 Mantis])
| |
| | |
| Metal generation, energy use and idle regeneration are handled in [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Units/Unit.cpp?op=file&rev=0&sc=0 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. === ([http://taspring.clan-sy.com/mantis/view.php?id=118 Mantis])
| |
| | |
| ==== How they work now ====
| |
| | |
| The [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Weapons/Weapon.cpp?op=file&rev=0&sc=0 base Weapon inherit] like it's willing to
| |
| point any weapon at an incoming projectile (<code>::CheckIntercept</code>, called by
| |
| <code>CWeapon::Update</code>). 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.
| |
| | |
| [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Weapons/StarburstLauncher.cpp?op=file&rev=0&sc=0 <code>CStarburstLauncher::Fire</code>] tells [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Misc/InterceptHandler.cpp?op=file&rev=0&sc=0 CInterceptHandler] about the
| |
| new projectile, if it's <code>weaponDef->targetable</code>.
| |
| | |
| Only [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Projectiles/StarburstProjectile.cpp?op=file&rev=0&sc=0 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 ([http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Game/GameHelper.cpp?op=file&rev=0&sc=0 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 [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Projectiles/BeamLaserProjectile.cpp?op=file&rev=0&sc=0 beam laser projectile] does the drawing; you'll find the damage ("explosion"!) is done when the weapon <code>::Fire()</code>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 === ([http://taspring.clan-sy.com/mantis/view.php?id=123 Mantis])
| |
| | |
| ... and have done so since SF CVS day dot ([http://cvs.sourceforge.net/viewcvs.py/springrts/taspring/rts/BeamLaser.cpp?rev=1.1&view=markup 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.
| |
| | |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?t=1248 Sound]
| |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?p=15984#15984 Making sounds audible again]
| |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?t=2239 Soundvolume is too low when zoomed out]
| |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?t=4242&highlight=sound volume vs distance]
| |
| | |
| ([[Monthly_Topic_Rotation|MTR]]! <nowiki>*ahem*</nowiki> Maybe not.)
| |
| | |
| ''' And some random sound-related posts '''
| |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?t=2522 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.
| |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?t=2667 please make the berthasound more quiet!]. For the record, the DGun's sound has a specific volume nerf ([http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Units/UnitLoader.cpp?op=blame&rev=0&sc=0 CUnitLoader]::LoadWeapon, near the bottom). It also suggests modder-settable sound-specific volume nerfs, or something.
| |
| * [http://taspring.clan-sy.com/phpbb/viewtopic.php?t=3728 Sound effects still played if you have no LoS]
| |
| | |
| Hmm. I could almost sketch out a design for a new "[http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/System/Sound.h?op=file&rev=0&sc=0 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: [http://spring.clan-sy.com/mantis/view.php?id=140 1], [http://spring.clan-sy.com/mantis/view.php?id=147 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''':
| |
| | |
| : [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Rendering/ExplosionGraphics.cpp?op=file&rev=0&sc=0 CStdExplosionGraphics]
| |
| | |
| :inverse square root, for smoke particle velocity
| |
| | |
| :default damage: <code>damages[0]</code>.
| |
| | |
| :Should 0 ''default'' damage produce a Peewee-sized smokepuff, or nothing at all?
| |
| | |
| '''Unsupervised target choice''':
| |
| | |
| :<code>[http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Game/GameHelper.cpp?op=file&rev=0&sc=0 CGameHelper]::GenerateTargets</code>
| |
| | |
| :the damage that would be to the particular candidate unit, for ... rating targets, somehow.
| |
| | |
| :Applicable damage type: <code>damages[(*potential_target)->armorType]</code>.
| |
| | |
| :The function is only called by [http://svn.berlios.de/wsvn/taspring-linux/trunk/rts/Sim/Weapons/Weapon.cpp?op=file&rev=0&sc=0 CWeapon]::SlowUpdate(), probably to look for a nearby enemy to attack. The target rating isn't used.
| |
| | |
| '''Knockback and deformation''':
| |
| | |
| :<code>GameHelper->Explosion</code>
| |
| | |
| :impulse and crater-making
| |
| | |
| :default damage: <code>damages[0]</code>.
| |
| | |
| :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.
| |
