Ruin Mechanics (We need you steve!)

[SpaceMarine (OP)]

In C# there have been changes to ruins that have been logged and put into the changelog but we do not have a post that fully details ruins themselves and any and all changes, such as are advanced weapons gone, how dead civilisations work, the chances for each type of a ruin to appear when a world has generated a ruin and more.

This is a great deal of confusion so I am making this post on behalf of myself and others to ask steve to write a post detailing what the mechanics for ruins are specifically so it is easier to then disperse this information to the wider populace, it would be a great help if you could do this steve thank you!

[nuclearslurpee]

It might be easier to instead compile what we know and the ask Steve to correct or clarify specific things. his way we do not distract him from releasing 1.13 soon. 

I'm afraid I don't know much besides "Use XEN to decipher the language, then use CON to excavate the loot", unfortunately. Well, that and the fact that ruins usually spawn Precursors, I know that too.

[Zap0]

In absence of other notes about changes, I guess most of the old VB6 rules are still in use? Wiki Entry

But who knows what details have changed with the new implementation or ancillary changes. A changed loot table including the altered facilities and different spawn chances in light of the planet and habitability changes come to mind.

[Droll]

From what I've seen on the DB each ruin type has a weight that determines the chance that a certain ruin is of a certain type - this is why intact cities are rarer.
Every ruin type also has a base no. of installations and a randomness factor that determines the range of amounts they appear in. The same also applies to the DST count.
Larger ruin types are also more likely to contain tech data as opposed to smaller ruins which are likely to just have installations

They also have detailed information on what amount and type of precursor presence is there
On the ground there are values that determine STO and GU count separately.
In space you have factors like defense/offense base amount, patrol amount, stationed fleet amount (these ships don't move around the system and just protect the planet unlike patrols)
There is also a value for squadrons which is some sort of fleet for precursors but don't know what special behavior they have.

Mind you this is the DB so if there are fields that aren't implemented in the code only Steve can answer

Edit: Censored the spoiler part

[brondi00]

Also, the advanced weapons are still in the database.  I don't know if you can still get them from the ruins but only the compressed fuel tanks actually function in game.

The advanced weapons, even if you got the tech, can't be used in component design.

I'm sure this will be added back at some point.

[Droll]

Also, the advanced weapons are still in the database.  I don't know if you can still get them from the ruins but only the compressed fuel tanks actually function in game.

The advanced weapons, even if you got the tech, can't be used in component design.

I'm sure this will be added back at some point.

I got them working by setting their type equal to their parent type in the DB - this works perfectly for anything that's not a railgun (adv railguns you also have to go into their component and set them to fire 5 and not 4 shots).
So you can set adv lasers to be a "laser" and their tech will appear in component design next to the standard laser options.

Of course disclaimers relating to DB editing still stands but I've been using stuff like railgun turrets, adv particle lances, adv railguns and even "heavy" railgun variants with absolutely no issues in combat.

[Namuras]

Also, the advanced weapons are still in the database.   I don't know if you can still get them from the ruins but only the compressed fuel tanks actually function in game.

The advanced weapons, even if you got the tech, can't be used in component design.

I'm sure this will be added back at some point.

I got them working by setting their type equal to their parent type in the DB - this works perfectly for anything that's not a railgun (adv railguns you also have to go into their component and set them to fire 5 and not 4 shots).

So you can set adv lasers to be a "laser" and their tech will appear in component design next to the standard laser options.

Of course disclaimers relating to DB editing still stands but I've been using stuff like railgun turrets, adv particle lances, adv railguns and even "heavy" railgun variants with absolutely no issues in combat.

I am curious how one would go about doing that. . .  b/c when i tried i could design e. g.  advanced lasers, but they would behave just like normal lasers would statwise. 

[Droll]

Also, the advanced weapons are still in the database.   I don't know if you can still get them from the ruins but only the compressed fuel tanks actually function in game.

The advanced weapons, even if you got the tech, can't be used in component design.

I'm sure this will be added back at some point.

I got them working by setting their type equal to their parent type in the DB - this works perfectly for anything that's not a railgun (adv railguns you also have to go into their component and set them to fire 5 and not 4 shots).

So you can set adv lasers to be a "laser" and their tech will appear in component design next to the standard laser options.

Of course disclaimers relating to DB editing still stands but I've been using stuff like railgun turrets, adv particle lances, adv railguns and even "heavy" railgun variants with absolutely no issues in combat.

I am curious how one would go about doing that. . .  b/c when i tried i could design e. g.  advanced lasers, but they would behave just like normal lasers would statwise.

From what I understand advanced lasers behave the same way as normal lasers but just do slightly more damage - which the game is able to handle quite well

[Namuras]

That is how i remember them. . .  but when i add them via DB editing they are a carboncopy of normal lasers in range / damage / costs. . .  vOv