nww02

There's lots of argument over AI being poor, and there are also some Dev comments about modding tools and an expanded EnForce API release at some point in the future... So rather than dissing BI, and since we're all intelligent people, why not get our heads together and constructively suggest some AI tactics? Basically, the script and object model they've created seem quite general, so "Walrus on Walrus" and "Manta on Walrus" seem quite similar - Got a Gun? Yeah? Go to optimal distance for firing You there yet? Yeah? Shoot, then! You Hurt? Worse than the player wants you to be? Go find cover! But some of the AI is a little simplistic. For example, the Carrier Defense tactic is Do I need reinforcements? Has the enemy launched more units than me? Yeah? Launch a unit too, then. If you want to suggest a tactic, don't worry about axes and frames etc.. Just think high-level plans, * assume that you can 'at-a-distance-inspect' the thing you're fighting, * you've got access to the list of enemies/islands/buildings nearby. * you can just ask the unit to go to a place, without worrying about how it's going to get there. Maybe someone on here is smart enough to post a good constructive idea, and it helps the devs concentrate on other issues? If you think your tactic is mega-awesome, and everyone agrees, post it on the sticky at the top, so that it's not buried in here, on the chance that this topic gets large. :)

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?

If you want to see the effects of negative friction, and a coefficient of restitution > 1, have a watch: A bit of fun for a saturday evening :-)

Try setting it to a -ve value, you may have some fun ramping mesas on the desert islands ;-)

If you search the files for one of the island names ('Taksaven' for instance), you'll find an array of them in a file somewhere. (I'm at work just now, so can't check - if you haven't replied with 'got it' by the time I get home, I'll find the exact file). Just add the name of your new island to the array, and I think you should get a new island. Not sure about locations and linkages. That may be in the firebird "db" file, if it's not alongside the island array. The Mod Tools app is able to generate new islands, if you want to look at the source code for that?

Yes, there is. The "AI", is a plan-making entity ('tactic') which gets attached to the "scriptable" base object. So, you can make any number of AIs you want, and you can decide which to 'attach' at any given time. (in theory). The attaching part is in the main executable at the moment. That's why I suggested that people could come up with interesting tactics.. If you come up with a good one, it can be turned into a Tactic or VehicleSequence object and added to the corpus of AI knowledge relatively easily. So, to answer your question, there's an Island Defense Tactic which seems pretty rudimentary in this first release. It relies on teleportation of needed resources to specific locations, until resource expires (based on defense value). It leaves the actual fighting to the individual objects, it just makes sure they're where they need to be.

To disorder: Ah, the two calls to that query are in separate blocks. They both do similar things, and the code could be written better, but the first one is what to do if there's an enemy carrier also at the island (basically, if the enemy carrier is here, attack it, unless the AI is 'panicking', in which case, run away). The second call is for when the AI has the island all to itself for attacking. ---------- Post added at 03:07 PM ---------- Previous post was at 02:56 PM ---------- To H4mster: Yes, that's a good point, but it is possible to come up with general plans, without going into specifics. For example, here's a very simple 'co-operative' plan: Is there an enemy unit nearby? Is something attacking me? Ask for assistance. Do I have a chance of actually winning? Yes - Add it to the list of things I need to attack. No - Are there any of my comrades nearby? Yes - Do I have a chance of actually winning with their help? Yes - Call for assistance, and start attacking No - Find Cover Sort attack list by threat level Have I reached the end of my attack list? No - Attack top target in list Yes - Has someone asked for my help & Can I help? Move to assist. I'm sure you can think of a dozen ways to improve it.. Finding cover. moving randomly while firing... timed, scripted attacks, attack patterns... all sorts of good stuff. :)

I wish that were true, but two things suggest otherwise: 1. The game crashes *on load* when you make a typo in a script, suggesting that the code is evaluated when the game initially starts. 2. I've been able to modify the AI of the walrii during a fight by saving the game in a fight, exiting CCGM and then re-loading CCGM (no island transition needed). There's a simple test, though. Replace the function body with this:- vector GetMovementTarget() { ret = ZeroVec; return ret; } Which just returns "do nothing" every time. Then, re-run the tests. It would be interesting to see if they stand still when not in a vehicle fight.

It's Czech. you can Google "Translate ten check je hotfix, nutno vyzkouset jestli se to nevy... nekde jinde" to yield: "check that the hotfix should try if it does not ... somewhere else" :)

I've run a test: I put in a 'return' at the beginning of that whole function. Like so:- vector GetMovementTarget() { Object enemy = GetTarget(); ret = ZeroVec; return ret; Basically, it means that if that function (which has been changed in the mod) is called *at all*, then the walrus will be set to stand still. I've run a few tests, and sure enough, the walrii all come to a screeching halt the moment you target an enemy walrus. All other times, they carry on regardless. So, I'm afraid to say, that modifying this function only seems to affect the paths when fighting another enemy walrus. I also modified the WalrusStaticSeq.GetMovementTarget() in the same way, and sure enough, the moment you target an enemy building... The walrus stops dead. So, the ai pathing is going to have to be modified elsewhere, sorry.

I rather think it means that they've overloaded the "*" operator for the two normalized vectors to produce a "DOT product". If the two are normalized, then the result should be between -1 and 1. 0.9 would refer to 25 degrees (if I'm right). http://en.wikipedia.org/wiki/Dot_product