Quote from: ISN on May 16, 2024, 06:03:36 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
(x2 + x1)^2 + (y2 + y1)^2 + (z2 + z1)^2rather than
(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!

After a boarding action I have the transport shuttles load ground units from the captured ships, I suspect any troopship could load from the stationary ship

We never stop from learning with Aurora, thank you 

I have captured an enemy ship using 3 boarding units, the ship has been repaired and sitting at my homeworld, however I cannot unload the 3 ground units, probably because the ship is a raider and it does not have any troop transport module, how Can I solve this?

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.

So, a weird behavior I'd like clarification on:

In my current campaign, I have one player race in Sol, and then I've created a habitable system in SM mode and placed a second player race in that system. The second race is therefore aliens from a human perspective with no connection to Earth.

This second race has just explored their first jump point and discovered the system of 70 Ophiuchi. By which I mean, that's the name this non-Terran race has assigned to this star system, despite being a completely alien race that has never heard of Sol as anything besides a random G2-V star that they probably have seen in their telescopes at some point in ancient history, and which has completely different constellations in any case.

So my question is: if the game is being played with Real Stars (which I prefer for system generation), do all player races use the 'real' names for the star systems even if they don't start on Earth? And if so, is there any way to force the system names to follow the naming theme? The setting in the Galactic Map window does not seem to matter here.

I see what you mean by "branch names" now - if table DIM_ComponentType doesn't work, then you could try DIM_TechType.

Done already. Doesn't work. Searched through the entire DB, renamed ALL. No effect.
Renamed all the relevant strings in the executable too. No effect.

The same with Beam Fire Control branch, wich controls kinetic weapons too. Tried to rename it into Directors to not confuse myself every second time about wich tech are for wich design philosofies, yet the branch name remains unchanged.

At this point I'm out of ideas and steam.

Quote from: vorpal+5 on May 11, 2024, 11:44:22 AM

<snip>

<snip snip!>

Darn, I thought that this rule was only for having a shipyard being able to build x different designs, with the rules you enunciate, but I was sure that you could refit anything to anything. Or perhaps, as you say, the additional requirements are only from C#.
My new tug is indeed twice the size of the old one.
Bonus question: when tractored, the ship being dragged loses a bit of fuel while traveling, which is strange? Or perhaps it is not ...

You can also rename them in the DB but you have to dig into the FCT_ShipDesignComponents table, I think. [...]

For race-designed components the procedural naming means you can't control every aspect, but I think the type names are pulled from FCT_TechSystem entries. Looks like it uses the component name if present, otherwise the primary tech name. Probably with a bit of trial and error for each component type you can figure out which entries control the relevant parts of each name.

Renamed every record in both these tables. Branch names remain the same.