JaiOwl

Ok guys, first; the AI is split across both the XML and lua files, and the XML files within '\Data\Xml\AI\' can be used (however I don't know if they take precindence over the .meg file but I would assume so (I'm not using a Config.meg file anymore)). second; the structure of the AI system In elements such as the campaign files you set the AI player modal using the tags ie. Empire, BasicEmpire The hintset also used by a campaign should be located in '\GalacticMarkup\' and called using the . (I know I've covering the stuff already known) Ok, the sends you to the appropriate file within '\Data\XML\AI\Player\'; in that file your find the lines like : SystemFunctions BasicOffensiveGalacticSet BasicDefensiveGalacticSet BasicInfrastructureGalacticSet BasicInformationGalacticSet BasicOffensiveSpaceSet BasicLandGoalSet SandboxEventsSet The function sets are the files within '\Data\XML\AI\GoalFunctions\' - those are the key systems for get the AI to do things. A entry in a goal function set is an individual is quite simple, I'm unsure how or what calls the individual entries at run-time (I'm assuming its the AI handler script for the AI control player). Example is; Destroy_Unit Unit_Needs_To_Be_Destroyed relates to a entry within one of the '\Data\XML\AI\Goals\' files (not the file but indivual entries within a particular file) which seem to apply restriction rules upon the use of the function. is a direct link to either a script loaded from within a .lua file or a function declared within one of the perception equation files from '\Data\XML\AI\PerceptualEquations\' . Looking at the entries within the files in the '\PerceptualEquations\' folder its clear that they could easily be lua scripts themselves. So notes; the AI doesn't at apear to be hard-coded as the AI can be directly related to the files within '\Data\XML\AI\GoalFunctions\' and the be shown that changes here actually affect the actions of the AI. Inside .lua scripts called will similar names to the ones refered by the goal function entries can be found to have the actual call named referenced inside asif it was a registration header. It isn't clear how the engine knows which xml files to load however it does appear to be clear that if there are parsing errors within the files (like alot of the 1.2 version code has) it won't cause any effect at loading and doesn't seem to cause any direct problems whilst playing except for the obvious unknown resulting AI behaviour from the bad code not being processed. Another note, the building of structures is directly referenced within the perception equations by there actual name however so far any reference I've seen to units has been by their appropriate catergory except for strategic notes used for determining if the enemy has a specific unit like the Death_Star. Hope this helps alittle.

I'm with darth_rann on this one : ??? 'Need your suggestion' .... on what exactly ??

Lol, you cheat ;D Had to do it the long way but did get the benefit that I now know what XML files are actually called by the loader on load, and what gets called during run-time loads for items like campaigns. But yeah, your right no 'DataMinerFiles.xml' .... move along people

Umm.... not sure what you've done exactly but the only way to stop the orginal units from being loaded into the game : 1) Have a file named the same as the original file in the '\XML\' which doesn't have those units in. 2) Remove the entry which calls that particular file within 'GameObjectFiles.xml'. Only only thing I can thing of is ARE YOU SURE those are the original files. We can only help you further if we knew what you did between you last time you had the units, and the time you noticed they were gone, sry.

Just tried an experiment to with a new 'config.meg' file .... :'( It didn't seem to care what I put in the 'DataMinerXmlFiles.xml' .... I'm too tired now to try anything else but I did notice, alot of files ARE NOT called via this so I think it was just a tool used for early development (none of the \AI\ or \ENUM\ folders were referenced at all in it) Still think that Orao has the right idea for overwriting those AI files those. Good luck.

Have you tried repacking it using 'FinalBig' ? It can extract, read, and create .meg files for EaW .... I see where your going with this and I think it might actually work, however you're have to work out which 'config.meg' (there are atleast 2) is actually used for the AI settings just in case its not the one in /GameData/ that is used for those things

Its literally (or would be if the game used it) is the loading protocol for the xml files from its appearance. It would control which xml files would be loaded and parsed by the parser when the game loads and defines how the engine interupts them... like I said very handy. A 'DataMiner' is best described as being much like a big processor used to pass through large archives and extract the data you want. From what I could tell is that it was definately last used near the end of the production as it has testing code in the original cutting out the old campaigns and old object files - however this was before they put some of the more extenable object files link through a 'metafile' (ie. HardPointsFile.xml) And trust me, Choas is right - it ain't being parsed at all as I've put valid stuff in there and it won't work ... I'm hoping there is a way to activate this as it would be guarenteed to be the FIRST xml file parsed on load, and would point to the rest (however seeing it work like that makes it less likely it being activated again outside the embedded code ) Not tried messing with the AI, but tested with 'GameConstants.xml' instead. Edit : Actually Oroa you could be right on with this, thinking about it the loader HAS to load this to know where all the xml files its to load are so if it did use it; then it would only load the one that's in the .meg archive as thats where it would naturally expect to look first for what to load considering the loader DOESN'T check whether a file exists beforing loading this would be a good idea.

I've been playing about alittle today and realised that 'DataMinerXmlFiles.xml' doesn't seemed to be used even though it seems a very useful system Just wondering if anyone has managed to get it working or knows how to get it working ? ... very useful if it can be used, a waste if it can't ???

There might be a simplier solution .... try editing the actual icon image for the symbol making it transparent as I'm assuming that this would only be meant for multiplayer games as the computer AI won't care about a symbol as it looks for smugglers through scripted chances of detection. Can't see symbol on the 'Galactic Map', then they would have to look for your smugglers the long way. Haven't tried it but might work as you want without the 'rewriting the whole engine part'.

Ok, for those who weren't aware- the 'Splash' screen or 'Shell Map' is what everyone is refering to as the background battle you see in the background when in the main-menu. The 'Splash' is actually refered to as the 'Demo_Attract' game which is played between two AI players in a skirmish game. ATM there are three different possible 'Demo_Attract' games playable with the retail version however I already tested the .rec files created automatically when playing a skirmish game and that works (it just isn't in camera mode :'() ... so when Petro fix the camera-recorder and we should be able to have our own battles as the 'Splash' screen ;D. WARNING : Try the other .rec at your own risk, the 'Demo_Attract' .rec don't have maps available in the retail version and trying the 'CAM' .rec caused a unrepairable error (meant unistall and fresh install). YOU HAVE BEEN WARNED! Note: The game searches for the .rec file in '/GameData/Recordings' as the root. Anyway, the lines responsible for the 'Splash' screen are the ones below taken from 'GameConstants.xml' just after the armour and damage settings : However the 'Splash' screen is directly loaded by the line below which is also in 'GameConstants.xml' : To Disable the 'Splash' screen's battle simply comment out those lines or simply turn it off ie. : or The other two available 'Splash' battles available in the retail version can be activated by disabling the original 'Spalsh' screen (like the first disable option) then include one of the below in the .xml (include only one of them at a time). I didn't play with the map_cycle or start_timeout values so if anyone does get the true effects of these then post them but the names really do speak ominously about what they do. Enjoy ... well hopefully after we get a proper camera-recorder anyway Edit : added the 'Shell Map' reference so people understood what this related too (I know I forgot something) and added the 2nd disable option

Unfortunately I don't think you can make specific maps have no fog of war unti lwe get the map editor, I only way I think it could be possible would be to edit a particular object that you can guarentee will be on ONLY the maps you want to get rid of FoW for. This would require the object to be undestroyable, untargetable, and not count towards victory. However the issue is if you choose a map object then how will define who owns the object ? and how will you change it so that changing the object doesn't interfere with the gameplay (ie. make a barrack undestroyable). Disclaimer: I could be wrong ....

The stuuf you want to change are in the 'GroundCompaniesRebel.xml' & 'GroundCompaniesEmpire.xml' and not in the individual units themselves. Have fun.

I don't know about 1.04 being a magic bullet for balancing the game but IMO they will release a patch at the time (whether its the same time or before) as the Mod tools are released as they said they would include a Mod manager for the game which I'm assuming will be a extension for the main menu to switch between installed Mods (which will require a patch on the hard-code) so would be in a patch rather than the tools itself. I do think however feel we won't actually get Mod tools any time soon, its just a feeling but I'm sceptical since Petro have confirmed that they would release Mod Tools but will refer to a Map Editor seperately ... I could be paranoid but they might actually BE seperate and only the map editor will be released any time soon :-\

If your on-about what I think you are, that is that when you build the unit it always starts in the surface slots then just add this line to the actual unit and it'll be placed in a space slot when its built. Yes

Good digging there Prez, nice and simple when we all know how nicely done