joeball123

[quote who="Horemvore" reply="8" id="3632424"] I was just looking at that. That is what I am going to "hopefully" replace. But I see a reference to it in ComponentClassDefs.xml, does this not mean its buildable in game? Or is it just a fake entry? [/quote] Look in ShipComponentDefs, StarbaseModuleDefs, and anywhere else that might possibly make use of EscortFightersCap. Nothing uses it anymore. Moreover, all of the base game factions have the same fighter class for their Ini

[quote who="Horemvore" reply="6" id="3632421"] Further investigation has bared a bit of info, there are schema files for StatTypes and ModifierEffectTypes but no xml files linked to these schema. I guess modding these is locked away for now, or forever. [/quote] At present, it's more or less the case that if something cannot be done with the things defined in the schema files that come with the game, you cannot do it. That being said, there are things defined in

[quote who="Horemvore" reply="4" id="3632407"] ATM though its not looking good. As I can not see how or where to make a new Stat Type effect. StatTypeDisplayDefs.xml just "seems" to be the place, but you can not define what your Stat Type does or does not do. I am guessing it is just a link file for some dll to reference. [/quote] I assume that you're trying to make use of fighters for the defense platforms and do not want to use AssaultFightersCap, InterceptorFightersCa

Unless I've missed something in a recent patch, the base population growth is a constant defined in GalCiv3GlobalDefs.XML. Look for the GlobalColonyMod with an EffectType of Growth. The formula for the difference in a planet's population between this turn and next turn is r * (1 + approval_mod + other_bonuses), where r is the base population growth defined in GalCiv3GlobalDefs, approval_mod is a number between -0.25 and +0.25 which can be computed using the planet's curren

The sensor range of a colony is defined by a line in the improvement definition for the colony or civilization capital, which is in ImprovementDefs.XML.

[quote who="naselus" reply="30" id="3630959"] Problem is, a huge hull with all max-tech sensors on it has a vast range; so vast that you can't make it into a sensibly-sized portion of the map without making early-sensor small ships essentially blind without basically saying at some point that sensors don't have any further positive effect. [/quote] You can adjust sensor components so that you can make early-game ships which have a reasonable sensor range without allo

[quote who="naselus" reply="27" id="3630780"] I think a small diminishing return on radius bonus (say -10% per module) [/quote] If you want a -X% sensor range per component system, you may as well impose a flat limit on the number of sensor components you can add to the ship and forget about the stacking penalty. The way that the stacking mechanics work, if you have a base sensor range of k, a percentile sensor bonus of c from sources other than sensor components, and a sens

The only things in the component definitions for Mercenaries which might limit a component to one per game are the Mercenary and Mercenary tags, though I'd be far more inclined to believe that whatever limits the mercenaries to one-per-game has to do with how the game handles purchasing things from the Mercenary Bazaar rather than being anything to do with any tag in the component definitions. I don't really k

That tag prevents more than one component of a specific type from being added to a given design, it does not prevent an empire from having more than one ship which carries a given component.

[quote who="Go4Celerity" reply="6" id="3630196"] I've always wanted this change. I've argued for it since Beta. It was Impossible to mod into the game and had to come from Stardock's end. [/quote] While it was not possible to mod in a constant area per component or per capacity spent model, it was possible to get something similar simply by adding a per-component capacity scaling factor to the sensor components, which results in both the number of tiles revealed

[quote who="Seilore" reply="1" id="3630137"] They completely changed they system on how it works. I don't think you can change it back. [/quote] I have not looked at the current opt-in. However, based on the patch notes, it sounds as though sensor components now provide a 'scan power' which represents a number of tiles revealed. Is that correct? If so, it should be possible to add a 'scan power' multiplier to the sensor components which would produce at l

[quote who="Seilore" reply="4" id="3625474"]Seems kind of dumb for you to be able to survey before you research survey even if it is a prototype.[/quote] If the Prototype Survey Module and the Survey Module were available from the same tech, I don't think that the Prototype Survey Module in its current form would be used. Its only real advantage, aside from being available sooner, is that it costs 24 less base capacity; the lower manufacturing cost, while kind of nice, is also a b

[quote] 6) Trade resource value should be affected by the personality traits and civilization preferences. Synthetic races should value trade resources that give + to growth or food a value of 0, since they aren't affected by those metrics. [/quote] Let's say that I own a van Gogh which I think is hideous and let's further suppose that I am not the kind of person who wants to have something just to have it, whether or not I actually like, want, or care about it. I get

[quote who="Mystikmind" reply="8" id="3625089"] I usually use it because i have assumed it reduces the build time of the ship compared to having that space used by primary defense modules?.... but when i think about it, i do not know for sure that is the case? [/quote] It will reduce the total manufacturing cost by comparison to filling that space with standard defenses, yes. By late game, it may even be reducing the overall manufacturing cost of the ship by a few hundred po

[quote who="The Sisko" reply="9" id="3624945"] I'm fairly certain (don't have the XML available so I'm going off memory) that the hull modifiers are acceleration only. All ships have a base speed of 35. [/quote] No, they're to both speed and acceleration. Also, the base tactical speed, as defined in GalCiv3GlobalDefs, is 40, not 35. As far as the subject of whether or not speed affects evasion, I am not certain, but I am rather do

[quote who="slothDC" reply="6" id="3624977"]So...there's no limit? [/quote] On the amount of HP restored by tactical repair in combat? No, not that I'm aware of, aside from those limits imposed by time constraints and maximum ship HP. I agree with erischild's view that tactical repair is unlikely to save any given ship, except maybe in an edge case. Like erischild, I feel that tactical repair is more useful for keeping the fleet in decent shape after a

Bearing in mind that I haven't paid much attention to tactical repair since v1.0 or so: [quote]How often does it trigger in battle? [/quote] You recover the repair rating in HP every 'tick' of the engagement, with 'ticks' being timesteps of a duration I don't know which is much shorter than the period of the firing cycle of any of the weapons. [quote]How much damage HP does it repair [/quote] As far as I know, the maximum

[quote]I got one planet that mysteriously decided to stop building.... I wonder if i accidentally clicked on something, what kind of things should i look out for? [/quote] If the planet is sponsoring a shipyard, the issue could be that you've somehow accidentally set most or all of the manufacturing output to military (most would lead to very slow build rates on the planet, all would lead to no construction on planet). The only other thing that I can think of that could

[quote who="Frogboy" reply="23" id="3608358"] In GalCiv II, the components had a fixed and a % space cost. This ensured you couldn't put on 50 engines and 80 sensors because an engine would always use 5% of the hull space +5. I think this needs to be brought back. [/quote] I'd point out to whoever said that Frogboy was in favor of diminishing returns that this is not a diminishing returns system but rather a system where the component cost is

[quote who="Taslios" reply="44" id="3622955"] Going back to the thought line of GC2 and scaling the size of the components dependent on the size of the ship. I think this is probably something that would help and would be a happy middle ground for everyone. Also if you made the weapons themselves scale you could see that a huge hull ship with 12 "lasers" does indeed have bigger lasers than the tiny hull ship with 12 lasers... but that's a WHOLE different discussion.<

ColonizeEventDefs.XML; DLC4_ColonizeEventDefs.XML should be the one for the Precursor worlds, and is off in the DLC/DLC4_PrecursorWorlds/Game directory rather than in the main /Game directory.

Yes.

[quote who="stevezar" reply="34" id="3622425"] It typically means you dont need to have sensors in any fleet [/quote] Changing sensor stacking mechanics is not going to incentivize adding sensors to warships, and is unlikely to result in sensor ships being added to combat-capable fleets except perhaps if the stacking penalty is extreme (e.g. no point in having more than two or three sensor components, at which point a larger or later-game sensor ship might have plenty of spa

[quote who="BuckGodot" reply="3" id="3622286"] Mind, I don't know if there is some upper bound for the amount of turns one can put in: [/quote] Last I checked, the upper bound on the value of numeric variables in the XML files was something like (2^31 - 1) / 1000, though I've not checked with any of the variables that could reasonably expect to see only integer values. If they decided to handle the variables that can reasonably be expected to only have integer values

[quote who="Taslios" reply="12" id="3621852"] Life support (something that oddly the AI has no issue stacking) [/quote] It's not at all odd if you look at ShipBlueprintDefs.XML and understand how the computer handles creating designs from the templates provided therein. The blueprints are simply component lists; the computer will add a component of the type specified for each entry in the blueprint in the order in which the entries appear, and will then cycle through the