Main Engine as Upgrade

[TBeholder]

...multiplied by the number of ships? As if packgages weren't enough. Interesting, indeed.

I don't really understand what you're getting at?
Fuel? Number of ships? Packages? How do these things relate to the discussion or each other?

See the text. As to the number of ships, we have packgage or three for many of them, and probably will get more. Now, do we really need more special configurations for every ship, that must be fixed separately every time something big changes?

Everything's on AI. But when i re-read this, it occured to me that AI isn't necessary: once eject pod lands, players can just buy some tow and pull their ships...

Pods take forever to get anywhere that isn't already within eye-shot. If you are lightseconds from the nearest colony, you are not going to get there ever.

As i wrote, if the pod is barely usable, it's a problem of pod, not everything else. Fixable in less than a minute - once here will be an agreement on what exactly they should do.

As a "save-ass" feature? Well, maneuver thrusters are close to this. Especially if we'll not separate them for now (after all, for symmetrical and fully 6 DOF outfit it may be 6 groups of 4 thruster placements or 3 groups of 8, so let's just skip it for a time being).

Again I don't understand what you mean. I don't understand what using maneuvering thrusters have to do with making thrusters in general a separate upgrade from the ship while keeping the game functional.

They provide some little thrust. I mean, we can do the same with maneuver jets, but if we'll not dive into this pool for now, we can assume they give a base thrust equal to the ship's lateral thrust in all directions, including main axis. So Llama has forward thrust 17000 plus possible overdrive, and it has 4000 of lateral thrust. So without cruising jets it will have less than 1/4 of its normal thrust and no extra boost.
And again, i don't understand why it's so important. After all, for those who feel the challenge is too high, it would be better to have ready difficulty settings, including lessened physics/"x_damage_prob" in vegastrike.config, that's all. Ah, right, i'll write some extra groups there.

[denyasis]

Good points - I guess in retrospec, any significant change to the upgrade system would have a cascade of changes needed to rebalance it.

[Shark]

There should still be limitations as per what types of engines you can buy for your ship based on chassis class, IMO.

Mike

[pheonixstorm]

Bump for related topic by travists http://forums.vega-strike.org/viewtopic.php?f=6&t=17628

[TBeholder]

Let's look into implementation?
Right now (without engine modification), the simplest way to do this would be: packing all maneuver jets together in one 6-DOF kit. Forward and Retro may be either handled via simple multiplier on the hull (see below), or sold separately.
If you want any justification for them being different parts in the latter case, they may be made for different work cycles: mains are supposed to work long at a variable strength, "brakes" are supposed to work mostly in short full-power bursts, but be more compact.
So, how to do it:

1. In units.csv, take the lateral thrust (currently it's the same for up/down and left/right). That's maneuvering thrusters' force. Substract this value from fore/aft thrust. Because if maneuver jets are 6-DOF they can add equal thrust in all directions.
2. Create add_maneuver_<Top_Accel value>__upgrade with Forward_Accel = Retro_Accel = Maneuver_Yaw = Maneuver_Pitch = Maneuver_Roll = Left_Accel = Right_Accel = Top_Accel = Bottom_Accel = <ship>.Top_Accel
3. Create mult_properties_<ship>__upgrades with Maneuver_Pitch| = <ship>.Maneuver_Pitch/ <ship>.Top_Accel and same for _Yaw and _Roll, this set arms of turning forces.
4. See the number of thrusters visible on this model and the number of "lights" in units.csv (but these may be bad - e.g. Determinant needs reqork) to see how many main thruster nodes are here. Divide the "pure" main thrust by this number if they are of equal size, or wait until the next stage if not.
5. See common denominators for maneuver jets, set the required number in Prohibited_Upgrades (6000, 4000 and 3000 can be reduced to the same upgrade of 1000, added 6x ... 3x times).
6. See common denominators in Forward_Accel, calculate variation from overdrives line, rounding together close values.
7. See common denominators in Retro_Accel if it's separate. If not, set in "mult_..." Retro_Accel = (Retro_Accel-Top_Accel) / (Forward_Accel/Top_Accel) of the original ship.
8. Create thruster upgrades as per common denominators and set the required combination in Prohibited_Upgrades for the ship.
9. Add the proper number of these upgrades to their ships.

As to common denominators -

Llama has 3x main thrusters for [...] 13 k over maneuver thrust; Lancelot has 2x big + 8x small for 27 k / 22 k

So if we assume big ones are the same, it can be something like (3x 4.4k = 13.2k) and 2x 4.4 + 8x 1.65 k = 22k respectively. However, it may be a better idea to group and compare ships by their building factions, perhaps starting with Andolians first and ending with Shapers.

About adding a lot of upgrades: note that "mult_..." one is constant for the hull, so there will be only one for all variants, and it still can hold other mult-type properties. There's no need in too many thrusters, since the number of different upgrades is reduced to common denominators and maybe further by asumption some ships are equipped with stronger/weaker engines by default. Also, afterburner acceleration can be included into thruster stats, so the choice of thrusters can replace the existing "mult_overdrive" line (then thrust component from maneuver jets isn't multiplied by afterburner).

[Hicks]

i know how to edit the units.csv sheet, and have worked out a few ways to get engines working. But i have looked at the ship_upgrades.py and i have no idea whats happening in there. Anyone know how to add new set of upgrades in it?

[pheonixstorm]

Not really.. Have you tried looking in the wiki for an answer? The wiki will sometimes be of help Even if its outdated help.

[Hicks]

ok, for some reason i can't get a catergory for engines, but if i add the stats to the passenger compartments and install those it works fine.

[Hicks]

ignore my previous posts, got an engine working. At the moment it is just an upgrade, so you can only have 1 installed at a time. It adds thrust so the same upgrade will provide slower acceleration for a larger ship. Got to work out how to let you install multiple engines up to a certain number, eg 2 or 3 depending on the ship. Do we want to set the acceleration for ships to 0 intially so you have to buys engines with a ship (or have them come installed) so a ship without engines won't move?

[Hicks]

next question, how do you add a new mountsize? going to define the engines as weapons in the weapon-list.xml, that just add thrust, and that way i can set a number of engine mounts on ships and install engines on them.

[TBeholder]

Got to work out how to let you install multiple engines up to a certain number, eg 2 or 3 depending on the ship.

Set the number for a category in Prohibited Upgrades.

Do we want to set the acceleration for ships to 0 intially so you have to buys engines with a ship (or have them come installed) so a ship without engines won't move?

Was discussed, my answer is "no need to complicate things, especially if maneuver jets do thrust too and are multi-node". Don't leave thrust on hull. Purchaseable variants should be equipped (they even have a reactor, remember?) with thrusters providing much the same performance as ships have now, though.
Now that dockOnLoad feature seems to work reliably, this needs only a simple validator on "launch" button of base interface.

Additional note: thrusters have non-extensive parameter: afterburner type. The only way to handle it is to set one and the same in the whole category. Justification: thrusters are plugged into great big assembly providing coolant, propellant, power, backstop... it's actually more reasonable to expect from "more energy", "more propellant" and "warp energy" solutions to be optimized for different purposes, run on different principles, have different form factors and thus not be comptible.

next question, how do you add a new mountsize?

Hardcoded.

going to define the engines as weapons in the weapon-list.xml, that just add thrust, and that way i can set a number of engine mounts on ships and install engines on them.

Not going to work. No controls and they don't even have recoil right now. Terribly constrained.
A similar idea was discussed by myself and devs, though. Here there be (planned to be) "effectors" for more generic handling of such things - a clean universal way to handle visual/physical effects created by events (e.g. to make antimatter shells explode without making an unit for each) and controls (weapons, jets etc).

[travists]

Boy, the upgrade base ship systems is all over the place, huh? Generally I think a "mount size" for engines is unnecessary. The thrust generating unit has a size and the ship has a max upgrade volume. You can go "formula one race car" and have all of your upgrade space devoted to an over sized engine, or decide that protection is more important than speed and use an undersized one. A thruster package of an Ox is larger than a Llama so there is no way to mount it.


Weapons don't have recoil? Awwwwww It would be kinda fun if your engine dies to move about backwards by firing your guns.

Almost forgot, TBeholder's procedure seems to work well to my mind.

[klauss]

Mount size is not for the physical size of the gun, but the connectors required to mount the gun in place.
I think.

It's a kind of compatibility issue.

[travists]

I kind of thought of it as mount hardware and reinforcement too. Like trying to mount a howitzer on a small drone. might have the hookups, but one shot and you tear yourself apart!

[Hicks]

Got to work out how to let you install multiple engines up to a certain number, eg 2 or 3 depending on the ship.

Set the number for a category in Prohibited Upgrades.

I though this sets the limit for the level of the upgrade, not the number of them you could have installed?

next question, how do you add a new mountsize?

Hardcoded.

going to define the engines as weapons in the weapon-list.xml, that just add thrust, and that way i can set a number of engine mounts on ships and install engines on them.

Not going to work. No controls and they don't even have recoil right now. Terribly constrained.
A similar idea was discussed by myself and devs, though. Here there be (planned to be) "effectors" for more generic handling of such things - a clean universal way to handle visual/physical effects created by events (e.g. to make antimatter shells explode without making an unit for each) and controls (weapons, jets etc).

Was going to try and use hardpoints so you could install say 3 engines on the Llama. Was trying to add a new mount type so that you could only install engines on them. Wasn't trying the weapons harpoints for the mechanics on how they work.

[TBeholder]

Boy, the upgrade base ship systems is all over the place, huh? Generally I think a "mount size" for engines is unnecessary.

Currently, categories can handle it. Engine/Highborn_Heavy, Engine/Andolian_Capship_Medium, Engine/LTC_Standard, and so on.
Looking at the setting, Andolian and Unadorned probably would obey strict standards. Shapers can go wild, but perhaps eventually become popular. Merchants probably would keep an eye on the existing steady supply and be unwilling to jump out of the line and pay for R&D without a compelling reason, while Forsaken and Pirates unable to (beggars can't be choosers). LIHW somewhere in the middle. IMHO for human (with satellite groups like Klkk) ships grand total can't be more than a dozen or less than half a dozen categories. If needed, tradeable categories can be stuffed inside them (Engine/LTC_Standard/Courier, Engine/Andolian_Capship_Medium/Economical, Engine/Andolian_Capship_Medium/Military).

Another thought - because the same big assembly rigging matters, hulls can slightly adjust the propulsion performance, in that a thruster can be allowed to work harder within the robust system that takes extra care to deal with heat, vibration etc, than in a box barely fitting standards and treatening to melt down if the torch spreads a little too wide.

I though this sets the limit for the level of the upgrade, not the number of them you could have installed?

No, it's quantity - UpgradeAllowed function (vegastrike/src/cmd/basecomputer.cpp) colors parts as prohibited and returns false "if (numUpgrades->quantity >= quantity)".

Was going to try and use hardpoints so you could install say 3 engines on the Llama. Was trying to add a new mount type so that you could only install engines on them. Wasn't trying the weapons harpoints for the mechanics on how they work.

Probably, the best unified solution would be handling ship parts as a separate type - with its appearance mesh, collision mesh (even internal ones, for critical hits and damage indication - see WC for a good example) and slot strings working much like in subunits, but without AI and other resource eaters. Conversely, if units and subunits were cleaned up - i.e. without AIs or cockpits plugged in acted more like stones (not eating more resources than is necessary) and were better integrated with the parent than they are now, every upgrade could be a subunit just as well.
Attach effectors, resource handling (needs power/fuel/cooling, has priority) and Python procedures instead of AI (e.g. for VS/WC/B5/Elite jumpdrive variations) and the only thing left is to specify into which control system they are hooked - then again, Mount/Dock/Light/Upgrades would do just fine.

[klauss]

Probably, the best unified solution would be handling ship parts as a separate type - with its appearance mesh, collision mesh (even internal ones, for critical hits and damage indication - see WC for a good example) and slot strings working much like in subunits, but without AI and other resource eaters.

I agree, though I would use a simple approach, perhaps no appearance mesh except for externals (and maybe not even, not easy making a mesh blend with all unit types), and instead of collision mesh, maybe just location and dimensions (perhaps as a bounding box or sphere).

[travists]

I third the motion. In reality I find it far more likely to knock out a critical system than blowing the reactor. It also makes the repair droid eminently useful.

[klauss]

I third the motion. In reality I find it far more likely to knock out a critical system than blowing the reactor. It also makes the repair droid eminently useful.

Feature request?

[travists]

please

[klauss]

please

I meant "create the issue in the feature request tracker"

[travists]

ah! Well even though it's a day off I still have stuf I should get on. I'll do so unless someone beats me to it.

[TBeholder]

I agree, though I would use a simple approach, perhaps no appearance mesh except for externals (and maybe not even, not easy making a mesh blend with all unit types),

If it's about things like tiny little radar antenna vs. great big radar antenna, they should perform differently, setting up which would be easier than with propulsion (except other special cases like armor). For clearly incompatible cases, different categories and all that.
Otherwise, why not, if they are pluggable anyway. Right now mounts have models, working but not used in default config mostly due to being broken (wrong size/orientation). Maybe, models for internals somehow tagged (material? negative size multiplier?) as "invisible", to be used in schemes but not rendered in normal views?

and instead of collision mesh, maybe just location and dimensions (perhaps as a bounding box or sphere).

That's what i assume as a reason for a separate mesh - it's unlikely to be more than 12 tri (box) or so. Of course, if there's a box check CPU-cheaper than a proper check for lesser meshes like a tetrahedron or octahedron, it's something to consider. Or if there's an easy sphere check (saw something like this in code but can't remember details) maybe just set it as fallback when the collision mesh is absent.

I'd swear we had a thread for this somewhere, though.

[travists]

Feature Request Added.

[klauss]

Feature Request Added.

bd