objCommunicate codes?

[Periculi]

I would like to know if there are more of the objCommunicate msg codes, which seem to be unavailable in a forum search- I looked up the ones on all the autons, but is that it? Are there more codes to use?

The reason that I think there are more codes is because A) the autons have a very limited command set and B) the message codes are oddly numbered.

Here we have the set of commands from transcendence.xml:

Attack => objCommunicate gSource gSender 1 targetObj
the message code for attack is 1

Form Up => objCommunicate gSource gSender 13
the message code to form up is 13

Wait => objCommunicate gSource gSender 14
the message code to wait is 14

Cancel Attack objCommunicate gSource gSender 13
the message code is the same as form up.

Now, the <OnShow> for some commands uses a filter to choose the commands that is => objCommunicate gSource gSender 15

the message code is 15, but what does that MEAN?

We have message codes 1, 13, 14, and 15. isn't that a little oddly numbered, even for transcendence? What about message codes 2, 3, 4, and so on to 12? Many things seem to come in groups of 16 in transcendence, so what about that? Why not deprecate the entire communication set and use the standard ship orders? (if the autons are just a relic from the early days and incomplete at that)

Here is an interesting bit of lore- autons seem to be a special case. They are the only type of object to make use of objCommunicate, which is triggered from the [controller] value in a shpCreateShip command- shpCreateShip [shipID] [vector] [sovereignID] [controller]

You can create a ship to use the auton communication method by placing "auton" for the controller and be sure to include <Communications> in the ship element.

[george moromisato]

The truth is that (objCommunicate) is probably not the right way to implement autons.

A bit of history:

As you know, all ship AIs (regardless of controller) honor a sequential list of orders. Example:

Code: Select all

...
(shpOrder theShip 'attack theTarget)
(shpOrder theShip 'gate)
...

The snippet of code above orders a ship to first attack theTarget and after the target is destroyed, to gate out. Ideally, what I should have done, is to use that mechanism for autons. For example, in the <Communications> code, when you order an auton to attack, the code should just call something like:

Code: Select all

(shpOrder theAuton 'attack theTarget)

Unfortunately, one of the orders that a ship obeys is the escort order:

Code: Select all

(shpOrder theAuton 'escort gPlayerShip)

So when an auton is following you around, it is in the middle of the escort order. If you give it another order, it will not obey the order until the escort order has completed (which it never will).

One possible solution is to cancel the escort order before giving the attack order. Unfortunately, the problem there is that the escort order is the only way that we know that the auton is following the player. If we cancel the escort order, we won't know that the auton should follow the player (for example, if the player enters a stargate).

Anyway, to overcome these problems, I created a special controller to implement the auton. The auton is always in running the escort order. But it can change its behavior based on messages from the player. Thus I added (objCommunicate) to tell the auton that it should attack.

I think this was a mistake. Instead, I should have added a separate variable on a ship that indicates that it is escorting another ship. Then we could use the standard order machinery to command autons and wingmen.

[alterecco]

Sorry for raising this thread from the dead, but it does contain some very useful info.

George, I was wondering it you could shed some light on the available codes for (objCommunicate). As far as I can see there are 4 different codes used, in two different versions.

Code: Select all

(objCommunicate source sender 1 target) --> attack target

(objCommunicate source sender 13) --> FormUp
(objCommunicate source sender 'FormUp)

(objCommunicate source sender 14) --> Wait

(objCommunicate souce sender 15) --> Query attack status
(objCommunicate souce sender 'QueryAttackStatus)

Can we presume that 'Wait and 'Attack are valid codes to send?
Are there more codes than these 4?

Thx in advance ;)

[george moromisato]

The codes are:

1 = 'AttackTarget
2 = 'AttackTargetBroadcast
3 = 'HitByFriendlyFire
4 = 'QueryEscortStatus
5 = 'QueryFleetStatus
6 = 'EscortAttacked
7 = 'EscortReportingIn
8 = 'WatchYourTargets
9 = 'NiceShooting
10 = 'FormUp
11 = 'BreakAndAttack
12 = 'QueryComms
13 = 'AbortAttack
14 = 'Wait
15 = 'QueryWaitStatus
16 = 'AttackInFormation
17 = 'DeterTarget
18 = 'QueryAttackStatus

But I really really really want to discourage you from using these code. Why? Because:

1. Not all controllers accept all codes. Auton, for instance, don't understand the 'AttackInFormation code. In general, unless you see the code being used, it will not work (or will not work correctly).

2. Some codes (such as 'AttackTargetBroadcast) only work when sent by stations that own the ships--sending the message through script may cause instability.

3. I am planning on deprecating the whole system. A better way to control autons and wingmen is to use the normal shpOrder functions--look at the implementation of Volkov, Jenna, and Rama for examples.

[alterecco]

Thanks for those codes anyways George... I will try to adhere to your advice though, and in that regard I have a few questions about your wingman implementation.

Am i correct in assuming that:

1. <OnOrdersCompleted> is a built in event that triggers once a ship is finished with its current set of orders.

2. Orders can be chanined, and the above event triggers only after completing all events.

3. <OnTranslateMessage> is a transition event from the old message system to the shpOrder system. I suppose it is used to handle these events described above.

4. That some of the messages described above are used internally by the game to control wingmen and autons (so we need to be able to handle them)

5. That moving an auton away from the objCommunicate system to the shpOrder system does not make the new AI handling of autons fall back to some worse system.

After having read through the Wingman base I can see how it allows for more fine grained control over the wingmans/autons behaviour. Do you think it will become an issue to have these actions controlled in script and not in the core (performance wise)? Having 10+ autons with complex behaviour might proove taxing.

Deprecating the old system seems fine to me. Will it be replaced by a completely new concept, or is that the general purpose of the shpOrder system?

Thanks again ;)

[george moromisato]

1. <OnOrdersCompleted> is a built in event that triggers once a ship is finished with its current set of orders.

Yes, that's correct. When a ship has no more orders the engine calls OnOrdersCompleted. In that code you should add some more orders. [If you don't, the ship will gate out.]

2. Orders can be chanined, and the above event triggers only after completing all events.

Yes, correct. Of course, you can call shpCancelOrders if you want to cancel the current set.

3. <OnTranslateMessage> is a transition event from the old message system to the shpOrder system. I suppose it is used to handle these events described above.

There is hard-coded code in the controller that tells the player "Watch your targets!" or "Nice shooting!". The <OnTranslateMessage> event is used to override the default behavior. [Note: This is not to process messages coming into the ship--it is to be able to customize the message text that a ship sends out.]

4. That some of the messages described above are used internally by the game to control wingmen and autons (so we need to be able to handle them)

I hope you won't have to handle them (other than to translate message text). If you omit the <OnTranslateMessage> event, the only thing that will happen is that your ship will use the default "Nice shooting!" and "Watch your targets!" messages.

5. That moving an auton away from the objCommunicate system to the shpOrder system does not make the new AI handling of autons fall back to some worse system.

I hope that's true--but until I move autons to the new system, I won't know for sure. I do know that wingmen used to be in the old system and now they work as well or better in the new system.

After having read through the Wingman base I can see how it allows for more fine grained control over the wingmans/autons behaviour. Do you think it will become an issue to have these actions controlled in script and not in the core (performance wise)? Having 10+ autons with complex behaviour might proove taxing.

Good question. I'm constantly surprised by how fast CPUs are and how much code you can run without impacting performance. Another thing that will help is that most of the time the ships will be running native code (while executing an order). Only when you want to change orders (or if you have a timer) will you need to run script. Hopefully that will keep performance fast.

Deprecating the old system seems fine to me. Will it be replaced by a completely new concept, or is that the general purpose of the shpOrder system?

I would like the shpOrder system to be the way to program all ship behavior. Over time I will add more orders to make more and more behavior possible.

p.s: I should say is that I also want to deprecate the concept of "controllers". As you know, the sysCreateShip call takes an optional argument that specifies the "controller" for the ship. In the past, I have done special ship behavior as a new controller. For example, Gaians use a custom controller. But I think that the order system is powerful enough and flexible enough to support any needs without having to write custom controllers.

p.p.s: In the past I have also written complex orders for some behavior. For example, the "trade route" order is a complex order that specifies complex behavior. In the future I will create very simple, primitive orders and implement complex behavior with <OnOrdersCompleted> etc.

[alterecco]

Thanks again for such a full reply. I hope it is ok that questions keep coming up. This time not so many though...

1. Is it possible to remove a ships controller, for example by calling (shpSetController target Nil).

2. What is the purpose of (shpSetCommandCode ...). It seems to contain logic similar to that present in an <OnOrdersCompleted> block.

3. When moving to the shpOrder functions, will all the (shpOrder[Attack/Hold] ..) functions be removed in favour of (shpOrder target 'order ...). Is there a significant difference between them? (personally I prefer the second version).