[quote who="Old-Spider" reply="5" id="3935200"] I've reviewed this and found 52 places where ship was used in ShipClassDefs.xml when it probably shouldn't be there. A quick search and replace fixed it for me in a mod. I haven't tried the mod to see if anything was messed up by the change. I think it will take more than a quick fix to fix it and make sure it didn't break anything. [/quote] I think the "Ship" suffix is
Mark Short
[quote who="RammaStardock" reply="4" id="3935190"] Hello Dorian, this has been relayed to the team accordingly, it may take a bit before the fix is introduced as most of the office will be out for a week on holiday [/quote] If it just gets fixed at all I would be very happy!
Through much trial and error, I feel it is safe to say that players (even modders) have very little control over Galaxy Map generation. Via manual manipulation of the Prefs.ini, MapSizeDefs.xml, and StarClusterQuantityDefs.xml, players have: questionable control over the number of Sectors generated via StarClusterQuantityDefs.xml for example, I can get the Galaxy (shown below) generated by setting 'Ma
For example, the following results in the corresponding map being generated. In this case, I explicitly set 8 Medium Sized Sectors to be generated. But that is not what I get. Huge 2928  
The following (StarClusterQuanityDef.xml , not what is contained in MapSizeDefs.xml ) appears to dictate number of sectors being generated. For 'Huge' maps using the 'Many' setting, it appears to be capped at 10 Max Sectors. I would much prefer for the UI to let me set this value myself rather than all of this senseless obfuscation. &l
This is more than just 'amiss'. Galaxy Map Generations is currently broke in v2.7. With the following UI Settings: Large Galaxy (which is really Huge Galaxy, internally) Max Setting for Sectors Max Setting for Distance from other Civilizations Using the default number of Civs for the map size (16 Civs) I encounter the Iconians on T3. From the map below, their home planet is practically adjacent to my own.
And the following value? It means nothing in v2.7. PlayerStartingLocationSetting= StartAloneInSector I encountered the Drengin on turn 2!
1. As far as sector generation, there needs to be a value more definitive than "Many" in the UI. This is just nuts! 2. The following are the settings from most recent "prefs.ini", yet I cannot tell they are even being used. Note that 'GalaxySize=Huge' below is a result of 'GalaxySize=Large' in the UI. The 'Large' category no longer exists in the XML files and was replaced by 'Huge'. (a complete
Agreed. Do not believe it impairs runtime functionality. But for modding purposes, having access to the schema validation is very helpful.
After about 10 attempts finally got my own sector.... but nothing like I wanted for the rest of the Galaxy. I do not want a huge sector and the rest of the AI to be starved of expansion space. Desired: 8 Medium Sized sectors with approx 2 Civs / Sector. I was previously able to do this from the UI without having to go Mod an XML file. FYI - I changed the Galaxy settings to "Large" this time hoping it would give more space for more Medium sized sectors.... but n
*sigh* Rolled again. Sectors are now too **** big. I know there are at least 3,4,5,more other Civs in the following. Actually, I much preferred the base GalCiv 4 settings (before even SuperNova). You really had much more control on Galaxy map generation than either SuperNova or v2.7. In basic GalCiv 4, I could easily generate 8 sectors with 2 Civs per Sector. Try doing that now! <img src="https://cdn.stardock.us/forums/6/39
Instead, I believe the correct location is actually: xsi:noNamespaceSchemaLocation= "../Schema/DoctrineDefs.xsd"
The current configured location of the DoctrineDefs.xml schema is not being found and is incorrect relative to the DoctrineDefs.xml file:
Piercing Breeze is now showing up correctly in the build list. [e digicons]:grin:[/e]
Basically, what I want and was previously able to do was generate a map with a lot of small to mid-sized sectors. What you have now is a chaotic mess with many of the user map generation settings completely ignored. [e digicons]:maybe:[/e] [e digicons]:maybe:[/e] [e digicons]:maybe:[/e] How exactly can removing a player's control over the map generation parameters be perceived to be an "improvement" or a good thing?
This is what those same settings give me now. Are you kidding me???
Previously, I was able to almost guarantee I would be the sole inhabitant of my starting sector with the following settings. Now, it is no longer the case and it is next to impossible. :( :( I do not remember anybody complaining about the previous map generation settings.
To be clear, in the ShipClassDefs.xml file, the following changes are needed: <span style="color: #cccccc; --da
Gentlemen, Not only have I previously reported this issue, but now I have provided a fix. Please incorporate this fix to your ShipClassDefs.xml file as soon as possible. Thank you.
This is the same issue as reported regarding the NaniteCloudShip ship classes, except it is regarding the ShieldBubbleShip ship classes as follows: AltarianShieldBubbleShip TerranAllianceShieldBubbleShip_Name
You guys have the wrong data values for the following: AltarianRepairNaniteCloudShip TerranAllianceRepairNaniteCloudShip_Name TerranAllianceRepairNaniteCloudShip_Dec
v2.7 made no difference.
The screenshot is to show an example of the side-by-side comparison done and the type of changes made in the v2.7 update. Just the ones I have reported, which remain unaddressed include: Beam Wpns vs Particle Beams (also previously reported by others) Incomplete / inaccurate leader trait tooltips Issues with the Ship Design and Ship Availability Incorrect linked ship types in the Ship Designer Ships not becoming available to buil
I have a screenshot of this occuring. (had to snip from a video recording...) This is where it is drawing the over-sized tooltip rectangle and subsequently resizes to the appropriate tooltip size. It makes for a very ackward and distracting UI experience. <img src="https://cdn.stardock.us/forums/6/39
After doing a side-by-side compare of the latest v2.7 data files, I cannot see any fixes to the reported bugs in the XML data files. This makes me sad. :(