Dear Frogboy,

I've just upgraded my DL ver 1.4 by buying DA ver 1.5 online and installing it. I've been playing for about 2 weeks now and there are some SERIOUS problems which you need to recitify before I even consider buying another GalCiv game. First is TRADE which is practically worhtless. I've been exploring this in another thread and am actually modding a game specifically to investigate and explore trade in DA. There is a severe problem with starbase maintenance that completely destroys the value of trade in medium and smaller maps. How do I know this? Because I've started my investigation and discovered that a 5 bc per turn maintenance fee destroys the Korx superability and benefits on medium and smaller maps. That means every year (52 turns the owner has to pay 260 bc per starbase whether or not it is useful. Adding trade modules gives you up to 60% additional income from a trade route if positioned effectively. That's only for a maximum of 17 turns if you perfectly position it, and if your really, really lucky you get more than 1 trade route merged together. What that means is that to break even the trade route must generate 433 bc for the maximum of 17 turns it is effective meaning in a perfect situation the trade route has to generate an average of 26bc per turn or your running on a deficit. On medium or smaller maps the amount is on average double that because starbase placement is usually less than ideal. This also has the effect of removing the bonus production value for worlds that generate less than 433 bc of bonus production per year meaning that worlds that generate 17mp's per week of starbase bonus production are running at a deficit. But worlds that exceed that are still efficient - providing your economy can burden the cost of the additional research/industrial units. If your intent was to eliminate or reduce the or some how address the 24 starbase 17k to 20k tp research worlds then you have failed and have instead created a severe game imbalance that negates a whole branch of the tech tree (trade), the Korx and their superability. Either limit the additional maintenance expense to only production upgrades (not very effective) or remove the bonus production from them entirely (which also creates a lesser cost to value problem), and to save the Korax, have their special abilitiy negate the cost completely. Perhaps best of all is to apply the maintenance cost to starbases only in maps of large or greater.

Second, there is a game imbalance with component sizes, particularly engines, that cripples large and greater maps. I personnally don't play large maps in DA now because my playing style favors starbases, and the way the game is now it would literally take me thousands of moves on a gigantic map to play out a game. This is unreal. Your size modules for engines should be balanced for the map size so that the player, outside of a random event that doubles speed, can create a constructor on a huge hull that only takes 2 turns to travel across the entire map from corner to corner. Because of the large numer of constructors required to build a starbase and UPGRADE it. Now I'm not trying to tell you what to do, but it just makes sense to have a spreadsheet for starbase management. Why? Because I should only have to build and construct the initial constructor ship; send it to a destination and build the initial starbase hull; and then manage upgrades like any other planetary improvement - from the spreadsheet. Then ship speed is nolonger a consideration for large/gigantic maps. Meaning that players like myself, who enjoy the building aspect of the game can still manage a decent game on the big maps. Personally, I think its time to abandon the entire ship size scheme because its outmoded. Hull sizes are a part of GalCiv original that I think would be better replaced with a hardpoint system where logistics defines the maximum number of hardpoints per ship and that component size should then be how many hardpoints it uses. Of course thats a major rewrite in itself, so I'm not holding my breath. (Again, though, engines should always be scaled to the map size, and fleet size logistics should be replaced by support modules or even eliminated entirely.)

In SUMMARY, their are some serious game imbalances that affect the GalCiv trademark of giving players the flexibility to use different playing styles, which in my opinion should be rectified or GalCiv will probably start to die. Since my play style favors DL, I see no reason to upgrade or purchase another GalCiv game unless it also supports my play style. Please don't tell me I can mod my own changes. That's just a cop out. Honestly, some people (I would guess the majority) are computer challenged and modding simply isn't a reasonable response for them. In the end its up to you to decide. I just hope GalCiv doesn't go the way of the dinosaurs.

I think the issue with contrusctors is not that you have to build so many but that you have to micro manage them too much.

I think what might be a good feature would e a new type of rally point that simply says "Send all completed constructors here automatically".

It would be a help if the ship presently selected was highlighted somehow. Maybe it flashes at fast speed or changes color. It is frustrating whem you think you have selected a ship but end up moving a different one.

Selected ships have an animated cursor around them. I'm not sure what you mean by tithis.

Dear Frogboy, I too have experienced this effect where the ship in the current display remains highlighted after movement is exhausted with what I will call a "ghost" cursor when the next ship in the movement que is selected. Its easy to miss when you get click happy, but if you actually read the text display the ship designation, location, and move parameters are different. By hitting "C" (instead of just clicking or using the find button, which doesn't work when this occurs) you are moved to the actual location of the selected ship. It appears to happen when the ship movement que exceeds the current buffer limit and needs to make a call to another stack(if it were written in assembler and not perl or somesuch thing, so feel free to ignore the extra jibberish). After hitting the "C" key and/or selecting the correct ship it(the stack pointer?) restores itself until the next group of large movements occurs. I hope this explains the problem better, because it can be annoying.

One question: did you really read all those suggestions?

Anyway, here are mine.

1) defenses should be more valuable. Attack right now has a great advantage. Simply said I do not research defensive techs

2) trading techs is impossibly expansive. diplomacy is useless.

3) want a carrier type ship: get X bombers that attack with your best available missile type (one shot). Each launched bomber has Y hit points and the other side cannot hit the carrier if any bombers is alive. Bombers are shown only when making a fleet battle. basic carrier could load a balance of stuff (weapons, engines...) and bombers.
Example: large carrier
120 hit points
80 for stuff
40 remaining for 8 bombers (Y=5 ; X=8)
Lost bombers would be replaced at the rate of 1 per turn if inside controlled territories.

4) want a stealth type ship (a submarine). can be seen only when nearby. strikes a selected ship even inside a fleet and inflicts a large damage like 50 points. very slim defenses (1) and hull (10) so an enemy first strike would win normally.

5) if you make peace you cannot go to war before X turns

6) whant to have the ability to tell the AI to remove ships from nearby or exchange starbase / planets on a 1 to 1 ratio

A general comment: I have found DA much more enjoyable that GC2.

I thing I have noticed is that when I use auto-explore or auto-attack (or other "auto" actions), the ships tend to follow the same paths if they are close to each other in position. Would it be difficult to implement a way to prevent this from happening? Maybe create waypoints or something. It's kind of annoying when two scout ships just follow each other or two fleets head for the same target.

yet another idea...

As part of a spying level, or just in general, It would be time saving to ba able to view and AI's tech tree. I mean all the info is really already available, but hard to see.

... (continuation from above): but most importantly: giving you new missions you can accomplish, like assasinating the planet's leader, sabotaging buildings, spreading disease or even starting a reverse terraforming! (NB. the game Haegemonia has wonderful spy rules). Getting caught should be a question of your level of spying versus the victim's level of counterspying ... Stopping the spy would not mean that his origin is automatically revealed, but when the origin is revealed that would of course be a major diplomatic incident (changing the relationship towards hostile).

In this way you would be able to play more offensively against the PC without going to war and with only a risk that you will be caught. This could become really important in the game if you consider 5 smaller civs all going against one leading civ individually ...

The one thing I'd really like to see is when Council votes come up that are of the sort like limiting number of starbase modules it should be a pair of votes. The first vote is "Should starbases have a limit of modules?" If that passes then vote on the number of modules.

( Frogboy May 8, 2007 23:56:37Reply #279 )

With the number of constructors presently required, it would be nice to have a controls that would allow you to send only constructors created from all or some ports to a location.

I think the issue with contrusctors is not that you have to build so many but that you have to micro manage them too much.

I think what might be a good feature would e a new type of rally point that simply says "Send all completed constructors here automatically".

Reply_______________________________________________________________

That would certainly be a good improvement Frogboy. Although it would be even better if I could select which planets would be affected by the rally point. After all, you may be working on star bases that are just too far away from some planets and maybe even out of range for the constructor to reach!

1) make the variable number of asteroid squares per racial homeworld indicated in the .xml file work. Right now (1.5x, 1.6b1,2), all home systems get exactly 3 squares of asteroids. this is a wonderful tool to get a little more differentiation, fine tuning of racial characteristics, but it sisn't working.

2) consider movement advantages for tiny (and small??) craft when moving through asteroid fields. Basically I'd say just let tiny ships move normally through them, and smalls maybe lose one MP.

3) consider combat bonuses for tiny/small ships when they are attacking from or defending on asteroid fields.

4) consider similar additional combat bonuses for tiny/small ships when defending from orbit.

5) consider permanent +1 speed advantage for tiny/small ships.

6) consider a "Super Planetformer" super ability, either as a substitute for Iconians or just for custom races. Gives additional +1 tile per planet per level of terraforming tech.

drrider

Starbase Transporter/Tug Boat
Provide a ship module allowing you to create a starbase tugboat so you can move them around, (slowing of course) or simply provide a module which can be added to the SB to allow it to move itself. This would allow players to change thier tactical positioning. Again this should be a slow process.

Military starbases should be allowed to auto/manaual attack enemy vechicles that come into thier sphere of infulence.

Patrol routes / linked rally points
Allowing patrol routes to be ship up for ships on sentry, or gaurd duty

Hunter/Search and destroy options for ships
Option for ships or fleet to perform automatic search and destroy for emeney ships.(need to be able to define a race to target though, incase of multiple enemys)

"GW Swicord" mentioned this, which i also would like
Separate sliders for spending to recruit spies (Economy page) and spending for intel on each rival empire (Foreign Policy page).

Dear Frogboy,

I have also observed one other condition that causes ships to lose their rally point and/or destination. Namely, when the AI initiates a diplomatic screen, which it did in one of my recent games, some ships were still moving. After the screen closed I had to reassign rally points for 2 or 3 ships which hadn't moved or hadn't finished moving when the diplomacy screen was initiated. I suspect this could be responsible for some of the AI/player ships losing their destination, as well as freighters which stop moving along their trade routes.