nww02

100% Totally agree. It's not the devs' fault though. They've done a good job so far, but ran out of time due to the self-imposed 'ship date' from the producer. They just need to just fix the AI for now. Concentrate on all the other good stuff later, just fix the AI, drop the price, and get the console port out, so that the home gamers are appeased and the metacritic scores and revenue can start to come back. THEN do some modding tools for the PC. Once they're out, the fan community can get its teeth into the game, and raise it to a cult status. There'll be mods, TC's, new maps.. But the faith just needs to come back into the game first. Just my 2c, though..

I've been waiting 20 years for someone to remake Carrier Command. I'm prepared to wait another month or two for the fixes and strategy to happen. Here's an educated guess as to what I think is happening: The poor reviews and sales are making the number crunchers unhappy. The "quick win" which CCGM promised hasn't materialised, and a nice little earner they thought they could use to fuel some of their more mainstream products hasn't delivered. The desire not to throw good money after bad is high, and with all-hands-on-deck needed for other projects, the management have been pressured to relocate the dev team. I'd be surprised if there was more than one or two devs left actively working on this now. They are trying to clean up the script files, make the modding tools community friendly, while simultaneously trying to write some documentation, and keep the project managers off their backs long enough to get the truly necessary patches out there. They have no community-interaction backup, so have to spend any spare time they have to check these forums and reply to us being all bitchy at them. It's just a matter of time before a manager at BI decides that CC:GM has taken enough money out of the pot, and needs to be shut down. So, let's give whoever is still working on this game some time. Once they've tidied up the script files, written up some docs, and got a modding environment they're happy to unleash on us, we can get stuck in again. Until then, I guess we just have to chat about how awesome it'll be once the bugs are squished. To The Devs working on CC:GM, a short message:

Hi Natey, Save game files are usually reliant on version because there may be patches and new objects in later versions. imagine if BIS put in a new upgrade for the walrus in 1.03, and you tried to downgrade to 1.02. what would the inventory screen show for the now non-existent upgrade? On the other hand, if it's *still* crashing after you uninstall and re-install the release version, then you may have an incompatibility issue. i suggest you look through all the things you've installed since CCGM, and if you come across anything which stands out, include a save game and your crash log, and log it at the issue tracking site instead of on here. The devs will be grateful for a save file they can load and trace through to crashing. I feel your pain on this. (luckily?) I, myself joined at the P&C stage so didn't pay top dollar, but if I'd shelled out £40 for this game, I'd be a bit miffed too. I have faith, though, that BIS will work at the issues until CCGM is the game it was always meant to be. It'll have to take a few price point reductions though, and it'll have to be damn soon to improve the metacritic scores before christmas. Stay sane, and keep posting the crash reports (on the issue logging site). It sounds like you're the motivated kind of person who can really help to turn issues round by digging until a problem is solved.

Dajunka's right. It's called a Beta patch for a reason. It *is* disappointing that more and more producers are strong-arming dev teams into releasing unready code, but BIS are one of the few studios with a conscience, and will actively fix those issues. I absolutely adore this game, but I've shelved it until the AI is patched. I check back here every so often, but I advise that you do the same, or you'll just beat your head against it until you are sick of it. Go play something else. ARMA II is good fun ;-)

The high-level pathfinding code in the script files is high-level, and there's not a lot wrong with it, except that it's a bit 'blunt'. The actual stuff that translates that into "move x units east..." is inside the main code, and imho, that is the part which needs the work. The only top-level scripty bit which I'd like to see them muck with (with regards to walrus pathfinding) is where it's trying to back-out of a corner, and it just starts randomly choosing forwards, or backwards, and side-to-side.. That needs to be a bit more heuristic and communicative with other units. Just my 2c though.

Dear Devs: When the pathfinding finds that a route (which was available) is now blocked, and that the item that is blocking the path is a friendly walrus, could you please try to implement one of the two following strategies. * rock-paper-scissors (winner gets to move for the next 5 seconds. Loser must stay still). * back-off (both walrii choose to move a small distance in a direction more than 45 degrees away from the blocker), then play rock-paper-scissors. At the moment, the two just seem to do a merry dance and get in each others' way, so I hope that something like the above might cure the issue :) Something co-operative, anyway.

Depending on what the enemy carrier was doing at the time, it /should/ launch all units. The AI files are clearest about what the tactics should be when attacking an island and suddenly you turn up.... drop everything and attack, unless it's "Panicking" (a state set by some internal process), in which case, run away. Pretty much any "subunit container" (i.e. carrier and islands) has the same tactic. The only reasons why it /wouldn't launch all units are because: * It doesn't have any units to launch (maybe it abandoned them when fleeing?) * The code to harvest the list of enemy objects within telemetry range is broken in some way - I was wondering about what it would do if attacking an enemy island - Do the island's defenders (which are also enemy units from the AI's perspective) add to the list of objects in the list? In which case, the enemy carrier is always HOPELESSLY outnumbered when it meets you at one of your own islands, hence the reason it might be panicking and running away?... Just a thought... So perhaps the cases where it stays and fights are because it's already wiped out the defender units, so it can meet you on a more level playing field? Who knows. If I could get up a debug console, I could print the number of enemies in the Object[] enemies array. ho hum.. Just have to wait, I guess.

That's a fairly standard practice. you'll see a lot of games do that, especially multiplayer games. It'll look like everyone just jumped at once. It's because the models could get stuck in the ground if there's a slope. So, to be safe, they add the models a teensy-bit high, to remove any chance of it. Play some quake or UT, and you'll see the models dropped in behind a shimmer which disguises it.

The first rule of mod club, therefore, is to wait for the bleeping API to be released ;-) The second rule is to obey orders given by human beings, except where such orders would conflict with the First Rule. I think the third rule is something about not eating Pot Noodles... May be wrong on that one though.

The hardest part of it is that we want to mod the AI for pathfinding, but the "level 2" pathfinder, the solver for navigating around terrain obstacles, isn't in the Enforce script - it's buried in the main code. If you trace the carrier.exe using a debugger, you can see where it calls an ai routine by attaching a behaviour class to the Parent scriptable object. I've tried to override the inner-core scripting, by creating partial classes in ailib.h and modifying the function bodies in the hope that the dynamic loading would overlay them on top of the core functions:- class DefaultMotionDataBatch { proto native void ClearBehaviour(); proto native void AddBehaviour(int iBehaviour); proto native void UsePath(bool bShouldUsePath); proto native void SetSpeed(float fSpeed); proto native void SetFaceTarget(vector vTarget); proto native void SetOrientation(vector vOri); proto native void SetPoint(vector vPoint); proto native vector GetAnchor(); proto native bool WasHit(); } class AssistAction { void AssistWalrus(DefaultMotionDataBatch b, float f) { //.. do nothing; } } class FormationSlot { proto native vector GetPosition(); } class SquadHandler extends MultiObjectHandler . . . But none of it has any effect. CCGM is compeletely happy with having the classes and prototypes added there, but whenever I try to override them, not a jot happens. So, I'm going to give up trying to tinker with it until :- * An Enforce3.pdb is distributed which matches the enforce3.dll * Some kind of hint about how to tinker with the scripting is given out... perhaps a class tree, callback list, or whatever. * A way to bring up a debug console or something is given... It'd also be nice if someone was to re-organise the scripts, and perhaps put in more comments, cos they need a jolly good tidy. I'd offer to do it, but with a potential patch coming, it'd be a bit of a waste of time, my changes'd get overwritten. Don't feel too bad, though H4mster... It's a damn good scripting language, but with no manual, we're kind of punching fog here..

hmm. That's curious. Do you have the armour in storage, or on the stockpile island, perhaps? (grasping at straws here). I don't think anyone's reported problems with getting armour onto an empty manta before... Perhaps it's a bug? Post a screenshot showing the armour in stock on your carrier, and attempting to load it onto the manta.. If it looks like a bug, may be worth submitting!

is the manta carrying anything else, a weapon, or addition which can't be mounted on an armoured Manta?

It's in data02.cc\scripts\ai\carriertactics.h in the CarrierDefenseTactic class. There's a similar set of functions in the CarrierOffenseTactic, and the Island*Tactics... Which basically means that the standard AI response to any situation is "Launch as many things as are needed to match how many things the opponent has launched". :-/ I have a feeling that'll change in the next patch, although "Tit-for-tat" is generally a good tactic, it makes things easy for the player to predict.

To my (untrained) eye, it looks like the decision to launch units is controlled by this function bool Offer( ObjectHandlerBase object ) { //STUB: accept anything if there is more enemies than controlled units int need = EstimateUnitNeed( AI_GENERAL ); if( need > 0 ) return true; return false; } int EstimateUnitNeed( int type ) { //STUB: do not care about type return EnemyCnt - ManagedObjectCnt; } EnemyCnt is the number of enemies within Telemetry Range, and ManageObjectCnt is the number of currently launched child units of the carrier. (AI_GENERAL is a boolean flag to determine which unit type to launch. As you can see the caller(Offer) says Do I need any unit 'AI_GENERAL', but the Needs() function ignores it anyway). So, the rule is: If the number of enemies is larger than the number of launched objects, let the AI know that you need to launch another. It doesn't seem to care what /kind/ of thing to launch though. I'm not sure if your carrier counts as one enemy, so you can test attacking with no launched units, and then more launched units, and see if he matches tit-for-tat. Also, it won't launch anything if there's nothing to launch (obviously), but there's no outward sign of that to the player.

Yeah, I just unpacked data00, and sure enough there's loads of Island-specific folders in there. Dang. I thought the islands would just be generic meshes, and the game picked the mesh type for each island at random. Looks like to make a new island you'll have to create an island art folder from data00.cc, and modify the island names in data01.cc. I think the named-island-scripts are for the specially-scripted bits where you can trigger story lines by hitting a trigger point on a specific island etc. The majority of the islands just seem to be randomly generated from a few hard coded "types". Try just copying a non-special island, renaming the files, and adding the island to the island list, and see what happens?