Author Topic: Questions Not Worth Their Own Thread: C# Edition  (Read 368164 times)

0 Members and 2 Guests are viewing this topic.

Offline Kaiser

  • Commander
  • *********
  • K
  • Posts: 329
  • Thanked: 41 times
Re: Questions Not Worth Their Own Thread: C# Edition
« Reply #4005 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.
 

Offline Steve Walmsley

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11695
  • Thanked: 20551 times
Re: Questions Not Worth Their Own Thread: C# Edition
« Reply #4006 on: Today at 06:16:33 AM »
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!

Yes, you are correct.

Here is the relevant code:
   
                // get known systems already in the game
                List<KnownSystem> CurrentSystems = SystemList.Values.Select(x => x.RealSystem).ToList();

                // order systems by distance from start system
                List<KnownSystem> PossibleSystems;

                if (StartSystem.RealSystem == null)
                    PossibleSystems = KnownSystems.Values.Except(CurrentSystems).OrderBy(x => Math.Pow(x.X, 2.0) + Math.Pow(x.Y, 2.0) + Math.Pow(x.Z, 2.0)).ToList();
                else
                    PossibleSystems = KnownSystems.Values.Except(CurrentSystems).OrderBy(x => Math.Pow(x.X - StartSystem.RealSystem.X, 2.0) + Math.Pow(x.Y - StartSystem.RealSystem.Y, 2.0) + Math.Pow(x.Z - StartSystem.RealSystem.Z, 2.0)).ToList();

                int SelectionRange = 5;
                if (GlobalValues.RandomNumber(10) == 1) SelectionRange = 20;

                // cycle through potential systems until one is selected
                foreach (KnownSystem ks in PossibleSystems)
                {
                    if (GlobalValues.RandomNumber(SelectionRange) == 1)
                        return ks;
                }

                return null;

The + should be -, as you stated above. Its been like this since C# launched and you are the first person to figure it out :)

I think correcting it is better than leaving as is, as it will be easier to understand what is happening.
« Last Edit: Today at 06:19:43 AM by Steve Walmsley »
 
The following users thanked this post: Kiero, ISN, gpt3