NTai XE10.1b

[DJ]

@smartie

I can't seem to download your config at the moment as unkown files is being grumpy but I'd check the config to make sure the attackers are listed and also that the auto select attackers flag is off.

[AF]

The XE9.79 version is months old. Out of date, kaput.

Unless you're using the very latest builds your bug reports are useless because how do I know that bug even exists any more? Is it a bug I fixed myself since then? Is it a bug in a class that I recently deleted and rewrote?

Simply put, you cant. The latest build isn't in a releasable state. An installer stable perfect build hasn't been released in months, certainly not this half of 2007. You're just going to have to wait for me and DJ to agree with each other on whether svn commit 123abc is worth releasing or not.

[zwzsg]

AF: note that this thread is unsplittable due to it's huge size, so you might want to make a new one sometime

Just give each mod and each AI its own subforum, ffs!

[AF]

There are advantages to having a large thread.

And some posts would be better deleted than split anyway.

[Snipawolf]

AF: note that this thread is unsplittable due to it's huge size, so you might want to make a new one sometime

Just give each mod and each AI its own subforum, ffs!

Sounds like a decent idea. I suppose the creator would be a mod in their forum.

[AF]

http://www.darkstars.co.uk/2007/ntai-progress/

You'll find the dgun behaviour was committed to svn with the old routines removed accordingly. I may do the same for the retreat behaviour soon.

DJ could you look at toolkit, and if it isn't too complex at adding behaviours? A checklist should do the job, although there're one ro two exceptions.

the none and auto behaviours are exclusive, and a unit cannot have this behaviour and any other behaviour. All other behaviours must be disabled if one of these is selected. A unit cannot have both the auto and none behaviours either.

Other behaviours atm are: metalmaker, dgun, and attacker

The tag they're read from is "AI\\behaviours\\unitname", and auto is the default value.

[Argh]

Good to hear you might have found the lag issue! Lemme know when something's in a SVN build that I can re-test with, I really liked how it was playing PURE.

[DJ]

@AF - no problem, there's a few bugs in it i can iron out at the same time... If you use it it loses all your noantistall records for instance.

[DJ]

what format is the tdf in for behaviours?

I assume its like:-

auto=armflash,unit2,unit3;
metalmaker=unitx,unity;

is auto set to be the default if no behaviour is found? And does auto work well?

[AF]

The tag they're read from is "AI\\behaviours\\unitname", and auto is the default value.

So:

Code: Select all

[AI]
{
    [BEHAVIOURS]
    {
        arm_peewee=attacker;
        arm_commander=dgun;
        arm_radar=none;
        random_unit=dgun,metalmaker,attacker;
        arm_mex=auto;
    }
}

Using the XTA names as an example.

[AF]

2 new behaviours

kamikaze and staticdefence

The kamikaze tag is now no longer supported due to the new behaviour

That and masses of other clean ups and tweaks to the code to make it nicer to look at and much more sensible logic in places.

[DJ]

sounds wicked, I'm gunna have a look at this and the toolkit tonight

[AF]

More code clean up and re-factoring out of random things. I've also added another behaviour movefailreclaim which makes units give area reclaim commands when they get a movefailed event if there are features within a 100 radius.

[DJ]

ok sounds like the best bet is to make the behaviours in the toolkit configurable by xml, then you can add them at will. I'll try look at this tonight but I've just done the worst release I've ever done at work and I'm trying to pick up the pieces...

[AF]

What would be the best map for showcasing NTai? Preferably a map that's prettier than comet catcher.

[DJ]

Using this build I got an Assertion Failed message. CKeywordConstructionTask utd!=0 failed

thought i'd try change the assertion to put the valid flag to false, I also added the if(!valid) return; to each of the methods and I haven't seen a crash yet....

[AF]

The problem is that a bad unit id shouldn't make it as far as the task system, it should be caught as early as possible to prevent processing and wasted resources, hence the assert statement.

As I understood it, an assert resolves into nothingness in a release build and a break point in a debug build, so i thought adding an assert would do pretty much nothing and be ignored unless ran via a debugger.

[DJ]

well just a crash anyway, but not as soon into the game as before. Maybe some other system is crashing due to wonky unit id's?

[AF]

No, a bad unitID shouldnt cause a crash unless I haven't checked the return value of UnitDef or CUnitTypeData pointers for null pointer values. bad unit IDs are ignored by the engine.

It's just unnecessary processing and lag that could be avoided, and could lead to certain jamming up like the accumulation of unit objects for units that no longer exist, or even duplicates as a unit that doesn't exists ID is actually assigned to a new unit.

Hence the assertion I put in. If its true then you should look backwards in the debugger to determine how it happened and fix it.

[DJ]

If its true then you should look backwards in the debugger to determine how it happened and fix it.

tbh if i was going to invest time debugging your code i'd be more likely to write my own AI. As it is I don't have much time, I give you as much help as I can, not many people get bug reports down to specific lines of code.

At the end of the day, this is your project, you can either fix the bugs I report or not but I don't have time to fix them for you. I'd like to see this project do well but it's taken so long to get a reliable version it is now well behind KAIK which also plays without the need for configs.