Oolite Bulletins

They have two roles: tharglet and thargon - how do these work?

I've been updating the galacticnavy.oxp to include thargoid cruisers and battleships to balance the gameplay. With 1.70 and the "setPrimaryRole: thargoid" method I can specifically add certain numbers of cruisers and battleships without them attacking eachother - the tharglets, however, are a different story. They use the same scanForNonThargoid as their various motherships. The motherships don't attack eachother, but the tharglets will attack the motherships.

Also, I've noticed in 1.70 that tharglets once going inactive don't reactivate when a mothership is near (this is after correcting for the new mothership role). Did the tharglets reactivate in 1.65 or am I misremembering?

Thanks to anyone that understands tharglet behavior and is willing to share.

IIRC if the ship which launched the Tharglets died they could be taken over by another Thargoid in the vicinity, so they stayed active.

Nowadays they go inactive when mummy pops her clogs.

However a lot more of them are launched during a battle than used to be the case. If they all remain active then I think that the human race will have had it.

I'm not sure if the following is related:

Witch Space battles finish relatively quickly under v1.71. I remember them lasting a lot longer under 1.65.

(I have all the Thargoid-related OXPs installed abd v1.71 of Oolite)

From my own recent experience doing the Thargoid Plans under 1.68, if there's another Thargoid in the vicinity when you dust their Momma, then they stay active... however, if there isn't, and they go inactive, they don't (thank Giles!) reactivate if another warship arrives in the area.

Something seems to be broken in 1.70 though, they sometimes go inactive even when their parent is still alive. I've seen them launched on the scanner from the ship i was targetting, then they change to white blobs as the go inactive when I'm still locked onto the parent.

I think I heard that it was fixed for 1.71 though?

In 1.70, this behaviour has changed slightly to take advantage of the “role set” system. Tharglets will deactivate if there is no nearby ship with the role “thargoid-mothership” in its role set. Ships are never spawned using this role (except potentially by OXPs), it’s just used to look for motherships.

So, for a ship to be a potential tharglet mother, it must have “thargoid-mothership” among its roles. (This should be backwards-compatible with 1.65, which will just ignore the extra role.)

For targeting purposes, tharglets currently check that the primary role is “thargoid”. This should probably be changed to check for having “thargoid” in the role set (I’ll do that now and roll it back if anyone points out a good reason for it not to be done that way).

Edit: Whoops, not paying attention. In the current code, a ship is considered a thargoid for not-being-attacked-by-tharglet purposes if its scan class is CLASS_THARGOID. You can tell if this is the case because it will be blinking orange and green on the HUD.

davcefai wrote:

Witch Space battles finish relatively quickly under v1.71. I remember them lasting a lot longer under 1.65.

(I have all the Thargoid-related OXPs installed abd v1.71 of Oolite)

That's quite interesting, because there is no such thing as v1.71 of Oolite.

...unless he got the automated daily build from svn. Linux people have all the fun!

Okay, so the "reactivation" behavior must have been some terrible nightmare of mine and never a reality

How about the two remote craft roles: tharglet and thargon - how do they operate in the game? I don't see any AI that scans for them.

Edit: Whoops, not paying attention. In the current code, a ship is considered a thargoid for not-being-attacked-by-tharglet purposes if its scan class is CLASS_THARGOID. You can tell if this is the case because it will be blinking orange and green on the HUD.

The motherships still attack based on roles correct? Maybe when I'm seeing a small number of tharglets attacking a mothership it's because the mothership attacked them first.

Kaks wrote:

...unless he got the automated daily build from svn. Linux people have all the fun!

Mac people do too.
On a good day I build two versions, on a bad only one.

matt634 wrote:

How about the two remote craft roles: tharglet and thargon - how do they operate in the game? I don't see any AI that scans for them.

The mothership’s missile_role is “thargon”, so that’s what’s used for launching them. On the other hand, “tharglet” is used in broadcastThargoidDestroyed to inform the, er, the robot fighters that a mothership died; that is, broadcastThargoidDestroyed sends a non-urgent THARGOID_DESTROYED message to all ships with the primary role “tharglet” within scanner range¹. Additionally, the code that lets you get a kill and full score for tharglets looks for “tharglet” in the role set.

I have absolutely no idea why this distinction exists, or whether it was deliberate.

¹Hmm, interesting. broadcastThargoidDestroyed is looking for a primary role of tharglet, which shouldn’t ever occur. *goes to test*

*comes back from testing*

OK, broadcastThargoidDestroyed isn’t finding tharglets, but their AI has several redundant CHECK_FOR_CONTROL triggers that were masking this. Thank wossname for the JS console, it’s so easy to test this stuff. Whoever thought of that is some kind of genius. ;-)

In 1.71 it’ll check for ships which have “tharglet” in their role set, not just as primary AI. So, in summary: “thargon” is the role used by motherships to launch them, and “tharglet” is the role that gives them special treatment. This means that you can create other ships which get the same special treatment but aren’t launched by standard motherships, which sounds like it’d be useful for one of those thargoid OXPs.

...unless he got the automated daily build from svn. Linux people have all the fun!

Which I do, regularly.

However, while the version number on current development builds is 1.71, it’s not yet the “real” 1.71.

is it not 1.70.buildnumber then at some stage 1.70.bugbuildnumber will be renamed to 1.71?

Thanks for the quick info and testing!