Jump to content
Sign in to follow this  
Thygrrr

[TOOL] CarrierTools (modding tool inside)

Recommended Posts

Note that many of the '.ent' files (see the 'worlds' directory for example) contain script code as well.

As for the executable, it is extremely easy to find out what code does what. I am, however not sure if BI would be happy if changes are made to it (in the form of 'runtime patches', eg, code injection). I have, for example managed to make walruses turn in place with a simple code patch but I am reluctant to post an executable for it (it doesn't change the actual executable file, the changes are done in memory while the game runs, so the patch would have to be started each time you start the game).

The path finder does a LITTLE better with 'tank-like' rotation but I think the real problem is that BI choose to use A* for this, I think a pathing grid (in 3D, since there are flying units) in combination with a terrain mask texture to determine where a certain action be done and where one can drive/fly would have been much better. Downside is a small performance hit due to the massive amount of grid look-ups one has to do, but since this grid (think of a cube with many cubes within, each a node) isn't drawn and can be 'moved' to the GPU for most processing it could be minimal. Mind you, this is a lot like A* but has everything already set in place and can be used for MANY more purposes. BI's A* implementation in CC is just... awful..

I can sorta live with the walruses getting stuck (the falling off cliffs part, not so much..) but manta's getting stuck on the lip of a mountain, or refusing to go over a mountain even if it already has enough altitude and just starts hovering in place is just BAD.

Maybe recalculating all them nodes every frame is what is really screwing up here, apart from the performance hit, every recalculation of a path or a section of a path could (and often will) result in a whole new path, causing the vehicle to do that 'grandma (or my wife) is trying to park' back and forth crap.

I'll look into it further once I have some time to dissect the executable a bit more.

Gotta say though, nice and clean code guys, well done (seriously).

PS, Thygrrr, I made a native executable based on your depacker, without requiring Python. Also added the ability to select specific files to unpack (or pack back into into the .cc file for that matter). Do you mind if I release that? (You are properly credited of course).

Edited by PureCode

Share this post


Link to post
Share on other sites

You can still use A* and cheat (ish) at the same time. If you know that the AI will alwasy find and take path X from pont A to point B, then preprogram/hard code path X so that units travel faster along that path.

Share this post


Link to post
Share on other sites

That's one of the key problem the current AI might be having. It seems to prefer roads even if there's an open field that'd be easy to navigate for the Walruses.

But I think it's just a case of too low costs for roads in the A* heuristic compared to gently sloping hills and flat fields, and probably no decent explosion of costs when terrain is too steep or has trees, etc. Meaning the costs are probably like 1-2-3 for each of these terrain types, but should be 8-10-OVERNINETHOUSAND or something ;-)

Share this post


Link to post
Share on other sites

Tools updated. Read first post for changed - I added a convenient little batch file to just drag the .cc files onto to unpack them. As long as your environment variabled (namely, PATH) properly points to python.exe in your Python 2.7 install (I think it should by default!), that's all you need to open those PAC1 files.

I also renamed the tool in anticipation of a pack functionality.

Share this post


Link to post
Share on other sites

I have fiddled around a bit, the hierarchy seems to be:

Patch files

Files in the root folder

Main archive files

This means that either we get a packer too or for every mod that uses files in the patch/es we will need to include all files from the patches and of course delete said patches. :/

Edited by Rambo919

Share this post


Link to post
Share on other sites
The path finder does a LITTLE better with 'tank-like' rotation but I think the real problem is that BI choose to use A* for this, I think a pathing grid (in 3D, since there are flying units) in combination with a terrain mask texture to determine where a certain action be done and where one can drive/fly would have been much better. Downside is a small performance hit due to the massive amount of grid look-ups one has to do, but since this grid (think of a cube with many cubes within, each a node) isn't drawn and can be 'moved' to the GPU for most processing it could be minimal.

First of all, there is a "pathing grid" as you call it. It is in fact being used for the walruses. I found no evidence of such a system being used for mantas however, nor would that be necessary.

I don't see GPU doing A* / Dijkstra yielding much in terms of benefit. This isn't massive amounts of floating point or matrix operations we're talking about. Indeed CPU is certainly not the limiting factor for functional pathfinding.

Mind you, this is a lot like A* but has everything already set in place and can be used for MANY more purposes. BI's A* implementation in CC is just... awful..

Did you disassemble the code to arrive at this conclusion? Based on my observation, the actual pathfinding code is fine, it's a combination of walrus vehicle performance and errors in the path data that causes most of the issues.

I can sorta live with the walruses getting stuck (the falling off cliffs part, not so much..) but manta's getting stuck on the lip of a mountain, or refusing to go over a mountain even if it already has enough altitude and just starts hovering in place is just BAD.

Again, I'm fairly certain that there's no pathfinding going on here. Mantas seem to do very basic terrain avoidance, but otherwise they fly straight to the objective. I agree that this terrain avoidance is pretty bad at times, other times it works ok.

Maybe recalculating all them nodes every frame is what is really screwing up here, apart from the performance hit, every recalculation of a path or a section of a path could (and often will) result in a whole new path, causing the vehicle to do that 'grandma (or my wife) is trying to park' back and forth crap.

They only seem to add points when the vehicle is backing up or missing a point, to account for the vehicle turn radius. This is to prevent walruses from driving donuts around a single waypoint. However, the remainder of the route is not recalculated all the time - I can't say this for certain, but I am fairly sure about it. Note that what you see happening on the map is most likely not representative of the actual workings of the pathfinding, as points are not rendered depending on your map zoom level.

Share this post


Link to post
Share on other sites

Nice rebuttal. Nothing to add.

Anyway, update on CarrierTools: Packer should be done tonight (I got time and energy to do it), but don't expect it to work for all mods immediately.

Share this post


Link to post
Share on other sites

The moment you release that packer i will release my performance mod for all you laptop gamers ^^

Share this post


Link to post
Share on other sites
The moment you release that packer i will release my performance mod for all you laptop gamers

What kind of performance? I've been playing on a core2duo, 4gb ram, 9600m gt on low graphics and it's just about playable. I'm interested in anything that will improve it :)

Share this post


Link to post
Share on other sites

I have updated the bitbucket repository. The tool can now pack directories as PAC1 files. However, I have a problem: The game doesn't recognize them, and I don't know where the error lies.

I suspect it may have something to do with the 4 bytes in the HEAD block (address 0x33 to 0x36) that I have just no idea about. The blocks are sufficiently coordinated across the different files, meaning it's unlikely they are some kind of checksum. They also don't appear to be timestamps, though they could be. However, I think they are version codes or something.

14 11 0F 35 (data00.cc)

14 11 0D 02 (data01.cc)

14 11 14 20 (data02.cc)

1B 13 03 28 (patch00.pak)

Any ideas? (The bytes right before these are: 00 DC 07 09 for all files)

---------- Post added at 21:10 ---------- Previous post was at 20:18 ----------

Addendum: When I tag my own repacked data02.cc file with 14 11 14 20, it also doesn't work. So the numbers could be related to the content of the files, OR I have another unknown value that is crucial (checking...).

---------- Post added at 21:27 ---------- Previous post was at 21:10 ----------

Ok, I had a few bugs in the code. Doing more tests.

---------- Post added at 21:41 ---------- Previous post was at 21:27 ----------

I can now run the game with my own repacked data02.cc, but I can't add any files in the form of .pak files yet.

---------- Post added at 22:03 ---------- Previous post was at 21:41 ----------

Trying to run the game with three fully repacked .cc files.

Result: GAME RUNS

(no guarantees for some obscure bugs, but I started a new game and was able to play and drive around in a walrus a little)

Edited by Thygrrr

Share this post


Link to post
Share on other sites

Great, I've been messing about with ai stuff but it does not make any difference in game, even removing stuff does not change anything, I have the right files in the right place because a change to stop intros works, will repacking make everything work?

Share this post


Link to post
Share on other sites

The routines that plan routes, tried changing them, replacing with other commands, even removing, make no difference.

Below is unaltered, I changed it so it can only getnextnode, by removing any getprevnode's, in the hope the walrus would stop messing about, but makes no difference, if there are any syntax errors the game wont start, strange.

RouteNode FindNextNode( RouteNode node, bool fwd )

{

if( RouteHasNames )

{

//!!!!MEGA HACK!!!!

if( !node )

{

node = AssaultRoute.GetFirstNode();

}

string nodeName = node.GetName();

if (fwd) node = node.GetNextNode();

else node = node.GetPrevNode();

if( !node ) return NULL;

nodeName = node.GetName();

while (node)

{

if ( strstr( nodeName,"Regroup" ) >= 0 ) return node;

if ( strstr( nodeName,"Wait" ) >= 0 ) return node;

if ( strstr( nodeName,"End" ) >= 0 ) return node;

if (fwd) node = node.GetNextNode();

else node = node.GetPrevNode();

if (node) nodeName = node.GetName();

}

return NULL;

}

else

{

//TODO: FIND NODE FAR ENOUGH

if (fwd) return node.GetNextNode();

else return node.GetPrevNode();

}

}

Edited by ToxLaximus

Share this post


Link to post
Share on other sites

@Thygrrr

I think 'xob' should be in your DO_NOT_COMPRESS array, too

it looks like the last 7 bytes of the HEAD section are something like a timestamp indeed:

0x30 date (4 bytes):

- year (2 bytes, LE)

- month (1 byte)

- day (1 byte)

some more guessing:

0x34 time (3 bytes):

- hour (1 byte)

- minute (1 byte)

- second (1 byte)

Share this post


Link to post
Share on other sites

You can unpack data2, change stuff pack it up and replace the original data2 with no problems, but I think a lot of stuff is not modable yet?

Share this post


Link to post
Share on other sites

Anyone find the damage radius for the hammerhead? i feel cheated when they explained the hammerhead in campaign but then its like a fart missile on explosion. They made me so pumped only to be bummed out on how crappy it was. I mean at least destroy 80% of the island for Reconstruction....

Share this post


Link to post
Share on other sites
@Thygrrr

it looks like the last 7 bytes of the HEAD section are something like a timestamp indeed:

0x30 date (4 bytes):

- year (2 bytes, LE)

- month (1 byte)

- day (1 byte)

some more guessing:

0x34 time (3 bytes):

- hour (1 byte)

- minute (1 byte)

- second (1 byte)

Omg and there I was going trying all permutations of the values as Unix timestamps ... the endianness on the year confused me I guess. Yeah, maybe that's it! Thanks again, man.

---------- Post added at 06:52 ---------- Previous post was at 06:11 ----------

Tools Updated - Timestamps are now read and written.

---------- Post added at 08:17 ---------- Previous post was at 06:52 ----------

Argh. Captain obvious to the rescue - the .cc files are IFF files. Python has methods to read and write these; so I can make my reader a bit more robust maybe. This will help with the extensibility of the tool kit later.

Edited by Thygrrr

Share this post


Link to post
Share on other sites
The routines that plan routes, tried changing them, replacing with other commands, even removing, make no difference.

Below is unaltered, I changed it so it can only getnextnode, by removing any getprevnode's, in the hope the walrus would stop messing about, but makes no difference, if there are any syntax errors the game wont start, strange.

Here's something to try; put the following code in functions that you want to know is being run:

g_Game.AddMessage("REACHED CODE POINT A", COLOR_RED, LMF_EMPIRE);

This will then pop a message on screen (and in the message log) whenever it reaches that point in code. If it appears, then you know that function is being called. If not, then it's a junk function that's just left over.

Share this post


Link to post
Share on other sites

Ok, so to get a mod to work, I need to repack it in a .pac or the .cc file?

Share this post


Link to post
Share on other sites

Steps to shadow content with a PAC1 file

  • Put all your mod components into a directory named like you want your mod to be named, and then pack that directory using pac1.py or by dragging that directory onto the package.bat that I conveniently include with the CarrierTools.
  • Put the resulting .pak into your Carrier Command directory
  • Open the ccsettings.xml that belongs to your player's profile - this is NOT the one in the Carrier Command directory, it's the one where your save games are.
  • Add the line <path directory="mymodname.pak" /> to the top of the filesystems list, replacing mymodname with the name of your mod, obviously.
  • Launch and enjoy.

This might still fail with patchXX.pak files around, though. Maybe one of you retail/sprocket (non-steam) users can send me your ccsettings.xml and tell me where it was saved so we can complete the documentation on this.

Share this post


Link to post
Share on other sites

ccsettings.xml is located in C:\Users\%user name here%\Documents\CarrierCommand on Windows 7

Who uses the %appdata% folder now a days anyway? (PS: everyone else.....)

Share this post


Link to post
Share on other sites

Wait I don't get it, your program extracts files? How big are the files that can be edited. Can't you compress them and then upload to zippyshare giving a set of modding files?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×