Instalează Steam
conectare
|
limbă
简体中文 (chineză simplificată)
繁體中文 (chineză tradițională)
日本語 (japoneză)
한국어 (coreeană)
ไทย (thailandeză)
български (bulgară)
Čeština (cehă)
Dansk (daneză)
Deutsch (germană)
English (engleză)
Español - España (spaniolă - Spania)
Español - Latinoamérica (spaniolă - America Latină)
Ελληνικά (greacă)
Français (franceză)
Italiano (italiană)
Bahasa Indonesia (indoneziană)
Magyar (maghiară)
Nederlands (neerlandeză)
Norsk (norvegiană)
Polski (poloneză)
Português (portugheză - Portugalia)
Português - Brasil (portugheză - Brazilia)
Русский (rusă)
Suomi (finlandeză)
Svenska (suedeză)
Türkçe (turcă)
Tiếng Việt (vietnameză)
Українська (ucraineană)
Raportează o problemă de traducere
Chance of a "moon" satellite biome (celestial.config) at a "gentle" star - vanilla math
inner: 66.75%
mid: 2.725%
outer: 66.75%
gate: 27.5%
That accounts for the slots per region, body probability, weighted chance for T1 and T2 (the satellite probability for each is different), and weighted selection of satellite types. Probabilities aren't exclusive so you could end up with multiple "moon" satellites. Granted I did this math at 5AM so forgive any mistakes (beyond staying up so late).
With this mod, you "risk" no moon according to their page LOL. This mod doesn't touch celestial.config. The Outpost already sells fuel. I don't see this as being worth worrying about.
I haven't played in a while but no reason this mod should "stop" working when the game hasn't even updated. But I had to check, and it looks like FU is now doing something unnecessary to universe_server.config
They're adding in "moon" to the necessary planet types - into the array this mod removes. And I suppose that could cause an issue since I'm not controlling for load order against FU, though I could. In the event that their mod loaded after, it would error on the patch since they aren't using a test operation there to see if the path exists.
So they're creating a problem that didn't exist before (for no real good reason). Yes I can fix it :|
by controlling load order in a way that wasn't necessary before.
Also this is probably because it's now completely incompatible with FU.
I'm not sure exactly what you're looking for. The vanilla starting requirements are as follows -
"starterWorld": {"terrestrialBiome": "garden", "terrestrialSize": "small"},
"requiredSystemWorlds" : [{"terrestrialBiome": "forest"}, {"terrestrialBiome": "desert"}]
Now this mod removes "requiredSystemWorlds" so only a "garden" world that's "small" is required. If it was too large, then it could take you a long time to find the gate, etc on the starting world.
If you where not on a "garden" planet to start with, that's even worse. You couldn't get to the Outpost. If using FU as well, you can't start their stuff til you get to a garden world - which you can't fix your ship til you get to the Outpost. I could give you instant access to the Outpost, but that's beyond the scope of this mod and it does not solve the quest line issues - for example you can't fix the ship til unlocking the gate because of how the quests work (finishing one unlocks another).
This has nothing to do with Nuru.
It is vanilla behavior that she will already be there if another character completed the Floran mission. Nothing to do with any mod at all.
How has it taken me this long to find it?!
The game put me in a situation where my only option to get Tungsten was an Ocean planet, and in turn I was forced to cheat to even explore.
And now I'm currently mining on the moon for fuel without an EPP, using that fuel to power my mech (because of Mech Overhaul), then balancing between fueling my mech and my ship to jump to a star with an easier planet, just so I can get Tungsten easily.
Because of these extreme circumstances, I'd like to request a tweak to this mod that make it check for both a garden planet and EITHER a Desert or a Forest planet, just so that starting faster won't result in having very little options to progress. I understand it might take longer for the game to find a starting area for the player, but it'd be nice to have.
i remember using a friends modpack and sure enough the ship
kept flying and flying and flying and flying and flying.... :(
.
as you've explained it it makes sense.
would of been a nice change to start on a more danagerous world tbh. :)
i just wonder how the story'll go?
"By default Starbound looks for a system that has a small "garden" (aka lush) planet, a "desert" planet, and a "forest" planet. You'll of course start on the "garden" planet of course.
Here's the problem. You start using mods that add more planet types, and the mathematical chance any given planet is a "garden", "desert", or "forest" decrease. The odds that any particular system contains all 3 (and the "garden" needs to be small) decrease dramatically. Starbound keeps looking and looking for a matching system. Generating and rejecting system after system. So the more planet types you add, the time it takes to find an appropriate system goes up A LOT. People may even begin to think Starbound - or a particular mod - are broken. That isn't the case... it is just taking a really long time!"
Bug? I think you may be misinterpreting the long load time for a bug. The description for this mod explains why that can happen (with planet adding mods), and this mod should make the situation far less severe.
Are you really asking if this mod is compatible with itself?
You could easily find this by unpacking this mod same as the game assets. Or the download from the forums doesn't even need unpacked.
I'm honored to hear that from a Goa'uld
It could be done pretty easily, but I don't quite see the point in doing that.Now this is a very simple mod actually. Look at the vanilla code to see what you'd need to do -
"findStarterWorldParameters" : {
"tries" : 200,
"range" : 500,
"starterWorld" : {
"terrestrialBiome" : "garden",
"terrestrialSize" : "small"
},
"requiredSystemWorlds" : [
{ "terrestrialBiome" : "forest" },
{ "terrestrialBiome" : "desert" }
]
},
I removed "findStarterWorldParameters/requiredSystemWorlds". You could just remove "findStarterWorldParameters/starterWorld/terrestrialSize" instead.
But as I say, I don't see the point really. If you want this, it is a fine excuse to get into modding with something small. Unpack \starbound\assets\packed.pak and see how this all works. You can use this mod as a simple reference too.
Nah I don't think that'd be it. It isn't like Starbound does much multithreading (which could seriously speed that process up). Generally I'd guess either -
1. You aren't using the sort of mods which add planets. Such as the mods I list.
2. You are using those mods, but also using TrueSpace (which already has this built in).
3. Much delay can be covered up by running the starting Protectorate mission, since Starbound can search for systems in the background.
It isn't a question of mod count, but specifically mods that add additional planets. I sort of explained the mathematical issue behind it in the description.
Suppose you had only FU (just one mod but with lots of planets), you'd still see a big jump in the amount of time it takes to find a suitable starter world. Granted you might not notice if you do the starting Protectorate mission since it would be looking (in the background) while you go through that.
But suppose you have lots of those planet adding mods I list above... the math gets increasingly harsher. Thus this mod. Alternatively TrueSpace already did this and if you have that, then you won't notice any difference.