Recent Posts

Pages: 1 ... 8 9 [10]
91
C# Suggestions / Re: C# Suggestions
« Last post by Polestar on June 12, 2021, 12:14:23 PM »
Some suggestions and observed issues, based on a couple of 1.13 games:

1. The Swarm is too variable in the danger level it poses, and can be far too deadly. What deep-space bugs should not do is a) scout your home planet (>10B km away from any jump point or linked LP point) five years into a game, park 10s of thousands of tons-worth of warships in orbit a few months later, destroy all your shipyards, and start bombarding your helpless early-game homeworld to dust and ruin. Endlessly, because they never run out of supplies.

This is unfair, because:
a) The player, if they set up using ordinary early-TN tech levels (the ones the game offers as defaults), may well not be able to fend off such an attack so early on. "You lose. Regardless of any attempt you might have made at preparedness." is not what a game should tell players. This applies also to the Invaders.
b) Distance should matter to the AIs. If the AI can't be made to understand fuel limits, it should at least respect a travel distance limit.
c) Supplies should matter to the AIs, at least in some sense. They don't have to run out when attacked, but if attacking, they should not be able to fire beam weapons endlessly, especially when bombarding.
d) If it is intended for space bugs to be a mortal threat, or at least if they should attempt to wipe out players if not stopped, then the game should provide some sort of warning that these aren't just ship-killing, wreck-harvesting critters ... the Swarm wages wars of extermination!


2. The bugs or game design choices that trigger lengthy - and in some cases quasi-endless - runs of increments measured in seconds, when the player is not involved, need to be hunted down and put of players' misery.

a) Are all fire controls being properly cleared when a target is lost or no longer available?
b) Can AI-versus-AI fights be resolved using a simplified set of rules? "If on attack and not in range, but might be able to get into range, chase until in range. Otherwise, defend. If has missiles, and missiles can't be shot down well enough, subtract missiles and inflict damage. If has beam weapons, and can catch target, catch target and inflict damage. Otherwise, set to chase or defence, and counter-fire only. Repeat for all other sides. Repeat for each suitable sub-block of time. Stop when all but one side is destroyed or escapes, or all sides are on defense, or the player-specified block of time ends." That kind of thing.
c) If a) and b) are not sufficient, then at least allow the player to learn which fleets are killing game progression, so they they can be deleted. Make it easier to kill off fleets without triggering "not set to an object" error messages.


3. On the subject of those dratted error messages: The keystroke used to clear the message should not be the same keystroke used to request another turn increment. At present, both are ENTER on my keyboard. Extra credit if the error message could be presented without popping up a box, and/or if the game got better at deleting objects that trigger such messages. For example, if a ship can't find its fleet, maybe kill off the ship?


4. The game interface redraws windows and refreshes text extremely inefficiently. This is immediately noticeable on the message window. The Economics window also has a problem here, a problem worsened by its refreshing every turn increment (even if only 5s) instead of just doing one automatic refresh every construction cycle. In long games, the Leaders window and even the Ship Design window can also bog down.
92
C# Suggestions / Re: C# Suggestions
« Last post by Jorgen_CAB on June 12, 2021, 11:27:10 AM »
I can verify that small crafts still can't unload/load cargo on their own, at least not colonists which is what I tested, I did not try from a cargo hold.

Another issue that still exist is that Troop Transports can unload/load troops on any planet no matter their size without cargo shuttles a well, I'm pretty sure they are not suppose to be able to do that. At least it is a bit weird that they can.
93
C# Bug Reports / Re: -ProbablyCosmetic- Create Research Project fields
« Last post by Droll on June 12, 2021, 11:10:20 AM »
I will add that those entry fields also show on the component design screen when playing with the resizable windows mod.
94
C# Suggestions / Re: C# Suggestions
« Last post by nuclearslurpee on June 12, 2021, 10:26:41 AM »
Closest I can find is this post here. It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.

In the 1.12 changes list, Steve explicitly states that "Fighter-sized craft do not require cargo shuttles to load / unload colonists or cargo. Due to their size they can land and load/unload directly."
I don't know if it actually works. I made an engineless fighter with cryo transports the other day and it couldn't load/unload without a cargo station but that might be because it was engineless. I didn't test it exhaustively in order to produce a bug report.

In that case someone who has confirmed this should report it as a bug. I would do it but I can't confirm myself at the moment.
95
C# Bug Reports / Re: -ProbablyCosmetic- Create Research Project fields
« Last post by nuclearslurpee on June 12, 2021, 10:25:29 AM »
This would probably get better visibility from Steve if it were posted in the actual bugs thread.
96
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by nuclearslurpee on June 12, 2021, 10:24:11 AM »
- Quick Question: Can a Jump Drive that is marked as "Self-Jump Only" still jump other ships via a Standard Transit,

Yes. The restriction applies to squadron jumps only, and will be clarified in v1.14.
97
C# Suggestions / Re: C# Suggestions
« Last post by kyonkundenwa on June 12, 2021, 09:49:12 AM »
Closest I can find is this post here. It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.

In the 1.12 changes list, Steve explicitly states that "Fighter-sized craft do not require cargo shuttles to load / unload colonists or cargo. Due to their size they can land and load/unload directly."
I don't know if it actually works. I made an engineless fighter with cryo transports the other day and it couldn't load/unload without a cargo station but that might be because it was engineless. I didn't test it exhaustively in order to produce a bug report.
98
New Cold War / Re: Cold War Comments Thread
« Last post by Kurt on June 12, 2021, 08:37:44 AM »
Firstly thanks for the updates, I enjoyed reading them.

As a rules question, I thought that only 1 ship can sit in each hex, is that not the case or did the Tormsk Union not place mines directly surounding the warp point?

As Paul noted, there are no stacking limits.  As for the mines, they cannot be placed directly in the hex containing the warp point, so this effectively creates a safe space in the warp point entry hex on the map for attacking ships.  Of course, they are only safe from the mines, not defending ships or buoys.  Mines can be placed directly on a closed warp point hex, meaning that as soon as the attacking ships jump in they are attacked by the mines, giving them no safe space.  The warp point into the Tomsk Union system is actually a closed warp point, so the Tomsk Union could have placed mines directly on the warp point, but I had decided way in advance of this event that the Tomsk Union would not do that, as they were maintaining diplomatic contact with the Colonial Union and were hoping for an improvement in relations.  In terms of economics, the Colonial Union is as large as the Tomsk Union and the Bjering put together, although it is lower tech.  In any case, the Tomsk Union didn't want to cause an interstellar incident by accidentally blowing up a Colonial Union diplomatic ship, so they hamstrung their own defenses.  They did this in the knowledge that the Bjering would back them up, and they were fairly sure the Colonial Union didn't want a long war on their hands.  Their entire strategy was based on the belief that if they made it too difficult and costly for the Colonial Union, Union forces would be forced to give up and leave by public opinion in their core systems.   

Quote
When the BC came through the warp point, the targeting switched from the CL to the BC. When the SD came through the warp point, the targeting switched again to the SD.
Why was this done? Isn't getting a mission kill on an existing target more valuable than scratching the paint on a new ship? Especially with the SD's being much larger than the BC which were firing on them.
In addition to this, the CL were minesweepers, so reducing the number of functioning minesweepers would have potentially let the minefield survive and inflict damage on the rest of the rest of the fleet as it passed through, or maybe caused the minesweepers to spend more than 1 turn sweeping, which lets the Tormsk fleet keep getting 'free' missile hits.

This was exactly what Paul said.  The defenders were trying to damage as many ships as they could on the turn they entered, taking advantage of the fact that they were out of their datalink networks and their point defense was degraded.  Also, from the Tomsk point of view, they were trying to inflict a lot of damage, not destroy ships.  Destroying ships would piss off the United Colonial Defense Fleet, and risked rousing the Colonial Union's population against them.  Instead, by damaging as many ships as possible, they were creating a problem for the Colonial Union, and reducing the number of ships that could move forward against them in the next phase of the battle, which would be around the capital planet, where the Bjering would come into play. 

Quote
Also I wasn't quite sure, are DSB-L one shot only and are they targeted by the command ship? It seems like another case where lack of focus fire left the CU with many functioning ships, whereas with more focus more of the ships would be mission kills, or is that the reason for using smaller hulls for minesweepers?

They are one shot, although there are higher tech buoys which can recharge, although not in time to fire again in a battle.  Preferably, the Tomsk Union would have preferred to fire their buoys earlier in the battle, where they would have caused damage to fewer ships, but would have caused more serious damage to those ships.  Unfortunately, the Tomsk Union only had two ships at the warp point that had control systems for the buoys, and by they time they activated it was too late to focus on fewer ships. 

Kurt 
99
C# Bug Reports / -ProbablyCosmetic- Create Research Project fields
« Last post by Jeltz on June 12, 2021, 07:41:36 AM »
v. 1.13.0, no mods.

It never seems to have been reported: simply put in full screen mode the Create Research Project windows: on the right appear two fields, "Entry #1" and "Entry #2", apparently editable.

J.
100
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by xenoscepter on June 12, 2021, 04:21:07 AM »
 - Quick Question: Can a Jump Drive that is marked as "Self-Jump Only" still jump other ships via a Standard Transit, or does this limitation apply to both Squadron Jumps AND Standard Jumps?
Pages: 1 ... 8 9 [10]
SMF spam blocked by CleanTalk