Suggestions Thread for v2.4.0

[kilo]

Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large

Happy to implement if you can supply the logic

Maybe it can be done semi-automated. I was thinking of the TikZ module in LaTeX to create mind maps. Start with a starting system like Sol in the center and create each system around it with the first directly north and every following one 360/x degrees further clockwise with x being the number of explored JPs. You do the same for the next set of JPs that originate from the daughter systems with the single difference that the parent system is the new starting point from which systems get placed.
The connections between later generations of stars have to be significantly shorter than those for earlier generations, but they have to be long compared to the star system symbols. This way you can ensure that there will never be an overlap between systems.
You can use zoom on the star map after all and you have no size limitations like you have on paper.

The above solution might work for the first 3-4 connections, assuming no loops, but when you get to 10+ jump chains and hundreds of systems, you quickly run out of space. How do you handle situations where there are not enough surrounding 'locations' for the systems (mainly due to the presence of other nearby un-connected systems) and how do you handle loops, especially nested loops?

The star map doesn't zoom BTW

Loops are the biggest issue I can see and they should be prevented at all costs. Every Item should only be allowed to be placed once and cross connections would be ugly in these cases. I never came to a situation where there was not enough space in LaTeX though. You could simply fit more objects on the circle when you increased the radius of it. The hard limitation of it was paper dimensions, which can be ignored when it comes to game development.

[Steve Walmsley (OP)]

Loops are the biggest issue I can see and they should be prevented at all costs.

Loops are a major part of the game. I am not going to prevent them in order to make mapping easier.

[mike2R]

Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large

Happy to implement if you can supply the logic

There seems to be a very nice package, that is unfortunately in javascript, called d3 force that looks like it could do something pretty neat using a force-directed graph technique.

Demo (with some really nice drag functionality):
https://observablehq.com/@d3/force-directed-graph/2?intent=fork

Source:
https://github.com/d3/d3-force

[Garfunkel]

Loops ... should be prevented at all costs.

I'm sorry but that is complete nonsense. Yes, loops make mapping more difficult but they are often a storytelling spice that brings extra flavour to a campaign.

[Steve Walmsley (OP)]

Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large

Happy to implement if you can supply the logic

There seems to be a very nice package, that is unfortunately in javascript, called d3 force that looks like it could do something pretty neat using a force-directed graph technique.

Demo (with some really nice drag functionality):
https://observablehq.com/@d3/force-directed-graph/2?intent=fork

Source:
https://github.com/d3/d3-force

There are still crossed lines all over the place. I could write something similar, but it doesn't solve the problem, which is finding a layout which is neatly laid out, human-readable and limits the number of overlapping lines in order to achieve that. Even that doesn't solve the problem that different players will have different views on correct layouts and what constitutes 'human-readable'.

Apart from very small numbers of systems, Galactic mapping needs human intervention. I am going to stop responding on this topic so the thread doesn't get dominated by it. If anyone wants to discuss this in depth, I suggest starting a new thread.

[db48x]

Add an "auto-organize" button to the galactic map screen, which automatically sorts systems so we don't have to manually re-arrange the galactic map once it starts getting large

I think that it is important to aim for _simple_ improvements rather than complex ones. Automatic placement could be improved, but even a complex implementation will never be perfect. So the simple improvement that we really need is just better interactivity when dragging systems around on the map. Just making the snap–to–grid functionality less fiddly would go a long way by greatly reducing user frustration. It might even cause some user satisfaction!

Currently, when you drag a system to a new spot on the map there is no feedback about where it will actually snap to. This causes frequent misses, along with repeated attempts to move the system just far enough to put it where we want it to go. Just rendering a “ghost” in the spot where the system will end up and updating it as we move the mouse around would improve usability by a huge margin, and it would be far simpler to implement than any automatic placement system.

Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.

[nuclearslurpee]

I think that it is important to aim for _simple_ improvements rather than complex ones. Automatic placement could be improved, but even a complex implementation will never be perfect. So the simple improvement that we really need is just better interactivity when dragging systems around on the map. Just making the snap–to–grid functionality less fiddly would go a long way by greatly reducing user frustration. It might even cause some user satisfaction!

Currently, when you drag a system to a new spot on the map there is no feedback about where it will actually snap to. This causes frequent misses, along with repeated attempts to move the system just far enough to put it where we want it to go. Just rendering a “ghost” in the spot where the system will end up and updating it as we move the mouse around would improve usability by a huge margin, and it would be far simpler to implement than any automatic placement system.

Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.

I have advocated before for changes in the snapping parameters under the hood. Currently, the galactic map spaces systems 140px apart with default placement and the snap-to-grid function snaps systems to increments of 20px. This means that there are seven 'increments' of snap positions between default system placements which is silly and not at all conducive to any way of organizing the systems besides a square grid - sometimes I would like to do a hexagonal arrangement and this is not feasible.

So my suggestions would be:

• Change the default snap increment to a neater fraction of 140px - 70px is probably not flexible enough but 35px should be fine.
• Snap-to-grid should round to the nearest increment mark, currently it seems to prefer rounding up rather than down which is frustrating to work with.

For a EXE-only patch we can keep the default 140px spacing as it looks fine as-is and this would preserve compatibility with 2.5.0 maps, but we could change to a friendlier value like 144px or 160px in a DB release which breaks saves anyways.

[Droll]

I think that it is important to aim for _simple_ improvements rather than complex ones. Automatic placement could be improved, but even a complex implementation will never be perfect. So the simple improvement that we really need is just better interactivity when dragging systems around on the map. Just making the snap–to–grid functionality less fiddly would go a long way by greatly reducing user frustration. It might even cause some user satisfaction!

Currently, when you drag a system to a new spot on the map there is no feedback about where it will actually snap to. This causes frequent misses, along with repeated attempts to move the system just far enough to put it where we want it to go. Just rendering a “ghost” in the spot where the system will end up and updating it as we move the mouse around would improve usability by a huge margin, and it would be far simpler to implement than any automatic placement system.

Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.

I have advocated before for changes in the snapping parameters under the hood. Currently, the galactic map spaces systems 140px apart with default placement and the snap-to-grid function snaps systems to increments of 20px. This means that there are seven 'increments' of snap positions between default system placements which is silly and not at all conducive to any way of organizing the systems besides a square grid - sometimes I would like to do a hexagonal arrangement and this is not feasible.

So my suggestions would be:

• Change the default snap increment to a neater fraction of 140px - 70px is probably not flexible enough but 35px should be fine.
• Snap-to-grid should round to the nearest increment mark, currently it seems to prefer rounding up rather than down which is frustrating to work with.

For a EXE-only patch we can keep the default 140px spacing as it looks fine as-is and this would preserve compatibility with 2.5.0 maps, but we could change to a friendlier value like 144px or 160px in a DB release which breaks saves anyways.

I recall that VB6 aurora actually allowed the user to change the spacing in-game.

[captainwolfer]

Feature Suggestion: Add the following 2 fleet orders (as orders that can be queued, not conditional/standing orders):
1. Wait for Trigger: Fleet will wait until triggered by a different fleet, then will continue with its queued orders.
2. Trigger Nearby Fleets: Fleet will trigger any waiting fleet at the same location.

This would give a way to automate rotating ships between a location for overhaul (IE spy ships or a jump point defense.)

Practical example: you want to keep a constant presence at a jump point. So, you create two fleets of ships, and set both to cycle orders, with the following order queue:

Code: [Select]

Move to jump point (Time Delay 365 days)
Trigger Nearby Fleets
Wait for Trigger
Refuel and Resupply at Planet
Overhaul at PlanetThe other fleet would be the same, you would just have it start at Wait for Trigger.

This way, you always will have 1 fleet at the jump point, and once per year or so, the other fleet would come and replace it so the ships can go overhaul, with no need to manage things or remember to send a fleet before the other fleet exceeds its deployment period

[BwenGun]

QOL Suggestion:

Show the ages of scientists as part of the information given when choosing someone to head a project.

May not be relevant to everyone but I've been playing a slower paced game (40% research speed, with Limited Research Admin) and I've run into the problem whereby I'll start the research and then a couple of months later the scientist retires as they reach their mid 60s. Having their age listed when choosing from the list would make it a lot easier to avoid that, whilst also giving players a better idea of when it would be a good idea to switch to a less experienced scientist to train them up.

[tastythighs]

I'd like to suggest the ability to delete/scrap multiple ground formations at the same time, or to delete/scrap all formations with X template.  Consolidating engineers and STOs into larger formations to reduce list clutter would be much, much easier with this feature.

[db48x]

Even just changing the rounding so that systems snap in a more intuitive way would be a huge improvement, and probably won’t require changing but a couple of lines of code.

I have advocated before for changes in the snapping parameters under the hood. Currently, the galactic map spaces systems 140px apart with default placement and the snap-to-grid function snaps systems to increments of 20px. This means that there are seven 'increments' of snap positions between default system placements which is silly and not at all conducive to any way of organizing the systems besides a square grid - sometimes I would like to do a hexagonal arrangement and this is not feasible.

Hexagonal arrangements are not impossible, even if they are not easy to achieve:

To do this I had to cheat really hard. Once I got the first few systems into a nice hexagonal arrangement, I placed a piece of scrap paper against my monitor and gently transferred their locations to the paper with a pencil (the green circles shone through the paper). Then, to place new systems in the pattern correctly I would line the paper up against two or three of the existing systems and drag the new on until it was just to the left of and above the next circle on the paper. It was still pretty fiddly and awkward, but at least it was doable.

So my suggestions would be:

• Change the default snap increment to a neater fraction of 140px - 70px is probably not flexible enough but 35px should be fine.
• Snap-to-grid should round to the nearest increment mark, currently it seems to prefer rounding up rather than down which is frustrating to work with.

Completely agree. The wonky rounding is the most frustrating thing about it.

[nuclearslurpee]

Hexagonal arrangements are not impossible, even if they are not easy to achieve:

This is true and I wrote imprecisely. What I meant is that it is not possible to create a hexagonal arrangement which can work with the existing 140px default spacing at all, if you want either the horizontal or vertical spacing to be automatic then you cannot have an evenly spaced hexagonal grid because we cannot snap to the 70px intermediate positions.

[tastythighs]

I split facility construction 50/50 so the system doesn't get clogged by big orders, but this does mean I have to change the %used by construction every time I open the window, either by typing it or selecting an existing work order.  I'd very much appreciate the ability to set a default construction % for new construction tasks to use. 

[Hari]

I split facility construction 50/50 so the system doesn't get clogged by big orders, but this does mean I have to change the %used by construction every time I open the window, either by typing it or selecting an existing work order.  I'd very much appreciate the ability to set a default construction % for new construction tasks to use.

Or remember the last % used.