Posted by: Kiero
« on: Yesterday at 08:46:45 AM »For RP purposes, it would be great if a module for a ship could be designed to assign a Scientist and/or Administrator.
Posted by: nuclearslurpee
« on: Yesterday at 05:21:18 AM »Engine technology:
I know this topic has already been raised, but every time I play I wait for the engines to reach at least the level of the Nuclear Pulse Engine.
Maybe it would be worth raising the cost of researching the initial stages of the engines, that would extend the time they can be used, both by players and AI?
Counterpoint: I use NRE tech quite a bit in my conventional-start games. I also play with limited research admin + 50% research speed, so even developing NTE tech takes some time during which I can build quite a lot of NRE-level freighters and colony ships. So personally, I prefer things as they are since I would not want to drag out the conventional starts even longer than they already are.
Posted by: Kiero
« on: Yesterday at 04:59:21 AM »Engine technology:
I know this topic has already been raised, but every time I play I wait for the engines to reach at least the level of the Nuclear Pulse Engine.
Maybe it would be worth raising the cost of researching the initial stages of the engines, that would extend the time they can be used, both by players and AI?
I know this topic has already been raised, but every time I play I wait for the engines to reach at least the level of the Nuclear Pulse Engine.
Maybe it would be worth raising the cost of researching the initial stages of the engines, that would extend the time they can be used, both by players and AI?
Posted by: AlStar
« on: May 15, 2024, 01:05:42 PM »Exactly like that! 
Although (IMO) it'd be better if Steve integrated that functionality into the game itself, so we don't have to use a 3rd-party solution.
Maybe build it into the events tab - clicking on an event will let you change the text/background color (as now), and if it does/doesn't cause interrupts.
Although (IMO) it'd be better if Steve integrated that functionality into the game itself, so we don't have to use a 3rd-party solution.
Maybe build it into the events tab - clicking on an event will let you change the text/background color (as now), and if it does/doesn't cause interrupts.
Posted by: skoormit
« on: May 15, 2024, 12:37:49 PM »...a screen that lists all events, and has a checkmark for "does this stop time? y/n" would be ideal (although probably a lot more work than I'd expect.)
Even better if the screen lets us import/export our preferred interrupts.
Like this?
Posted by: AlStar
« on: May 15, 2024, 08:49:35 AM »It would be nice to be able to toggle a checkbox on the fleet orders screen to control if finishing shore leave stops auto-turns.To build on this, a screen that lists all events, and has a checkmark for "does this stop time? y/n" would be ideal (although probably a lot more work than I'd expect.)
Even better if the screen lets us import/export our preferred interrupts.
Posted by: vorpal+5
« on: May 15, 2024, 08:00:50 AM »And on the contrary (sorta...) entering overhaul will halt the time interval. Is it that important?
Posted by: skoormit
« on: May 15, 2024, 06:42:34 AM »The Shore Leave Complete event does not stop auto-turns.
Usually, that is my preference.
Sometimes, though, I am waiting for a ship to complete shore leave before I give further orders.
It would be nice to be able to toggle a checkbox on the fleet orders screen to control if finishing shore leave stops auto-turns.
Usually, that is my preference.
Sometimes, though, I am waiting for a ship to complete shore leave before I give further orders.
It would be nice to be able to toggle a checkbox on the fleet orders screen to control if finishing shore leave stops auto-turns.
Posted by: paolot
« on: May 11, 2024, 08:27:48 AM »I am liking the capacity of stabilization ships.
To further improve their value/ability, and have more Lagrange Points in a system, in Standing Orders would it be possibile to include the orders "Build Jump Gate at Nearest Terrestrial Planet", "Build Jump Gate at Nearest Gas Giant" and "Build Jump Gate at Nearest Superjovian"?
I think that a general order only (i.e. "build JG at nearest massive planet") would be limiting.
Instead, using these three ones, we can choose where to build new LPs, to have faster ships around.
To further improve their value/ability, and have more Lagrange Points in a system, in Standing Orders would it be possibile to include the orders "Build Jump Gate at Nearest Terrestrial Planet", "Build Jump Gate at Nearest Gas Giant" and "Build Jump Gate at Nearest Superjovian"?
I think that a general order only (i.e. "build JG at nearest massive planet") would be limiting.
Instead, using these three ones, we can choose where to build new LPs, to have faster ships around.
Posted by: skoormit
« on: May 09, 2024, 12:03:28 PM »Does the issue resolve itself after a time increment? (Theoretically) as long as you've got "use max speed" checked, the fleet should speed back up to max speed once they get underway.
I've seen similar display issues when giving orders to tugs that had dropped off terraformers - their orders will give an ETA that's based on their laden speed, but they'll actually get there much faster.
Negative.
The issue persists after time is incremented.
Move orders given to such a fleet will be undertaken at 1km/s.
Posted by: AlStar
« on: May 09, 2024, 09:46:11 AM »Does the issue resolve itself after a time increment? (Theoretically) as long as you've got "use max speed" checked, the fleet should speed back up to max speed once they get underway.
I've seen similar display issues when giving orders to tugs that had dropped off terraformers - their orders will give an ETA that's based on their laden speed, but they'll actually get there much faster.
I've seen similar display issues when giving orders to tugs that had dropped off terraformers - their orders will give an ETA that's based on their laden speed, but they'll actually get there much faster.
Posted by: skoormit
« on: May 09, 2024, 08:49:42 AM »Merging fleets with tugs can be problematic.
Say Fleet A has one or more ships with a tractor beam, and all these ships are tractoring engineless ships.
If Fleet A executes an order to join some Fleet B (which may or may not also have ships with engaged tractor beams), then sometimes (not always) the speed of Fleet B drops to 1km/s.
If I drag Fleet A into Fleet B, same thing happens: sometimes (not always) the speed of Fleet B drops to 1km/s.
The only way to reliably join the fleets without reducing the speed of Fleet B to 1 km/s is to individually drag the tractors from Fleet A to Fleet B in the left hand tree view.
(Dragging this way automatically brings the tractored ships along.)
Obviously, this can be very tedious for large fleets, and can only be done when the fleets are in the same location.
And it means that you just can't use the Join Fleet order when tugging ships.
And I do a *lot* of tugging, so this adds a lot of micromanaging to my playtime.
I'm hoping there's something easy to tweak in the fleet merging logic that can resolve this.
I wonder if the resulting speed is being determined by iterating through the list of all ships, which might be in ascending order of ship construction time, and it doesn't recognize that a ship is tractored unless the tractor has already been processed.
Note: I don't know if the situation only occurs when engineless tractors are targeted, because I only very rarely tractor ships with engines.
Other note: the same thing happens when detaching subfleets with tractors from fleets. Sometimes the newly detached fleet has a speed of 1km/s. Perhaps the same code is handling this as well.
Say Fleet A has one or more ships with a tractor beam, and all these ships are tractoring engineless ships.
If Fleet A executes an order to join some Fleet B (which may or may not also have ships with engaged tractor beams), then sometimes (not always) the speed of Fleet B drops to 1km/s.
If I drag Fleet A into Fleet B, same thing happens: sometimes (not always) the speed of Fleet B drops to 1km/s.
The only way to reliably join the fleets without reducing the speed of Fleet B to 1 km/s is to individually drag the tractors from Fleet A to Fleet B in the left hand tree view.
(Dragging this way automatically brings the tractored ships along.)
Obviously, this can be very tedious for large fleets, and can only be done when the fleets are in the same location.
And it means that you just can't use the Join Fleet order when tugging ships.
And I do a *lot* of tugging, so this adds a lot of micromanaging to my playtime.
I'm hoping there's something easy to tweak in the fleet merging logic that can resolve this.
I wonder if the resulting speed is being determined by iterating through the list of all ships, which might be in ascending order of ship construction time, and it doesn't recognize that a ship is tractored unless the tractor has already been processed.
Note: I don't know if the situation only occurs when engineless tractors are targeted, because I only very rarely tractor ships with engines.
Other note: the same thing happens when detaching subfleets with tractors from fleets. Sometimes the newly detached fleet has a speed of 1km/s. Perhaps the same code is handling this as well.
Posted by: Steve Walmsley
« on: May 08, 2024, 04:45:21 AM »In the Environment tab, together with the Annual Terraform capacity, I would like to read the number of the Terraforming Istallations active on (or near) a body.
Added for v2.6.
Posted by: paolot
« on: May 07, 2024, 06:31:05 PM »In the Environment tab, together with the Annual Terraform capacity, I would like to read the number of the Terraforming Istallations active on (or near) a body.
Posted by: ISN
« on: May 06, 2024, 08:04:18 PM »I've noticed that if an NPR fleet with jump-capable ships gets spooked and flees through a jump point, it will often not make a squadron transit even in cases where I'm pretty sure at least some of the ships could. I don't know if this is a bug or WAI -- I have no idea what factors the NPR code takes into account when deciding when and how to flee, whether to squadron transit, etc. -- but this particular behavior makes it really easy to exploit them (even if you're not trying to) and I feel like some better logic here would be a big improvement.
