Jump to content


Photo

Unofficial, Untested (by PR) BugFixes


49 replies to this topic

#1 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 20 January 2008 - 04:30 AM

In the short time I've been here, I've noticed that there were several bugfixes floating around in various threads. It's great to have your questions answered with possible fixes, but I thought it would also be good for new people (and old ones :) to be able to find all the fixes in one spot. I asked PR if he minded if I compiled them all in one post, and he said go ahead :thumbsupsmiley: so here they are. I'll try to keep this updated with any further fixes. If you know of one I haven't put in here, point it out to me, I'll add it.

These are NOT official bugfixes. Use at your own risk. Or, to quote PR:

Just keep in mind that these fixes are mostly untested (and unsupported) and as such, I would appreciate feedback on them to know if they work as they should. Also, using them will cause synchronization problems for you in multiplayer unless you backup or reinstall, so just remember that.

Now, on to the fixes :xcahik_:

Missing Strike Cruiser

The option to reasearch the strike cruiser never came up in my game. I have finished all other tech upgrades, and no sign of that beautiful beast.

I'm no pro, and all that XML makes my eyes bleed, but I think I found the fix (based on looking at other code segments).

In Tech_Tree_Empire.xml, the entry looks like this:

<!-- Super VIII Transport Bulk Cruiser / Super VIII Transport Escort Carrier -->    <Event Name="Unlock_Super_Transport_VIII_Bulk_Cruiser">        <Event_Type>STORY_CONSTRUCT</Event_Type>        <Event_Param1>E_Super_Transport_VIII_Bulk_Cruiser_Research</Event_Param1>        <Event_Param2>1</Event_Param2>        <Event_Param3>FILTER_FRIENDLY_ONLY</Event_Param3>        <Prereq>Unlock_Immobilizer_418_Cruiser</Prereq>    </Event>

The entry is missing the reward parameter that chains to the next ship tech. I believe it should be like this:
<!-- Super VIII Transport Bulk Cruiser / Super VIII Transport Escort Carrier -->    <Event Name="Unlock_Super_Transport_VIII_Bulk_Cruiser">        <Event_Type>STORY_CONSTRUCT</Event_Type>        <Event_Param1>E_Super_Transport_VIII_Bulk_Cruiser_Research</Event_Param1>        <Event_Param2>1</Event_Param2>        <Event_Param3>FILTER_FRIENDLY_ONLY</Event_Param3>        <Reward_Type>BUILDABLE_UNIT</Reward_Type>        <Reward_Param1>E_Strike-class_Medium_Cruiser_Research</Reward_Param1>        <Prereq>Unlock_Immobilizer_418_Cruiser</Prereq>   </Event>


AI Not Upgrading Starbases

In BasicInfrastructureGalacticSet.xml change the following:

<DevelopStarbase>        <Goal>Upgrade_Starbase</Goal>        <Function>ReallyBig</Function>    </DevelopStarbase>


Planets too close together

Alternatively, you can change the camera. This can actually be done rather easily if you know where to look. In GameConstants.xml, find the <GMC_InitialPullbackDistance> tag. Its value is currently 750.0, but making it smaller will cause it to zoom in and make the planets larger. However, if you change it this way, you will be unable to connect to other players in multiplayer, so make a backup, or better yet, a different copy of the mod.


Two possible fixes for lag. First if you think it's because the AI is moving units around too much

I think I found the script that controls how often the AI shifts around units. It's GalacticFreeStore.lua. I've halved the service rate and hopefully that will help with some of the lagging, but I haven't had much time to test it and realistically won't, at least not comprehensively. If any of you want to mod it into your copy (just change both of the 8s at the top to 4s) and see what happens, I'd appreciate it. Of course, the usual warnings about multiplayer synchronization.

The file can be found here.

Second lag issue, if you think it's the AI in general

I don't know. At this point, I'm out of ideas. You could turn the AI players off, but then they would do nothing. Maybe try turning just the CSA off? I don't like the compromise, but it might help. In Campaigns_PR.xml, replace this line:

<AI_Player_Control> Corporate_Sector_Authority, BasicEmpire </AI_Player_Control>
with this:
<AI_Player_Control> Corporate_Sector_Authority, None </AI_Player_Control>
There should be two occurances because there is a Rebel and Imperial version of each campaign. Let me know what that does.


Next is a problem with fighters hunting or scouting

1) what is up with the computer setting all ships to "hunt" mode shortly after the battle begins.. this include his bombers and his fighter cover.. which leaves him at a serious disadvantage.. his cap ships are completely open to bombers and my cap ships need NO fighter cover as his bombers are aimlessly flying around the map after the initial opening volleys (he leaves them together for 1 or 2 passes then sets to "hunt") is it possible to disable the computer from useing this feature to force him to keep them in formation? or perhapes make fighter spawns "defend" the cap ship they spawm from? (I do that if I am not altering the fleets position.. enemy fighters/bombers that come near get engaged.. cap ships that get to near find a few extra bombing runs ) It is also annoying since the computer will not retreat if he has alot of fighters roaming the map.. which forces you to try and hunt them down.. he once had enough fighters and bombers roaming the map that he could have wiped my fleet.. but he left them just roaming.. they weren't even engageing the cap ships when they found them.. just make one pass and contuine the roam

The fix

Fighters roaming all over the map is usually a consequence of the scout function and not the hunt ability. Do a test: open ...\data\xml\ai\goalfunction\BasicOffensiveSpaceSet.xml. Do the following change and look what happens:

<Space_Scout>
<Goal>Space_Scout</Goal>
<Function>Zero</Function>
</Space_Scout>

Do that only if you don't want to play multiplayer or make a seperate install for testing! The AI should no longer waste his units flying all over the map. I never understood what scouting does for the AI anyway.

That file can be found here

The file for this next one can be found in the scripts/AI directory (I had to look it up, so I thought I'd share)

Here's another excellent suggestion by Zarkis, to reduce AI raid-spam in the GFFA campaign. Supposedly it will cause the AI to take some time to defend it's newly acquired planet, before releasing the ground forces to be used elsewhere (on another raid, no doubt). Note that the order of two of the lines is reversed when the sleep command is placed between (you will see what I mean when you open the lua file)

Found on the third page of this thread.

Here you go: Open conquerpirateplan.lua with an editor, find the block below, and add the line written in bold. You can vary the timer after sleep to whatever length you find convenient, so 60 is just a guess for a good length on my side.

sleep(60)
MainForce.Release_Forces(1.0)

ScriptExit() _linenums:0'>LandSecured = true FundBases(PlayerObject, Target) <strong class='bbc'>sleep(60)</strong> MainForce.Release_Forces(1.0) ScriptExit()


Hopefully, here's a fix for Bombing runs causing exceptions

PR, your idea about the AI using their broken bombers is interesting. Have you identified which bombers on each side are broken?

If I'm correct, it's the Skipray and the ATR, which aren't even bombers.

If you have, is there a simple way to disable them in the XML?

I think so, but I actually need someone to test it. I had assumed that <Is_Bomber> would control whether or not a unit was able to do bombing runs. However, the fact that it's giving exceptions leads me to believe that <Ship_Class> actually controls this. You'll have to go in the XMLs for these two ships and change <Ship_Class> to Fighter and see if that fixes it. However, there may be more than one thing causing exceptions; I don't know.


For those having problems with the MC80 Reef Home, hopefully this will fix it:

Tech_Tree_Rebel.xml:

<Event Name="Research_Reef_Home-class_MC80_Star_Cruiser">
		<Event_Type>STORY_TRIGGER</Event_Type>
		<Reward_Type>BUILDABLE_UNIT</Reward_Type>
		<Reward_Param1>R_Reef_Home-class_MC80a_Star_Cruiser_Upgrade</Reward_Param1>
		<Prereq>Unlock_Republic-class_Star_Destroyer</Prereq>
	  </Event>

I believe it should be:
<Event Name="Research_Reef_Home-class_MC80_Star_Cruiser">
		<Event_Type>STORY_TRIGGER</Event_Type>
		<Reward_Type>BUILDABLE_UNIT</Reward_Type>
		<Reward_Param1>R_Reef_Home-class_MC80a_Star_Cruiser_Upgrade</Reward_Param1>
		<Prereq>Unlock_Reef_Home-class_MC80_Star_Cruiser</Prereq>
	  </Event>
The Repub SD shouldn't be appearing here. Simple copy/paste error I believe.

I'm not entirely sure that this explains the problem we're seeing... Maybe. I haven't played a rebel side campaign other than Thrawn's yet, so I haven't had the reef home problem personally.


'AI retreats too easily' fix:

SpaceUnitsUtilities_CT-11_Space_Tug.xml:

<CategoryMask> Transport </CategoryMask>
change it to:
<CategoryMask> fighter </CategoryMask>

Your AI will no longer retreat too easily as defender whenever large Starbases are present.

The problem was that starbases were spawning up to 5 squads of 12 tugs each, and 60 tugs were causing the AI to retreat to 'save the transports'. This is smart behavior when those 60 transports are carrying 60 teams of AT-AT's. Not so smart when they are base-defense tugs.


Two more fixes for everyone: If you are having problems with the AI (not the not working variety, but you just don't like it) go here. Zarkis has made some great strides in making the AI better. Also, if you think the turbolaser, ion cannon, etc graphics are blah, go here. Dal MP is doing great work on the graphics side of things.

We have a fix for Talay! Thanks Kitkun!

Well, I've not seen a fix for Talay (Not being able to fight in space, have to auto resolve) posted, so here it is:
In planets.xml, change
<Space_Tactical_Map>_Space_Planet_MonCalimari_01.ted</Space_Tactical_Map>
to
<Space_Tactical_Map>_Space_Planet_MonCalamari_01.ted</Space_Tactical_Map>
Just a spelling error.
Note: Do NOT change the land map name, that works fine.


Error where TIE Avenger x8's don't have their light laser.

The fix
Open the file

\Mods\Phoenix_Rising_Space\Data\XML\SpaceUnitsFighters_TIE_Avenger.xml

find the entry (in red)
- <SpaceUnit Name="TIE_Avenger_x8">
  <Variant_Of_Existing_Type>TIE_Avenger_x7</Variant_Of_Existing_Type> 
  <Text_ID>TEXT_UNIT_TIE_AVENGER_X8</Text_ID> 
  <Encyclopedia_Text>TEXT_UNIT_TIE_AVENGER_X8_TOOLTIP</Encyclopedia_Text> 
  <Max_Speed>8.4</Max_Speed> 
  <Min_Speed>4.2</Min_Speed> 
  <Shield_Points>200</Shield_Points> 
  <Damage>22</Damage> 
  <HardPoints>[color="#FF0000"]HP_TIE_Avenger_x7_LL[/color], HP_TIE_Avenger_x7_LACM</HardPoints> 
  </SpaceUnit>


and change it to the following
[color="#FF0000"]HP_TIE_Avenger_x8_LL[/color]


If anyone knows how I can clean up the presentation a bit, please let me know! I've tried the hide tags, but they just don't work like they are supposed to :thumbsdownsmiley:

Edited by hetter71, 17 May 2008 - 04:25 AM.


#2 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 20 January 2008 - 04:31 AM

Reserved

#3 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 20 January 2008 - 04:31 AM

And Reserved (just in case I run out of room with the first two)

#4 Dalmp

Dalmp
  • Project Team
  • 249 posts

Posted 20 January 2008 - 08:32 AM

Fantastic idea hetter! Thanks a ton, I was looking for the fighter scouting fix. :thumbsdownsmiley:

Here's another excellent suggestion by Zarkis, to reduce AI raid-spam in the GFFA campaign. Supposedly it will cause the AI to take some time to defend it's newly acquired planet, before releasing the ground forces to be used elsewhere (on another raid, no doubt). Note that the order of two of the lines is reversed when the sleep command is placed between (you will see what I mean when you open the lua file)

Found on the third page of this thread.

Here you go: Open conquerpirateplan.lua with an editor, find the block below, and add the line written in bold. You can vary the timer after sleep to whatever length you find convenient, so 60 is just a guess for a good length on my side.

sleep(60)
MainForce.Release_Forces(1.0)

ScriptExit() _linenums:0'>LandSecured = true FundBases(PlayerObject, Target) <strong class='bbc'>sleep(60)</strong> MainForce.Release_Forces(1.0) ScriptExit()


Edited by Dalmp, 20 January 2008 - 12:53 PM.

Amateurs study Tactics. Professionals study Logistics.
-Napoleon

Posted Image


#5 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 20 January 2008 - 03:45 PM

Fantastic idea hetter! Thanks a ton, I was looking for the fighter scouting fix. :thumbsdownsmiley:

I'm glad someone has found use for it already :xcahik_:

Fix added :thumbsupsmiley:

#6 anakinskysolo

anakinskysolo

    Phoenix Rising Fan

  • Members
  • 490 posts
  • Location:Chile

Posted 20 January 2008 - 03:50 PM

I can't open the .lua files. Do you need a special software?

#7 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 20 January 2008 - 03:54 PM

I can't open the .lua files. Do you need a special software?

Notepad will open it. From notepad, not from explorer.

#8 Phoenix Rising

Phoenix Rising

    Beyond the Impossible

  • Petrolution Staff
  • 6,509 posts
  • Projects:Phoenix Rising
  •  Mod Leader
  • Division:Petrolution
  • Job:Mod Specialist

Posted 20 January 2008 - 10:15 PM

Thanks much, Hetter. Just keep in mind that these fixes are mostly untested (and unsupported) and as such, I would appreciate feedback on them to know if they work as they should. Also, using them will cause synchronization problems for you in multiplayer unless you backup or reinstall, so just remember that.

#9 Phoenix Rising

Phoenix Rising

    Beyond the Impossible

  • Petrolution Staff
  • 6,509 posts
  • Projects:Phoenix Rising
  •  Mod Leader
  • Division:Petrolution
  • Job:Mod Specialist

Posted 20 January 2008 - 10:18 PM

Don't forget the bombing run exception fix (I hope).

#10 anakinskysolo

anakinskysolo

    Phoenix Rising Fan

  • Members
  • 490 posts
  • Location:Chile

Posted 20 January 2008 - 11:53 PM

The file for this next one can be found in the scripts/AI directory (I had to look it up, so I thought I'd share)

Here's another excellent suggestion by Zarkis, to reduce AI raid-spam in the GFFA campaign. Supposedly it will cause the AI to take some time to defend it's newly acquired planet, before releasing the ground forces to be used elsewhere (on another raid, no doubt). Note that the order of two of the lines is reversed when the sleep command is placed between (you will see what I mean when you open the lua file)

Found on the third page of this thread.

Here you go: Open conquerpirateplan.lua with an editor, find the block below, and add the line written in bold. You can vary the timer after sleep to whatever length you find convenient, so 60 is just a guess for a good length on my side.

sleep(60)
MainForce.Release_Forces(1.0)

ScriptExit() _linenums:0'>LandSecured = true FundBases(PlayerObject, Target) <strong class='bbc'>sleep(60)</strong> MainForce.Release_Forces(1.0) ScriptExit()


If anyone knows how I can clean up the presentation a bit, please let me know!



The file that I have puts the phrases the other way around, with fundbases after mainforce.

#11 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 21 January 2008 - 02:57 AM

Don't forget the bombing run exception fix (I hope).


Added

#12 Zarkis

Zarkis
  • Members
  • 70 posts

Posted 21 January 2008 - 07:18 AM

The file that I have puts the phrases the other way around, with fundbases after mainforce.


Change it as shown in the example, so the task force waits while the first structures are created. I forgot that I changed the lines when I wrote down that example.

Edited by Zarkis, 21 January 2008 - 07:19 AM.


#13 muneyoshi

muneyoshi
  • Members
  • 196 posts

Posted 21 January 2008 - 04:21 PM

the missing strike crusier.. I can't find the file Tech_Tree_Empire.xml.. I did a search on my comp and said it's not found

#14 Phoenix Rising

Phoenix Rising

    Beyond the Impossible

  • Petrolution Staff
  • 6,509 posts
  • Projects:Phoenix Rising
  •  Mod Leader
  • Division:Petrolution
  • Job:Mod Specialist

Posted 21 January 2008 - 07:29 PM

It's definitely Tech_Tree_Empire.xml under the XML folder, so I don't know what to tell you. If you didn't have it, none of your tech would work :p.

#15 muneyoshi

muneyoshi
  • Members
  • 196 posts

Posted 21 January 2008 - 10:50 PM

It's definitely Tech_Tree_Empire.xml under the XML folder, so I don't know what to tell you. If you didn't have it, none of your tech would work :p.


lol.. yeah.. it's weird.. even a "search" on my comp doesn't turn it up.. but when I played as the empire I was able to do research and tech upgrades... weird

#16 Dalmp

Dalmp
  • Project Team
  • 249 posts

Posted 21 January 2008 - 11:48 PM

Feedback: Scouting fix definitely works. And what a difference. I actually fear those bloody B-wings now hehe. Also, the AI is definitely upgrading those starbases - I tend to find them at top size when I come calling, complete with Golan's for defense.

I haven't had any issues with any of these fixes thusfar, and I'm running all of them except for the bombing run fix (I haven't ever had a bombing run issue, so I'll wait until I see it before I try the fix).

Edited by Dalmp, 22 January 2008 - 12:29 AM.

Amateurs study Tactics. Professionals study Logistics.
-Napoleon

Posted Image


#17 muneyoshi

muneyoshi
  • Members
  • 196 posts

Posted 23 January 2008 - 10:43 PM

It's definitely Tech_Tree_Empire.xml under the XML folder, so I don't know what to tell you. If you didn't have it, none of your tech would work :thumbsupsmiley:.


lol.. yeah.. it's weird.. even a "search" on my comp doesn't turn it up.. but when I played as the empire I was able to do research and tech upgrades... weird


so weird.. found the file.. apperantly the file itself to the search engine is JUST Tech_Tree_Empire .... .xml is not an offical part of the file name apperantly and therefor it did not find it.. lol.. stupid Microsoft

#18 hetter71

hetter71
  • Members
  • 33 posts
  • Location:Crazyville

Posted 26 January 2008 - 04:45 PM

Added MC80 Reef Home fix

#19 Phoenix Rising

Phoenix Rising

    Beyond the Impossible

  • Petrolution Staff
  • 6,509 posts
  • Projects:Phoenix Rising
  •  Mod Leader
  • Division:Petrolution
  • Job:Mod Specialist

Posted 27 January 2008 - 09:13 PM

Feedback: Scouting fix definitely works. And what a difference. I actually fear those bloody B-wings now hehe.

Yeah, it's like night and day with starfighters.

so weird.. found the file.. apperantly the file itself to the search engine is JUST Tech_Tree_Empire .... .xml is not an offical part of the file name apperantly and therefor it did not find it.. lol.. stupid Microsoft

Figures :sad:.

#20 IcySmoke

IcySmoke
  • New Members
  • 1 posts

Posted 01 February 2008 - 04:17 AM

The fixes for Reef Home and Strike class worked for me but for the bombing run exception fix when you change Bomber to fighter does it matter if I use caps or not because in some files Bomber is Capitalized while fighter is not. Like in the X-wing file it's <Ship_Class>fighter</Ship_Class> while in the skipray it's <Ship_Class>Bomber</Ship_Class>. Sorry if that is a stupid question but thought that was odd.

Edited by IcySmoke, 01 February 2008 - 09:53 AM.




Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users