Oolite Bulletins

I think that makes sense... the various worlds themselves must make some sort of contribution to GalCop/Co-op, though. The more organised and economically successful the system, the more Viper patrols they can afford to fund and/or demand: hence the heavy police presence in Corporate States and Democracies, all the way down to the token presence around Anarchies that rarely ventures outside the station aegis. The planets must also provide some sort of input into station construction, building fancier stations around higher-tech systems. The Dictatorships and Commies OXPs add some interesting dynamics to this: being inherently more militaristic, they seem to be developing police/navy ships of their own... how long until a Commie version of a Behemoth is spawned from a collective ZGF? Or until a Dictator thinks to adapt one of those tankers as a carrier? There's trouble a-brewing'...

Anyway, this is getting a bit off-topic so I'll shut up about it now!

Disembodied wrote:

Code: Select all

<string>[LOCALHERO_OFFER1]\n\nHARKOV! This is our chance!\nHe's leading a major strike force\nheading for this station.\n\nYour mission:\nprotect the station, destroy his henchmen and capture General Harkov.\n\nWill you do it, Commander?</string>

Code: Select all

<key>LOCALHERO_RUNNING</key>
<string>Ehm, Commander.\n\nI don't expected to see you again without\n one of Harkov's scum in your hold.\n\nI there some sort of problem? Should I entrust\nthis mission to another captain?\n\nDo you want to step back?</string>

Code: Select all

<key>LOCALHERO_MISSIONCHOICE</key>
		<dict>
			<key>LOCALHERO_ACCEPTED</key>
			<string>Yes, I will.</string>
			<key>LOCALHERO_REFUSED</key>
			<string>No, I won't.</string>
		</dict>
</dict>
</plist>

You might want to make sure that saying "yes" actually means accepting the mission, not stepping back...

Cmdr. Maegil wrote:

You might want to make sure that saying "yes" actually means accepting the mission, not stepping back...

No. This Text is only displayed while a mission is running. There is only 1 defined missionChoice for all kinds of questions and in that case the mission would be aborted.

@ Disembodied (and Svengali): Only recently (read: right now) I had a look at the wiki pages about GalCop and the different government types, which is part of the Powers and Organisations page. The information found there support my view. I could have referred to them earlier, but I simply hadn't visited these pages for a long time.

So this is the framework in which the OXP discussed here should work, without demolishing too much of the frame.

Commander McLane wrote:

@ Disembodied (and Svengali): Only recently (read: right now) I had a look at the wiki pages about GalCop and the different government types, which is part of the Powers and Organisations page. The information found there support my view. I could have referred to them earlier, but I simply hadn't visited these pages for a long time.

So this is the framework in which the OXP discussed here should work, without demolishing too much of the frame.

Yes, I think you're right. But the good thing is there's still a lot of wiggle room! For example, one man's pirate can be another man's privateer, or patriot, or policeman. I think the whole Galactic Co-Operative is probably a hell of a lot less co-operative than people would like to think: at best, it's most likely a bodged and shaky compromise, held together largely by bureaucratic inertia and a lack of good/practical alternatives...

Disembodied wrote:

at best, it's most likely a bodged and shaky compromise, held together largely by bureaucratic inertia and a lack of good/practical alternatives...

Hmmm, thinking of organizations I know of: why does that sound so familiar...

Disembodied wrote:

Yes, I think you're right. But the good thing is there's still a lot of wiggle room! For example, one man's pirate can be another man's privateer, or patriot, or policeman. I think the whole Galactic Co-Operative is probably a hell of a lot less co-operative than people would like to think: at best, it's most likely a bodged and shaky compromise, held together largely by bureaucratic inertia and a lack of good/practical alternatives...

And this is one of the secondary reasons for GalCop's collapse following the lost of the wormholes that link G1 to the rest of the Galaxy.

Captain Hesperus

Hello folks,

the Oxp is at a good way, but I'm a little bit confused about the AIs.
If a performAttack is executed and the target is a very slow moving vessel the DESIRED SPEED is set to an absolute small value and sometimes they don't attack anything, don't face the target or even don't react to offenders.

Is there a kind of aggression factor that can be increased?
Any solutions?

My only suggestion would be to repeat the performAttack by putting it in the UPDATE-part as well. That could make the ship more aggressive while attacking.

But if the performAttack method in itself is somehow broken or at least imperfect, I can't help you with that.

Anyway, I would try.

Svengali wrote:

Is there a kind of aggression factor that can be increased?

I know nothing about scripting but perhaps performhaka in the routine? or peformreallynastyhaka

Seriously though, hope the more knowledgeable peeps here can help.

Svengali wrote:

If a performAttack is executed and the target is a very slow moving vessel the DESIRED SPEED is set to an absolute small value and sometimes they don't attack anything, don't face the target or even don't react to offenders.

McLane wrote:

My only suggestion would be to repeat the performAttack by putting it in the UPDATE-part as well. That could make the ship more aggressive while attacking.

The command performAttack should not be repeated. Once you issue it, the ship starts a sets of tactics you should let it finish. With the AI commands you set a behavior for the ship. The ship can only have one behavior at a time. This stays as long as a new behavior is commanded. PerformIntercept and PerformFlee are examples of these commands.

PerformIntercept --> BEHAVIOUR_INTERCEPT_TARGET :

PerformFlee --> BEHAVIOUR_FLEE_TARGET :

PerformAttack is more complicated. Once issued it chooses from several different attack modes. Partly completely random chosen and partly based on his unique ID number. This makes sure a similar ships often behaves a little different to make a battle more fun. But these attack modes are not permanent, they constantly switch. After issuing a performAttack the script should do nothing but wait till the target is destroyed or the script wants to do something else. The script can do some things but nothing that changes behavior.

PerformAttack -->
BEHAVIOUR_ATTACK_TARGET :
BEHAVIOUR_ATTACK_FLY_TO_TARGET_SIX :
BEHAVIOUR_ATTACK_FLY_TO_TARGET_TWELVE :
BEHAVIOUR_ATTACK_FLY_TO_TARGET :
BEHAVIOUR_ATTACK_FLY_FROM_TARGET :
BEHAVIOUR_RUNNING_DEFENSE :

performAttack should not adapt his speed on a very slow moving object. In the last part of a attack run it prefers a speed of 25% of his own max speed but when the victim flies faster than this value it uses the victims speed.

The only thing that needs to be set is a target before issuing the command. (That one is set correctly on entering Svengali's state example). What could be a problem is the message "FRUSTRATED". This message is set when is has not a good success in his attack. After issuing this message he normally flies away from the target to start a new attack. (a script could use this message to scan for a new target at this point). But in Svengali's script he switches to another state that starts with: performIdle. This logically breaks off the attack.

Eric Walch wrote:

What could be a problem is the message "FRUSTRATED". This message is set when is has not a good success in his attack. After issuing this message he normally flies away from the target to start a new attack. (a script could use this message to scan for a new target at this point).
But in Svengali's script he switches to another state that starts with: performIdle. This logically breaks off the attack.

That was my intention. It is only used for some special missions when a lot of enemies were nearby.
The WIKI says for performIntercept:

When it hasn't come closer to target for 10 seconds it returns: "FRUSTRATED"

I don't know what happens if a ship has a frustration factor equal 1 (or higher), but I thought
resetting it to zero (performIdle) is necessary to do any other attack, scan or check for position
successfully. So it can react to the new situation without a big handicap. And maybe it is the same
for performAttack?

Svengali wrote:

I don't know what happens if a ship has a frustration factor equal 1 (or higher), but I thought resetting it to zero (performIdle) is necessary to do any other attack, scan or check for position successfully. So it can react to the new situation without a big handicap. And maybe it is the same for performAttack?

The FRUSTRATED message is not explained in detail in the wiki. It is used frequently within the code and it is actually counting time. Every time things are not ads good as it should be the code adds a little bit of time to this variable. Then when it reach a maximum value it issues the FRUSTRATED message, resets the variable to zero and starts from scratch with counting.

So you do not need to reset the performAttack yourself. In most cases the AI has no need to react on it and the function will react on it by itself. The time to issue the FRUSTRATED message is chosen so high that it signals a problem when it is issued. On different functions the time is different.

I now use the FRUSTRATED message in a performCollect function. In my mining mission, half of the time the NPC ships leave noncolidable objects. (Bug in oolite) Other mining ships find these objects and try to scoop them. They were endlessly trying to scoop them. Now I added a FRUSTRATED message to jump to a second performCollect state. When this again results in a FRUSTRATED I let the AI just give up and search for an other target.

Hello Svengali,

I noticed that sometimes the group members are killing each other. It are the escorts that are firing at each other or their mother. I just found an escort and checked it was in the "LEADED" state. Then I fired a shot at the mother and one escort started to shoot at the other. There is a bug in the script (or Oolite itself)
I removed some lines that are not essential for showing the problem.

When your escort is attacked it messages the mother who receives a ATTACK message as if she was attacked hereself. Then the mother sends a "GROUP_ATTACK_TARGET" to herself and her escorts.

This is when the escorts react. Your escortAI is copied from the standard escortAI, but you added a requestNewTarget. This is not necessary as the mother already send the target as found target with the message.

This command had to be the culprit but I could not understand why. Looking in the code I saw that requestNewTarget looks for ships that are targeting the mother and have hostile behavior. But to follow the escorts are already targeting the mother and are hostile. AARGH!! It seems that this command was written with clean ships in mind. Now the mother gives as target one of the escorts. So this command should not be used with hostile escorts.

EDIT: I just shot on one of the two escorts. With the debugging key I noticed that the mother and the other escort also took this escort as target and attacked him.

requestNewTarget should never be followed with a setTargetToFoundTarget. It returns: "MOTHER_LOST", "TARGET_FOUND" or "NOTHING_FOUND". setTargetToFoundTarget should only used as reaction on "TARGET_FOUND". Ill update the wiki when it is availlable again. (it seems to be down since yesterday.)

I'm in Galaxy 4 and even when I'm at a TL 10 Democratic system there is a distinct lack of local heros.

Oolite is running under Deban Linux Unstable. The version is 1.69 build 1234.

Can anybody suggest a fix?