Recent Posts

Pages: [1] 2 3 ... 10
1
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by Kaiser on Today at 05:37:17 AM »
Stating the obvious probably, but often even the obvious escapes me ;D

The cheapest way to extract minerals: manual mines. Then, Orbital Miners, but they are restricted to small bodies (can the body be populated? AM are fine though). And finally, the costliest option, Auto-mines.

I'm asking because I'm just starting with OM and it seems like a good middle ground. Although you need tugs to move them, and they can't be refitted unless you have a shipyard for them, which I don't.

Well, there are downsides, AM fits better for big planets with high colony costs, they can be easily moved around with civilian cargos and get repaid after a while.
OM are usually huge ships which need to be built and it takes time, you need to move them ( I prefer having them equipped with some cheap engine rather then tug them) and they are at riders risk.
2
Stating the obvious probably, but often even the obvious escapes me ;D

The cheapest way to extract minerals: manual mines. Then, Orbital Miners, but they are restricted to small bodies (can the body be populated? AM are fine though). And finally, the costliest option, Auto-mines.

I'm asking because I'm just starting with OM and it seems like a good middle ground. Although you need tugs to move them, and they can't be refitted unless you have a shipyard for them, which I don't.
3
Forum Issues / It's nice to see the forum up again!
« Last post by vorpal+5 on Today at 02:06:45 AM »
Just saying, 4 days without the forum ... Worrysome ...  :D
4
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by ISN on Yesterday at 09:36:33 PM »
How are systems generated in Known Stars games? The wiki says "The game works through all the stars in order of increasing distance. There is a 20% chance of selecting the nearest star, then if that isn't selected, 20% chance of second nearest star, etc." I think this is from the old VB version, but I haven't seen any posts about changes to this. I ran some tests in a fresh game generating systems from Sol and they seemed to confirm the 20% number. However, in my games I've also seen systems with really distant neighbors, like HIP 31293 in the screenshot. Its neighbors have distances in real space of 54.1, 63.1, and 70 light-years, and as far as I can tell there are hundreds of closer systems that haven't been picked yet. So it seems very unlikely to me that this was generated purely by iterating through the closest systems.

Sometimes you link to an existing system, but not one you know about. In that case, its a lot easier to end up with a system a long way away, because the number of systems in the sequence is much smaller. Or you are already in someone else's known system and they made the connection from their end. Or you just got the long-shot that sometimes happens.

I'm willing to bet that the code somehow negates one set of coordinates when computing distances to pick new systems, so that the formula looks like
Code: [Select]
(x2 + x1)^2 + (y2 + y1)^2 + (z2 + z1)^2rather than
Code: [Select]
(x2 - x1)^2 + (y2 - y1)^2 + (z2 - z1)^2.Either the code is missing a minus sign, or it has an extra one somewhere.

I made a new game with no NPRs (attached if you want to play around with it) and generated a bunch of systems, then plotted their positions in 3d space and jump connections. The full plot is here (https://www.desmos.com/3d/6q3qs5wogh); in the screenshot I just plotted a single chain so it's easier to see. Look at how they zigzag back and forth -- this isn't at all what you'd expect if the distances were calculated correctly, but it's what you'd see if the coordinates get reflected! This leads to a pattern I see all the time in my games, where systems are much closer to systems two jumps away than to neighboring systems. (Sol usually connects to nearby systems because it's at the origin, so reflecting everything doesn't change distances to it!)

For some reason the distance measurements everywhere else seem normal, but this seems like the best explanation for these patterns. It's not even necessarily bad, maybe you generate more interesting galaxies this way than with correct distance measurements, but it would still be good to understand how it works. And if I'm wrong and there's some other explanation for the zigzagging, let me know!
5
C# Mechanics / Re: v2.6.0 Changes Discussion Thread
« Last post by Zap0 on Yesterday at 08:26:45 PM »
The new shipping changes look good. It makes good sense to have only a certain amount of pop available for transportation.

Do the existing source, destination, stable buttons remain?

Is the emigration pressure percentage shown anywhere in the UI? I think it needs to, otherwise people will wonder why the civs don't ship anything to their new 10%+ colony.
6
How are systems generated in Known Stars games? The wiki says "The game works through all the stars in order of increasing distance. There is a 20% chance of selecting the nearest star, then if that isn't selected, 20% chance of second nearest star, etc." I think this is from the old VB version, but I haven't seen any posts about changes to this. I ran some tests in a fresh game generating systems from Sol and they seemed to confirm the 20% number. However, in my games I've also seen systems with really distant neighbors, like HIP 31293 in the screenshot. Its neighbors have distances in real space of 54.1, 63.1, and 70 light-years, and as far as I can tell there are hundreds of closer systems that haven't been picked yet. So it seems very unlikely to me that this was generated purely by iterating through the closest systems.

Sometimes you link to an existing system, but not one you know about. In that case, its a lot easier to end up with a system a long way away, because the number of systems in the sequence is much smaller. Or you are already in someone else's known system and they made the connection from their end. Or you just got the long-shot that sometimes happens.
7
C# Mechanics / Re: Potential Changes to Shipping Lines
« Last post by Steve Walmsley on Yesterday at 12:35:17 PM »
These changes are so great they broke the forums for days with their sheer awesomeness.

LoooL

Steve, I will be brutal, how about release the 2.6 so we can try the juicy shipping line thing?

It's going to be a while before any new release. We are now 10 weeks into our motorhome trip and its going really well (currently on the Isle of Skye). Instead of returning to the Isle of Man in September, we are likely heading to Spain and parking on a beach for a few months :)

I would like to be back on my PC before doing a new release, as programming on a laptop is not ideal.
8
C# Mechanics / Re: Potential Changes to Shipping Lines
« Last post by Droll on Yesterday at 11:22:06 AM »
Right now the only way I can think of a shipping line shrinking is through very old ships being retired while there are other ships idling (or getting their ships blown up). I know in the changelogs Steve sort of shoots down the idea of explicitly modelling operating costs, but maybe that would be a good way to have civilian shipping more closely model the economic activity of the empire. The admin overhead just reduces the growth rate as the shipping line gets bigger and doesn't really do the same thing.

Also I am once again asking for mineral transport contracts (esp being able to peg it to reserve levels).
9
C# Mechanics / Re: Potential Changes to Shipping Lines
« Last post by Kaiser on Yesterday at 10:15:32 AM »
These changes are so great they broke the forums for days with their sheer awesomeness.

LoooL

Steve, I will be brutal, how about release the 2.6 so we can try the juicy shipping line thing?
10
C# Mechanics / Re: Potential Changes to Shipping Lines
« Last post by nuclearslurpee on Yesterday at 10:11:58 AM »
These changes are so great they broke the forums for days with their sheer awesomeness.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk