Why can't I add shields to my Cobra? It tells me it's too heavy?

Status
Thread Closed: Not open for further replies.
Ship.Type.Name + ' ' + ShieldGenerator.Class + ' ' + ShieldGenerator.Rating

Hows that for simplicity?
Naming was hardly the complex part. ;)

The complexity is in going from 40 modules to 450.

We already have an order of order of magnitude increase that player and devs have to deal with. Every ship in the game currently has bespoke shield generators, they just happen to be named the same and cost the same and consume the same power, in their actual function they are unique, might as well imagine the outfitting screen is filtering them down to your ships shield generator except for the fact you can sell it from one ship and buyback on the other.

Generators are ship specific! They can't be reasoned about generically! How confusing is it that the shield generators all look the same but have wildly different and inconsistent performance on each individual ship?
No, every ship in the game uses the same shield generators, but due to the formula used to calculate shield strength based on the stats of the ship and the generator, you end up with 'bespoke' shield values.

Imagine you are a game designer. You can design the system so you have 40 modules in a spreadsheet and the game database, then use a formula to calculate the shield values. Or you can design the system so you have 450 modules in a spreadsheet and the game database, with no formula.

Which seems like it'll be more complex to manage, maintain and keep track of? Especially when during development you'll probably need to revise the stats of all the modules several times? Both give the same end results, but one only means dealing with 40 module entries, the other means dealing with 450... And the one that only means dealing with 40 also allows you to make across the board changes simply my modifying a single formula, while the one with with 450 would mean changing every single one individually...

- - - - - Additional Content Posted / Auto Merge - - - - -

I can't get this to line up with my measrements. I've plotted them here (red points is theory, blue points are measurements). These points were obtained through power required to recharge shield.
Sorry, I'm not sure I understand what the graph is showing? (Forgive me if I'm being dumb, it's been a long day.)
 
Last edited:
Sidewinders firing pulse lasers at an Anaconda for example get their damaged cut to 1/3 their normal damage potential.
...if you want to ensure you're doing the max damage the weapon is capable of you need to use a huge weapon as that will always do it's best against any ship in the game.
...it's always better to fit the largest weapons you can if you want to fight equal or larger ships effectively rather than just loading up on as many small and cheap weapons as you possibly could


I'm confused, does this mean all class 1 weapons do reduced damage against larger ships? Could you explain the formula? I made the assumption that class 1 weapons like railguns, missiles and torpedoes were there to give small/medium ships a fighting chance against big threats. Based on this thread, and my failed attempts at Anaconda hunting, I'm now assuming I've been wasting credits on ammo (not to mention repairs) in what amounts to firing a slingshot at an elephant.
 

Mike Evans

Designer- Elite: Dangerous
Frontier
[/COLOR]
I'm confused, does this mean all class 1 weapons do reduced damage against larger ships? Could you explain the formula? I made the assumption that class 1 weapons like railguns, missiles and torpedoes were there to give small/medium ships a fighting chance against big threats. Based on this thread, and my failed attempts at Anaconda hunting, I'm now assuming I've been wasting credits on ammo (not to mention repairs) in what amounts to firing a slingshot at an elephant.

Railguns, missiles, cannons and torpedoes punch above their weight in terms of their effectiveness against larger ships. There is a stat missing from outfitting that is supposed to indicate roughly speaking what the weapons is good at shooting at in terms of rough ship size (small to huge). Under the hood is slightly more complicated but effectively every weapon has a number that is compared against another number on the target ship that if lower will result in lower damage than normal. If higher then it doesn't change. The largest hard point size on the ship is a good indicator to show what kind of weapons you need to be effective against it. So a cobra is best dealt with size 2/medium weapons.
 
Naming was hardly the complex part. ;)

The complexity is in going from 40 modules to 450.


No, every ship in the game uses the same shield generators, but due to the formula used to calculate shield strength based on the stats of the ship and the generator, you end up with 'bespoke' shield values.

Imagine you are a game designer. You can design the system so you have 40 modules in a spreadsheet and the game database, then use a formula to calculate the shield values. Or you can design the system so you have 450 modules in a spreadsheet and the game database, with no formula.

Which seems like it'll be more complex to manage, maintain and keep track of? Especially when during development you'll probably need to revise the stats of all the modules several times? Both give the same end results, but one only means dealing with 40 module entries, the other means dealing with 450... And the one that only means dealing with 40 also allows you to make across the board changes simply my modifying a single formula, while the one with with 450 would mean changing every single one individually...

I am a developer, they have the same complexity. In one instance you run the calculation at build time, the other at runtime the end result and complexity is the same you still have 450 unique generators at what point it is calculated is a minor thing, the end result is the same. You seem to be thinking someone would have to go by hand and make 450 generators in a spreadsheet. No there is a formula procedurally generating 450 unique generators that have only 40 unique names, it is confusing to the us the players because an A6 generator means something completely different on a Python vs Asp vs a Clipper, it might as well be called a Python A6, Asp A6, and Clipper A6. They don't want bespoke generators, yet they are procedurally generating bespoke ones anyway, to the players there is no difference other than the confusing naming, which could be fixed by changing the generation procedure.

I would prefer they go with a simpler model of generator and mass determines output, but if they're not then don't try and tell me the generators are not ship specific, they are.
 
[/COLOR]
I'm confused, does this mean all class 1 weapons do reduced damage against larger ships? Could you explain the formula? I made the assumption that class 1 weapons like railguns, missiles and torpedoes were there to give small/medium ships a fighting chance against big threats. Based on this thread, and my failed attempts at Anaconda hunting, I'm now assuming I've been wasting credits on ammo (not to mention repairs) in what amounts to firing a slingshot at an elephant.

We have 3 classes of landing pads that roughly equate to 3 ship sizes, 4 classes of weapons, and the knowledge that a small ship with small weapons shooting a large ship (Anaconda) leads to 1/3 damage.

I guess it probably works something like this:

S weapon + S target = 100% DPS potential.
S weapon + M target = 67% DPS potential.
S weapon + L target = 33% DPS potential.

M weapon + S target = 100% DPS potential.
M weapon + M target = 100% DPS potential.
M weapon + L target = 67% DPS potential.

L weapon = 100% DPS potential all against S-L ships.

Huge weapons maybe geared towards potentially larger targets like faction capitals.


Edit: Mike replied while I was typing.
 
Last edited:

Mike Evans

Designer- Elite: Dangerous
Frontier
We have 3 classes of landing pads that roughly equate to 3 ship sizes, 4 classes of weapons, and the knowledge that a small ship with small weapons shooting a large ship (Anaconda) leads to 1/3 damage.

I guess it probably works something like this:

S weapon + S target = 100% DPS potential.
S weapon + M target = 67% DPS potential.
S weapon + L target = 33% DPS potential.

M weapon + S target = 100% DPS potential.
M weapon + M target = 100% DPS potential.
M weapon + L target = 67% DPS potential.

L weapon = 100% DPS potential all against S-L ships.

Huge weapons maybe geared towards potentially larger targets like faction capitals.


Edit: Mike replied while I was typing.

Pretty much this.
 
I am a developer, they have the same complexity. In one instance you run the calculation at build time, the other at runtime the end result and complexity is the same you still have 450 unique generators at what point it is calculated is a minor thing, the end result is the same. You seem to be thinking someone would have to go by hand and make 450 generators in a spreadsheet.
It depends how the designer approaches it, I guess, and the way their development environment is set up.

A couple of comments from devs have strongly suggested that they are manually copying and pasting numbers from their own spreadsheets into the game DB to update the game. In my experience this is very common in game development, unless the team has worked together on a similar project before and had time to develop some automated tools.

I completely understand that the complexity is the same from a code point of view - as you say, you end up with 450 shield values either way - but for the game designers whether you calculate at build time or run time can make an enormous difference to the workload and complexity.

Of course, our experiences may be very different. :)

I would prefer they go with a simpler model of generator and mass determines output, but if they're not then don't try and tell me the generators are not ship specific, they are.
I guess it depends how the DB is set up.

My assumption (and I could well be wrong) is that each generator has its own entry in the DB. That means there are 40 DB entries that the designers have to worry about for shield generators. So the generators themselves are no more ship-specific than any other module. The effect they have on a ship's shields is specific to that ship, as it's calculated from a combination of the stats of the ship and the generator, but the designers only have 40 DB entries to worry about, not 450.

Again, I could well be wrong.
 
I am a developer, they have the same complexity. In one instance you run the calculation at build time, the other at runtime the end result and complexity is the same you still have 450 unique generators at what point it is calculated is a minor thing, the end result is the same. You seem to be thinking someone would have to go by hand and make 450 generators in a spreadsheet. No there is a formula procedurally generating 450 unique generators that have only 40 unique names, it is confusing to the us the players because an A6 generator means something completely different on a Python vs Asp vs a Clipper, it might as well be called a Python A6, Asp A6, and Clipper A6. They don't want bespoke generators, yet they are procedurally generating bespoke ones anyway, to the players there is no difference other than the confusing naming, which could be fixed by changing the generation procedure.


I would prefer they go with a simpler model of generator and mass determines output, but if they're not then don't try and tell me the generators are not ship specific, they are.


They are not 'procedurally generated' they are a database item that has base values assigned (actually its a smart easy to change and tweak design IMHO), they have the ships in a database and they have base values assigned (ship mass, hull strength, shield strength, etc) and the program uses a formula incorporating the ship mass and the base shield strength with the installed shield generators base values to calculate total shield strength of the ship. This (to my way if thinking) is about the simplest way to have the shield generator and ship stats handled, makes individual ship tweaking easier and allows for overall shield generator tweaks to be quickly implemented. The ships are SPECIFIC, the ships have specific individual values for their various base data as determined by their overall role in the game... which is how it should be... The generators sit on top of that data and are 'modified' by the base data of the ship...

That is simple, elegant and easily manageable, each asset is actually hand made initially so this makes for a total of 40 shield generator assets, and only needing to create X number of ship assets...

Deciding to change it to ~450 shield generators would add significant problems for asset creation and asset modification... then to top it off you would need to list the assets in the games outfitting screen adding to what is already long queues in that screen when changing internal (non dedicated) components.

The current system is about as simple and easy to maintain / modify as you can get IMHO
 
Last edited:
Anyway, I was bored so I worked out shield values based on the info in this thread and the Wiki. Here's the result:

View attachment 9863


Some caveats:

* These have been worked out by me in a largely manual fashion (Major Lag will be very disappointed in me ;))
* The numbers are based on my understanding of the mechanics as explained by Mike in this thread, and it's entirely possible I have misunderstood them or made a mistake in the maths
* The source data is from the wiki, not the game, so if there are any mistakes in the Hull Mass, Base Shield values or what class generators a ship can fit on the wiki, they will be repeated here
* I may have made mistakes

If anyone wants the data in a more useful format, I can put it into a Google sheet, text file or CSV.
 
They are not 'procedurally generated' they are a database item that has base values assigned (actually its a smart easy to change and tweak design IMHO), they have the ships in a database and they have base values assigned (ship mass, hull strength, shield strength, etc) and the program uses a formula incorporating the ship mass and the base shield strength with the installed shield generators base values to calculate total shield strength of the ship. This (to my way if thinking) is about the simplest way to have the shield generator and ship stats handled, makes individual ship tweaking easier and allows for overall shield generator tweaks to be quickly implemented. The ships are SPECIFIC, the ships have specific individual values for their various base data as determined by their overall role in the game... which is how it should be... The generators sit on top of that data and are 'modified' by the base data of the ship...

Each shield generator produces a unique shield envelope based on the ship it's on by running through a formula based primarily on a number SPECIFIC to each ship, not the generator. The end result is 450 UNIQUE and widely different shield generations, this is the definition of procedural. You can calculate this dynamically, or run it ahead of time and write to a config file, doesn't matter your trading CPU for disk space/memory, the end result is the same, 450 unique shields based on executing a procedure.

That is simple, elegant and easily manageable, each asset is actually hand made initially so this makes for a total of 40 shield generator assets, and only needing to create X number of ship assets...

Deciding to change it to ~450 shield generators would add significant problems for asset creation and asset modification... then to top it off you would need to list the assets in the games outfitting screen adding to what is already long queues in that screen when changing internal (non dedicated) components.

There are 450 generators already, whether they are in a static file or calculated in ram is an implementation detail, what we see in game is 450 different shield generators, this is shown by the large matrix needed to represent them having a cell for each ship and each generator name, where the cell shows you the actual generator stats. If generating them statically is a problem for their asset pipeline, then we are in real trouble, either way it matters not, we have 450 generators to reason about, and that number will go up 40x for every ship added to the game.
 
Mike Evans, thanks for answering a lot of these questions. Unfortunately, I have one (kinda big one) as well.

When you say shield energy is compared to the ship's hull mass - is that also true for thrusters, or do setup matter for those?
 
Each shield generator produces a unique shield envelope based on the ship it's on by running through a formula based primarily on a number SPECIFIC to each ship, not the generator. The end result is 450 UNIQUE and widely different shield generations, this is the definition of procedural. You can calculate this dynamically, or run it ahead of time and write to a config file, doesn't matter your trading CPU for disk space/memory, the end result is the same, 450 unique shields based on executing a procedure.



There are 450 generators already, whether they are in a static file or calculated in ram is an implementation detail, what we see in game is 450 different shield generators, this is shown by the large matrix needed to represent them having a cell for each ship and each generator name, where the cell shows you the actual generator stats. If generating them statically is a problem for their asset pipeline, then we are in real trouble, either way it matters not, we have 450 generators to reason about, and that number will go up 40x for every ship added to the game.

If thats the definitiong you wish to use for procedural generation then fine... I was thinking you were meaning procedural generation as in (PRNG assinging of the values)

I realise that the 'calculated out' variants of the shields becomes 450... but as for the static assets, 40 in total is a lot less than 450 when it comes to manipulating, sure they can do the updating from those base 40 to the necesary calculated variants with a script, I was not arguing that point...

Also under your 'idea' for each new ship they would only need to add realistically between 5 and 20 shield variants not 40... this is allowing for up to 3 lower than max fitting size classes E to A such as my asp I can fit size 5 or is it 6 ?? I am not in the game right now, down to size 3 shields...

I would assume because of hull mass that this would be pretty close to the max ranges in the bigger ships as well but will stand corrected if that is not the case...


I think by creating dynamically you essentially have less load on the client... it only needs to produce shield results for each ship in the instance not all permutations...
Fixed coded (even if its precalculated in a config file or whatnot) just adds to code bloat IMO... internally from a software pov, it only has to hold 40 + number of ships records in memory and just create the permutations on the fly... when you start to consider all the other modules ships have etc, from a programming standpoint isn't it easier to design and code this versus precalculated permutations?
 
Mike Evans, thanks for answering a lot of these questions. Unfortunately, I have one (kinda big one) as well.

When you say shield energy is compared to the ship's hull mass - is that also true for thrusters, or do setup matter for those?
Pretty sure that equipment, cargo and fuel mass do matter for thrusters, because if your ship can just barely fit a given thruster and then you add heavier components or cargo racks with higher capacity, suddenly that same thruster cannot be purchased any more. Not sure what happens if you have it fitted already and then increase your mass above its limit. Maybe you can't launch? Or can't move?
 
Pretty much this.
Three questions:
1) Which ships are "small, medium, and large"? Is it by what size docking port they use (Python would be medium) or mass (Python would be large) or by some other metric?

2) Which weapons are "small, medium and large"? E/F weapons are "Small", C/D weapons are "Medium", and A/B weapons are "Small"?

3) When will the Outfitting screen be updated to show the DPS of weapons against the different "classes" of targets accurately, and to provide lists of what ships are what class of target???

Right now Outfitting shows a single DPS value which is extremely confusing. I've sat and looked at the Outfitting screen and wondered why a railgun with 4 DPS cost so much more than a multicannon with 4 DPS and assumed it was some tradeoff between rate of fire, heat, and mass, but I honestly figured that because the DPS values were so similar - multicannons and pulse lasers would work just as well as rail guns and particle accelerators. This game is in a constant state of flux - so I tend to only trust the in-game UI for data on what is going on, things I try myself, or developer data - so this is a major revelation.

I honestly don't understand why FD was unable to balance weapon damage over simpler a set of linear numbers which lots of space combat games have done since about...1990. Wing Commander, X-Wing, Freespace - thousands of hours of my time playing those before MMOs were even a thing... Maybe it has to do with the way the equations for the shield relate to the actual volume of the art assets. Okay, peace on that topic - I could get past this IF it was communicated in the game to the player, but right now it is not, and it's kind of a critical gameplay mechanic.

Pretty much all of the critical gameplay mechanics in this game are hidden, obtuse, or just plain frustrating. I am really tired of having to come to these threads and sort through pages of developer comments to figure out how things work - AFTER I spent a good deal of time going through the giant PDF manual, the tutorial YouTube videos, and the training missions.

Mike - I would much rather have the current gameplay mechanics, shields, armor, weapons DPS vs classes, etc. properly indicated to players in the UI BEFORE we start getting NEW features like Wings which I am sure also requires a bunch of UI work so it would be some of the same people doing the work. If you could convey that feedback back up the chain of command it would be much appreciated.
 
Anyway, I was bored so I worked out shield values based on the info in this thread and the Wiki. Here's the result:


Some caveats:

* These have been worked out by me in a largely manual fashion (Major Lag will be very disappointed in me ;))
* The numbers are based on my understanding of the mechanics as explained by Mike in this thread, and it's entirely possible I have misunderstood them or made a mistake in the maths
* The source data is from the wiki, not the game, so if there are any mistakes in the Hull Mass, Base Shield values or what class generators a ship can fit on the wiki, they will be repeated here
* I may have made mistakes

If anyone wants the data in a more useful format, I can put it into a Google sheet, text file or CSV.

Could you tell me exactly what formula you used? I tried implementing it and get different results. Also, I've just found the shield % memory location and done some testing with my asp. For classes 4-6 I get results within 1% of what you predict, but for class 3 I get very different results (EDIT: your prediction is up to 40% higher), are you sure you got the below optimal mass portion right?
 
Last edited:
If thats the definitiong you wish to use for procedural generation then fine... I was thinking you were meaning procedural generation as in (PRNG assinging of the values)

This is the definition of procedural, I didn't make it up, procedural need not be based on PRNG, in fact it usually isn't, I even think there is a video where DB says procedural is not equal to random. If it were the stars would shift around in the galaxy every time you load the game.

You're the one tacking PRNG on to procedural not me, generating content through algorithms (procedures) is the definition of procedural generation.

I think by creating dynamically you essentially have less load on the client... it only needs to produce shield results for each ship in the instance not all permutations...
Fixed coded (even if its precalculated in a config file or whatnot) just adds to code bloat IMO... internally from a software pov, it only has to hold 40 + number of ships records in memory and just create the permutations on the fly... when you start to consider all the other modules ships have etc, from a programming standpoint isn't it easier to design and code this versus precalculated permutations?

CPU vs Memory is a trade off made in every program in existence, depending on the situation one can be better than the other, in the end the effect is same and has no bearing on a discussion like this. So long as the game runs at a good frame rate with acceptable memory usage, it doesn't matter. Typically for this kind of thing static asset generation is better, the amount of memory to store 450 shield generators might be a few kilobytes, rather than recalculating in the cpu over and over when the values don't change between builds of the game. Again the implementation is unimportant so long as the game runs ok.

The point remains we have 450 bespoke shield generators in the game. The shield generators follow no logical consistency since they are primarily based on a magic number on the ships hull that has no relation to hull mass or size. Some larger ships have stronger shields with the same generator as a smaller ship, sometimes it the other way around, it follows no pattern, it has no internal consistency.
 
Three questions:
1) Which ships are "small, medium, and large"? Is it by what size docking port they use (Python would be medium) or mass (Python would be large) or by some other metric?
I think it's based on the pad size, with the exception being the Python (counted as large but can fit on medium pad).

2) Which weapons are "small, medium and large"? E/F weapons are "Small", C/D weapons are "Medium", and A/B weapons are "Small"?
Class 1 weapons are small, Class 2 are medium, Class 3 are large and Class 4 are huge.

Note that Mike mentioned that Rails, Missiles, Cannons and Torps 'punch above their weight' - not sure if these means they are immune to the weapon size vs ship size modifiers, or just have different ones.
 
The point remains we have 450 bespoke shield generators in the game.
No, we have 40 shield generators that will (once all 30 playable ships are in) result in around 450 possible shield ratings.

There are not 450 'credit cost' values for shield generators, there are 40. There are not 450 mass values for shield generators, there are 40. There are not 450 names for shield generators, there are 40.

I am aware that from your point of view it amounts to the same thing, but it really doesn't from the point of view of the person who has to create, balance and maintain the DB entries for the shield generators, at least in my experience.

But I think we're just going to have to agree to disagree here, as we've circled around this point more than once now. ;)
 
No, we have 40 shield generators that will (once all 30 playable ships are in) result in around 450 possible shield ratings.

There are not 450 'credit cost' values for shield generators, there are 40. There are not 450 mass values for shield generators, there are 40. There are not 450 names for shield generators, there are 40.

I am aware that from your point of view it amounts to the same thing, but it really doesn't from the point of view of the person who has to create, balance and maintain the DB entries for the shield generators, at least in my experience.

But I think we're just going to have to agree to disagree here, as we've circled around this point more than once now. ;)

450 unique names, costs and mass could be easily generated with the stat that actually matters the most which is HOW MUCH SHIELD IT GENERATES.

I have been arguing all along this is harder to balance, just look at the Python nerf incoming, -33% to shields, all because someone hand coded a giant value in the Pythons magic shield number. If it were purely based on mass and generator it would be much harder to get wrong, you would have to get hull mass completely wrong which would affect all system and be very noticeable, it would have an internal consistency, it would make sense.
 
Last edited:
Could you tell me exactly what formula you used? I tried implementing it and get different results. Also, I've just found the shield % memory location and done some testing with my asp. For classes 4-6 I get results within 1% of what you predict, but for class 3 I get very different results (EDIT: your prediction is up to 40% higher), are you sure you got the below optimal mass portion right?
I'm not sure at all. :)

I'll give you an example of how I worked it out, with a Class 3 generator on the Asp (if I screwed up, maybe you, I or someone else will notice how).


So, a 3A generator on an Asp:

The Asp has a Hull Mass of 280 and a Base Shield of 140 (according to the wiki)

Class 3 Generators have mass values as follows (from Mike's earlier post):

Min Mass 83
Optimal Mass 165
Max Mass 413

'A' Rating generators have the following modifier range (from Mike's earlier post confirming my guess):

Min Mass 1.7
Optimal Mass 1.2
Max Mass 0.7

The Asp's Hull Mass of 280t is 115t higher than the Optimal Mass of the generator, so the modifier is going to be in the range between 1.2 and 0.7.

413 - 165 = 248, so there are 248t difference between the Optimal Mass and the Max Mass. The modifier value falls from 1.2 to 0.7 over that range, meaning a maximum difference of 0.5

So the modifier will be 1.2 - ((115/248)*0.5) = 0.9681 (and some change - I'll stick to 4 decimal places for this example, but I used a spreadsheet and then rounded the final result to 1 decimal)

0.9681 * 140 (the base shield of the Asp) = 135.5 Shield


A 3D generator on an Asp:

Most of the numbers are the same. The difference is in the modifiers, which for 'D' Rating generators are:

Min Mass 1.4
Optimal Mass 0.9
Max Mass 0.4

So the modifier will be 0.9 - ((115/248)*0.5) = 0.6681 (also with some change)

0.6681 * 140 = 93.5 Shield


Let me know if I've made a horrible mistake somewhere. :)
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom