Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[xenoargh]

Got it.  Really wasn't very bad to get the basics working. 

Granted, there isn't any, erm, nuance to it yet, but the AI will now steer to a destination, whether that's a ship or not, and it will "escort" it in a very simplistic way (that will not be acceptable with anything other than Fighters and Frigates in Vacuum- I am not worrying about collisions at all yet). 

Orders still appear to work OK, since they're coming down from the UI.

So, I guess it's time to build the next step up, and see if I can get it to be differentiated in behaviors a bit more.  Right now it's the world's stupidest interceptor; it runs straight at the target and shoots it, period.

Amongst other issues, apparently System AI isn't working any more, so I need to take a look at that and see how to communicate with it (or just replace it entirely, if that makes more sense).

[xenoargh]

Oh, and!

Sorry, I got my terms screwed up, sorry Alex.  I was able to do it with a display list, but only because I was using a shader and used texture data to transmit values.  Anyhow, I'm fairly certain that the same holds true of VBO (manipulating the VBO to shove particles off-screen should be cheaper than making a new quad, setting the vertex attributes and doing a glTexture call; glTexture is very expensive) but IIRC I didn't test that scenario.

You can change contents of the VBO but not display lists, you're absolutely right, and that's probably the way to do it short of using shaders.  Pity that VBO causes terminally-nasty behavior on some Macs' drivers, though that just doesn't surprise me much; lemme guess, they're Macs with ATi hardware

[Sundog]

I don't think that'll be too hard.

Pretty sure you just jinxed yourself 

Edit: hah, nvm. Thought I was looking at the end of the thread when I was actually just looking at the end of the first page... Turns out caffeine is not a full-proof substitute for sleep.

[Alex]

Sorry, I got my terms screwed up, sorry Alex.  I was able to do it with a display list, but only because I was using a shader and used texture data to transmit values.  Anyhow, I'm fairly certain that the same holds true of VBO (manipulating the VBO to shove particles off-screen should be cheaper than making a new quad, setting the vertex attributes and doing a glTexture call; glTexture is very expensive) but IIRC I didn't test that scenario.

Ah, ok. I see what you're saying, in your case you'd be calling glTexImage2D (or some such) fairly often to send data to the shader. In my case, that's not necessary; the texture is loaded once on game start, and after that there's just binding the texture, but that's not too expensive. The way I've got it now is it's using glDrawArrays, which ends up having the same performance as VBO... and the code is virtually the same, too.

Pity that VBO causes terminally-nasty behavior on some Macs' drivers, though that just doesn't surprise me much; lemme guess, they're Macs with ATi hardware

Good guess

[xenoargh]

Pretty sure you just jinxed yourself

Nah, that part was actually pretty easy, although I'll probably have to do another pass later to clean up traveling to an objective in a way that guarantees capture (if an objective) and (eventually) deal with leash limits, since that's one of the things I really wanted to get done with customized AI.

But first I probably need to deal with Systems, and I'm still fairly confused; there are the ShipWideAIFlags, but there aren't any that communicate in a way that Systems need, so I'm pretty confused about how I'm supposed to tell the System AIs to do their thing; do I just tell it to run the System via ShipCommand and it'll handle the actual decision-making over there?

I also haven't dealt with collision avoidance at all, which is necessary before this is applicable to anything but Fighters... but I'm out of free time for this evening

[Alex]

But first I probably need to deal with Systems, and I'm still fairly confused; there are the ShipWideAIFlags, but there aren't any that communicate in a way that Systems need, so I'm pretty confused about how I'm supposed to tell the System AIs to do their thing; do I just tell it to run the System via ShipCommand and it'll handle the actual decision-making over there?

You'll need to write a custom AI for all the systems, however you want to handle that. There's no way to get at the "default" implementation for the system AI; those tend to have some very close, non-API-exposed ties to the default AI, and wouldn't work with a custom AI anyway. You will be using ShipCommand to toggle the system on and off, but I'm afraid all the decision-making is up to your AI

[xenoargh]

I don't suppose that I can subvert the ShipWideAIFlags system to tell the System AIs to just do their thing?  Or are the System AIs not even running if a custom ship AI is running?

[Alex]

Not even running, and, as I mentioned, in most cases couldn't possibly run due to depending on some default ship AI innards. Nothing that *couldn't* be extracted or done by the system AI without that dependency, mind, but it'd just be extremely hairy to do.

[xenoargh]

Hrmm.  That makes expanding this beyond ships without Systems a bit problematical; if the AI doesn't know what the System can / cannot do, and I can't let the System AI, a separate state-machine, make semi-intelligent decisions...

Also, the command to turn Systems on is binary; if I tell it to activate every frame, what happens with Drones?

But mainly this seems like it'd get in the way of efficient code re-use.  If this is a Fighter and it's an Interceptor and it has a Phase Cloak, it now needs a special AI just for it- a Fighter that's Support and has a Phase Cloak needs to behave differently.  Granted, I'm not anywhere near that point... yet... but it's going to happen, and I suspect once the base code's reasonably bulletproof, a lot of people are going to want to try this out- sort of AI Wars with SS ships, heh. 

System AIs got around those hassles somewhat, by providing a framework where the System AI could run the System but the main AI could run movement decisions, firing and all that.  That was a kludge, to be sure, vs. customizing everything very specifically (sometimes the System AI made a bad decision, since it couldn't know much about the AI state machine), but that's exponentially more work to do (and boring work, to boot).  Vacuum has, like, 25 Wing types and 145 ships atm.

Anyhow, I'll have to think about that one a bit, see what makes sense to do.  Maybe I can break it down to a few generic cases that are kludges (after all, I'm not trying to make the AI "brilliant", just behave a little differently and be able to handle a few novel things, like deal with broadside-oriented designs), but are a reasonable fit...

[Alex]

Also, the command to turn Systems on is binary; if I tell it to activate every frame, what happens with Drones?

It works the same way as pressing the button does, in all cases.

System AIs got around those hassles somewhat, by providing a framework where the System AI could run the System but the main AI could run movement decisions, firing and all that.

Well, yeah, and I imagine you'd set up your ship AI in the same way. The exponential amount of work isn't practical at all.

The way I'd see this working is you picking a proper ship system AI implementation in the same place you're picking the ship AI to use (since you have access to the ShipAPI there and can see what system it has). The ship AI would then get passed in the system AI and could call it as appropriate, from its own advance() method.

... but it's going to happen, and I suspect once the base code's reasonably bulletproof, a lot of people are going to want to try this out- sort of AI Wars with SS ships, heh. 

I would so love to see that Looking forward to seeing the one you're working on in action!

[xenoargh]

The way I'd see this working is you picking a proper ship system AI implementation in the same place you're picking the ship AI to use (since you have access to the ShipAPI there and can see what system it has). The ship AI would then get passed in the system AI and could call it as appropriate, from its own advance() method.

OK, that makes sense. 

I'm not sure how to do that, though; my Java-fu is thus far sorely lacking in terms of the concept of code insertion / inclusion like that; I don't know how I'd give it a function call to a remote function like that.  Maybe pass the public function as an object to the ship AI?  Gah, we're getting into parts of Java I'm still pretty clueless about, unfortunately.

[xenoargh]

OK, I think I've figured it out(fingers crossed):

In the ModPlugin, when designating the ShipAI, we can do this:

Code

            ShipSystemAIScript systemAI = (new RepulsorAI());
            return new PluginPick(new StandardFighterAI(ship, systemAI), CampaignPlugin.PickPriority.MOD_SPECIFIC);

This hooks into the AI for the System.

Then, within the AI's advance() we can call the System's advance().  I think that I also need to call the System's init() and set that up right away as well.  I hope this works; it'd be the simple way.

[Alex]

Yeah, that could work. However:

public void init(ShipAPI ship, ShipSystemAPI system, ShipwideAIFlags flags, CombatEngineAPI engine);
public void advance(float amount, Vector2f missileDangerDir, Vector2f collisionDangerDir, ShipAPI target);

The flags, the missileDangerDir, and the collisionDangerDir - if your systemAI is using any of those, you'll have to provide those yourself when calling these methods.

[xenoargh]

I tested it (very briefly) and it works.  Yay!  That makes doing this look fairly practical.

I call init() in the AI's function, setting that stuff up and using null where it's safe.

I wasn't using any of that stuff before, so if anything, they're now extra channels of communication (should I actually need it).

The only remaining challenge is that now I have to write System AIs for everything that didn't have one before and write a halfway-organized method to set it up once I get past the "dumbest interceptor ever" stage

[xenoargh]

Got through a lot of stuff with this.  Couple of questions popped up:

1.  It doesn't appear to be possible to set the angle of Omni shields.  setActiveArc() controls the amount of arc, but there is no setAngle(), or better yet, setDesiredAngle() that will not force it to <angle> immediately, but will change it like a player can.  

2.  I tried to generate the circle-strafe behaviors of Vanilla fighters when they decide they're close enough (and aren't bombers, and the target's suitable, blah blah), but I failed utterly.  

ship.giveCommand(ShipCommand.DECELERATE,null,0) will decelerate, but it's far too slow and the ships slow down to near-zero speeds, making them easy targets.

Are you helping them out a bit there and killing velocity or even giving it a strong push backwards, then giving it a strafe velocity that's quite high, or are you pushing up their MutableStats for acceleration a lot, so that strafing and forward / back is greatly accelerated?  If not, IR confuzed... I have a simple check... if the target's "kite-able" and the fighter's close enough and the fighter's facing the target, then kite (back off and strafe), else accelerate.  But it didn't work (in the functional, "was this useful / desirable" sense, rather than in terms of function) at all.

Anyhow, sorry for the last; it's kind of a frill I don't actually think I want, really, but I wanted to get pretty close to the default behaviors so that there's some sort of baseline for Red vs. Blue robo-pilot deathmatches, heh.

User Error.  ACCELERATE_BACKWARDS... duh... must sleep now.