Thygrrr

It's pretty much what I expected - fake patch mods would be possible this way. Steam users are now out of luck... I tried wildcards in the settings dir; didn't work. ---------- Post added at 21:23 ---------- Previous post was at 21:19 ---------- Try the following please: name the file patch66.pak and see what happens name the file patchMyMod.pak and see what happens If we're lucky, the code that reads these files doesn't use a sequential enumeration that stops at the first nonexistent file, but some glob like patch*.pak or patch??.pak :-)

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.

More Command Line Params -player me|neutral|enemy (yes, you can play as green or red! but it doesn't *really* work, lol) -nowaitres 1 -campaign ---------- Post added at 17:02 ---------- Previous post was at 16:28 ---------- Main Entry Point The main entry point is in script.c (I wasn't exactly sure, but it's there). That means to write a total conversion, you only need to exchange that file and you can rewrite almost your entire game logic from there (I might be talking out of my ass but it seems to be this way). EDIT: Maybe not. I'm trying to build a "minimal mod", basically a hello world. It dies when it tries to set up some part of the physics system. Other required files to run the game barebones are: ---------- Post added at 17:09 ---------- Previous post was at 17:02 ---------- Command Line Parameters in scripts The int main(string cliparams) function in script.c seems to get the carrier.exe's command line parameters. ---------- Post added at 17:17 ---------- Previous post was at 17:09 ---------- File Access API There's a complete file access API in proto.h, meaning you can parse stuff like your own custom island layouts and missions. This is very powerful. One could make a mod launcher with this. Console Logging proto void Print(void var); as specified in proto.h, no fricken clue where this is logging to, though. Netstat doesn't show any open ports so it's not logging to a debug monitor port or something. ---------- Post added at 19:06 ---------- Previous post was at 17:17 ---------- Dynamic Binding / Function Calls Call(this, funcName, param); ---------- Post added at 19:07 ---------- Previous post was at 19:06 ---------- I am starting to wonder why they had to put so much into the native code. This engine can do pretty much anything script side! ---------- Post added at 19:12 ---------- Previous post was at 19:07 ---------- Goofed Up Polymorphism //! Determine if unit is manta proto native bool IsManta(); //! Determine if unit is walrus proto native bool IsWalrus(); //! Determine if unit is turret proto native bool IsTurret(); Too bad the scripters for some reason couldn't use the engine's powerful OO capabilities to prevent such bollocks. ---------- Post added at 19:40 ---------- Previous post was at 19:12 ---------- Preprocessor The scripting language has a macro preprocessor. Not sure how powerful it is. However, one can define symbols like this (for example at the start of script.c) #define DEVELOPER 1 (this actually enables a shitload of developer options. still trying to figure out where all the logging happens.) However, it does seem like DEVELOPER has to be defined in every file you want it defined (I guess it's related to the interactive designer outlined below) ---------- Post added at 19:49 ---------- Previous post was at 19:40 ---------- Interactive Designer Tool The Enforce engine SDK probably ships with an interactive editor, for which all the AddDesignerCheat(...) functions are. I'd love to get my hands on an Enforce SDK. Probably no good without the native codebase of Carrier Command, though. ---------- Post added at 20:04 ---------- Previous post was at 19:49 ---------- Log Files Log Files are written into your steam profile. <Steam Installation Path>\Steam\userdata\<your user id number>\65740\local This is also where your savegames end up I guess. The (borked) video encoder in the game puts its video files there, as well. ---------- Post added at 20:29 ---------- Previous post was at 20:04 ---------- Profile-Based ccsettings.xml Important tidbit: The ccsettings.xml in the Steam Carrier Command directory is merely a template. The actual used one is in your profile directory! I can now mount arbitrary .pak files at load time. However, it doesn't shadow any existing files, no matter which way around I do it. (strange!). So maybe there is still an issue with the file. Maybe (!) chunk alignment, I'll try that. ---------- Post added at 21:03 ---------- Previous post was at 20:29 ---------- Shadowing content with PAK files Okay, I figured it out. I skipped a byte in my pac1.py tool and the Enforce engine couldn't handle the smaller chunk (even though it wasn't malformed). Additionally, I was using the wrong settings file. STEAM ONLY: Steps to shadow content with a PAC1 file (use the latest version of CarrierTools!!!) 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.

Don't know. Yet. Still experimenting.

Love these! :-)

That said, all my contributions to Carrier Command are public domain / property of BI where applicable, so they can do with it all what they want. I also don't expect them to do anything with it, though. Too risky, also legally (imagine some modder puts in a backdoor...)

Not yet. ---------- Post added at 10:10 ---------- Previous post was at 09:31 ---------- -load takes a savegame as argument.

Yeah, of course. And that's also why I'm waiting for at least one patch. The code will need a LOT of refactoring anyway, and I expect BI to do some of it because I can't see them maintaining the current code they shipped in the messy condition it's in. So tonight I'll probably check everything into a mercurial repository on my home server so I can, for every patch, see exactly what changed where (down to every single number in every .ENT file for the worlds and every single pixel in a .DDS file, and every line in every script). It's not that hard to update mods if you have the means to do that. I am also looking forward to how BI is going to implement mod support on their side, because currently I am looking for a backdoor to load custom content without shadowing files using directories.

carrier.exe The executable file supports the following command line switches (there may be more, especially implicit arguments without switches): -nosplash -load -client -server I have no clue about the syntax. The game doesn't properly launch as -client or as -server; -nosplash works as expected. ---------- Post added at 09:01 ---------- Previous post was at 08:58 ---------- Shadowing content with PAK files On steam, the following techniques do NOT result in successfully modifying the game. adding a patch00.pak with custom content, with or without mentioning it first in settings.xml (first or last) adding a mymod.pak with custom content, with or without mentioning it first in settings.xml (first or last) adding a data03.cc, with or without mentioning it first in settings.xml (first or last) creating a new data02.cc with changed files from data00.cc and data01.cc There may be some command line option necessary to get it to work. Kudos to whoever finds the solution first.

We at the CCGM forums would GREATLY appreciate a modding sub forum for Carrier Command (and all relevant threads moved there). Would that be possible? We'd love you for it!

No, instead of waiting, I'm making the big mod (no guarantees it'll get done, I have exactly zero lines of production code done so far - still experimenting :))

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.

Removing what?

File packer is working, but I have not been able to get additional PAC1 files to work in my game (Steam version) yet. Also, I'm currently writing a bogus number into the file header because there are 4 bytes I have no idea about. The game runs after I unpack and re-pack all the big original files, so my tool can't be all wrong.

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)

Just so it doesn't get lost - there's a floating door in the sky over Somnus. :-) Must be a misplaced prefab.

Nice!

You don't need SDKs when you can make one yourself. The game is very moddable, and I created a very simple tool that unpacks the files. (and I am extending it tonight so people can pack their mods into single files, as so-called fake patches, making mod distribution a bit easier). I might write a tool to process navspaces files next. But I am more keen on providing some great template classes to make UI modding easier (the current scripts directory is such a mess... the Enforce engine is one of the most nicely moddable things I've seen in ages, and somehow the dirty code that has grown over several bouts of crunch time for this project seems to spoil it all). Come to think of it, I can't find a place where to license the Engine. It's almost as hard to find stuff online for it as for RenderWare. I waited 20-some years for this game, and once even commenced to make a remake myself (but abandoned the idea for lack of time). Damn straight I'm motivated! Especially with such a great foundation to work on.

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.

I'm working on the PAC1 packer. No ETA, but ideally done tonight.

Yes I'm starting to figure most of it out now. About fixing the code - the more I look at it, I think I'll make a cleaned up version of the game's script code that only shadows "script.c". That would make for a much cleaner code base. The current script code is a complete dependency hell, and has so many unrelated things bunched into the same files. The problem is, it requirea touching / refactoring almost every file in the scripts folder. Another issue is (of course) the code base being improved / fixed by Bohemia Interactive guys themselves over the next months. I'll create a private repo somewhere so I can track their script changes. That said, there are silver linings, such as the strategy pattern being used extensively for unit actions (like the Manta Dogfight Motions). That'll be easy to extend and improve. Also, some sections have good comments and a fairly clean code style. Others - not so much... I can imagine an intermediate step (so one can release early, release often), but in the long run, I want to use this cool engine to make a really cool mod unencumbered by chaotic code that's partially documented in Czech. :cool: I'm not entirely sure how much is really scripted in /scripts. So my idea might get shot down by reality even before it can fail to fly.

You can try to unpack the patch file, and then copy the mod over it.

It's theoretically possible in a mod. The game currently doesn't offer this kind of game play.

UI Modding UI Scripting is actually *quite* possible already, including proper Observer Pattern / Event Handling and loading custom UI from UI files. I'll post a short example in a little bit. ---------- Post added at 11:16 ---------- Previous post was at 11:08 ---------- Addendum: We could actually create a UI registry that would allow mod plugins that are cross compatible (as long as they focus on UI elements or adhere to a standard). The actual use of this might be limited, but it'd potentially alleviate the problem that all mods are mutually exclusive at the time.

Come to think of it, three carriers would be awesome. e.g. Red, Blue, Yellow.