klauss wrote:TBeholder wrote:
klauss wrote: IF (and I stress the if) animatable mountpoints were to grow to the functionality level required by turrets... then maybe (maybe) turrets could be implemented as such. I'm not sure though... I thought so earlier, but after thinking it through, turrets really use all the power of subunits.
I'm purely with OOP thinking here - it follows from "modular ships" overhaul. There are clear sets of properties and methods certain objects need and others don't. Not counting special cases, there seems to be 4 main categories. A ship component: <Part> (basic physics/type&functionality/connections/graphics) + <special functionality> (like weapon info for mounts). Ship: <Part> ("summary" body and stats from all parts and recalculated only by certain events) + <Navigation> (it's present in the system space and can be detected there on its own, is orbiting or traveling, etc) + <Tactical> (it got its own allegiance, can suffer collisions, has shield and armor sectors - though this may be resolved differently - etc) + <controls> (cockpit/AI, can target on its own). Asteroid or salvage: <Part> (which may have parts or subunits attached!) + <Navigation> - no control, it's just orbiting here. A turret: <Part> + <controls> + <Tactical> - no ballistic/travel support, refer back to whatever it's attached to (no related bugs, either). So, whether we'll call them "4-1" or "1+2", it's still makes 3.
Maybe if you were designing the game from scratch. But we have an existing code base that works nothing like that.
It does. You insist on saying "4-1" and not "1+2", but it's still 3.
klauss wrote: It's not practical to think about the problem in terms that are so wildly different from the engine.
It's not very practical to think about tools before thinking about the problem to be solved with them, either. That's exactly what leads to spaghetti code, under which VS is half-buried by now. And all those horrid interfaces made by playing with "<Whatever GUI> Maker"... then again, we have it easy, spaghetti managed to kill D&D
twice by now.
klauss wrote: The engine state is that, everything is a unit, a full-fledged unit. The framework in place to distinguish among all unit types is rather limited, so you cannot think of turrets as a simplified type of unit, and it's a core engine assumption so you can't easily get rid of it.
Yup, and every accessory needs overhead of a (sub)unit, and - which is much worse - a turret moving as 1+1 DoF instead of 2 (which is
most of them) needs overhead of
two subunits instead of one. We suffer this pointless waste only because right now nothing can move that isn't an unit/subunit.
But the moment we have proper modular support, we'll have all needed framework - it only needs addition of basic joint support to allow servo-mounts remain as close to normal mounts as possible, which is to say, exactly one joint structure away - all overhead is one field. For fixed mounts we have ".joint = NULL" and everything else is behind one straightforward field check in UpdatePhysics (there's "autotracking" branch in Mount::Fire that covers it well enough, we'll only need to copy some of this stuff into Mount::UpdatePhysics). For servo-capable, but not equipped mounts, one more plain check. Not bad, IMO.
It's possible to do with mounts as is, of course, this just will have to be subsumed by part/slot system overhaul - along with vectors, meshes, mountsize tags, etc.
Deus Siddis wrote:TBeholder wrote: TurretAIOn + TurretTargetKey?
More in the discussion of that ticket.
You are assuming the status quo where main turrets never run dry the main capacitor or run out of ammunition or even miss
I assume that everything that
needs to be known in realtime is available via HUD.
Deus Siddis wrote:When that is corrected, there will be more to shooting turrets than aiming directly at the target and holding down fire until it is dead. Then, letting the AI run amok, wasting all your ammo and power as it sees fit, not anticipating dynamically moving targets, not holding fire until optimum range and relative vector (as determined subjectively per the current situation), will put you at a disadvantage. Because when firing your turrets actually costs you something, it becomes vital to apply your firepower intelligently rather than continuously.
And how exactly from this follows inherent superiority of activating/deactivating exactly the same functions by holding down and releasing one button vs. pressing on and off buttons? I see only inconvenient interface here.