[SCR or MOD] AntiXenonCongaline / NoSwarm: Stop endless Xenon migration.

The place to discuss scripting and game modifications for X³: Terran Conflict and X³: Albion Prelude.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

Post Reply
User avatar
AtomicDryad
Posts: 209
Joined: Sat, 19. Jan 08, 01:04

[SCR or MOD] AntiXenonCongaline / NoSwarm: Stop endless Xenon migration.

Post by AtomicDryad » Sat, 3. Apr 10, 02:41

I used STO to claim Xenon sector 472 and since then there's been what can best be described as a CONGA LINE OF ANGER leading from Xenon Sector 023 to 472. When I destroyed the shipyard in 023, they came from 101...and one sector had 40 Xenon ships in a line from one gate to the other, like ants, (only J's (2) and Q's (6), with assorted lackeys).

At first, this provides some entertainment, however it...never...ends.. What at first seems like an attempt to reclaim lost territory is soon a source of constant annoyance, and unrealistic, illogical, or INSANE behavior on the Xenon's part. For some this is exactly how a machine race should act, however for others, this seems like an illogical squandering of resources which should at least have -some- variation or strategy.


Basically the reason this happens is because the jobs file (which controls respawns) has Xenon spawn in one of the two Xenon shipyards, then fly back to the home sector. The culprit is !job.fight.rthr.attackallenemies, the script that all sector defense ships run after creation, which ends up calling a 'kill all enemies' script. But first, it moves the ship to it's home sector....without checking ownership.

So regardless of if you've claimed the sector with STO or IR or RRF, they still act like the sector is home, and fly their metal butts there. Since invaders tend to get slain by takeover scripts or vigilant players, this creates a never ending migration. For now I'm just nipping this in the bud and leaving things up to the RRF-IR-MBR-IX-WTF-ETC scripts to deal with reclaim efforts.

I have created two fixes for this problem. You only need to install -one-. Please see the pros/cons of each to decide. I prefer the mod and will likely develop that version further.

The script: al.plugin.anticongaline.xml
This is an AL script that checks, every 120 seconds, any Xenon ship under a 130 seconds old in the two Xenon shipyard sectors. IF it's command is to move to a player owned sector AND it's home sector is set to that sector, the ship is destroyed.

Pros:
Easy to turn on, off, or uninstall.

Does not require a mod.

Cons:
This may BREAK some mods or scripts that deal with Xenon and/or warfare. Untested with them, I do not use RRF / IR / MBR / etc.

It runs a loop on up to ~ 100 ships. I have optimized the loop but it is what it is. I have experienced no -noticable- performance impact, but this is inefficient and does use cpu cycles every 2 minutes. If your game is already bogged down, you may notice. This should probably be rewritten as a signal hook.

--

The mod: noswarm-r1.spk
This overrides the default !job.fight.rthr.attackallenemies script but does not -overwrite- it. (Thanks ThisIsHarsh!). When it reaches the point where it's told to move to the home sector, it first checks that the ship is Xenon - which is basically the only extra work added for all the other races. Then, if the noswarm.enabled global isn't FALSE, AND the home sector is owned by the player, it skips past the 'fly home' bit.

Pros:
The proper way to handle the problem I believe, rather than monitoring spawns or sectors.

Very resource efficient, I imagine the cpu load caused by the robotic #CONGA.LINE is much greater than this fix.

The ship's original home is helpfully recorded on a local variable, for use in other scripts.

Cons:
This may BREAK some mods or scripts that deal with Xenon and/or warfare. Untested with them, I do not use RRF / IR / MBR / etc.

It's a mod. Version 2.6 will be out -really- soon, which means it may clobber this upon install, and that this may need updating. UNINSTALL before applying 2.6 patch, lest package manager get confused.

Also, the former inhabitants of your shiny new sector will stay in the shipyard sector. Lingering. Waiting. Going "DERP DERP DERP". For each non shipyard sector you conquer, 101 or 023 will have approximately: 5 N's, 7 M-LX's, and 4 Qs. If your plan is EXTERMINATUS, you will find that the two shipyard sectors become more fortified as you continue your invasion. For some, this may be a -good- thing, though the sector's defense might become -too- much to handle, with 16 respawns every 260 seconds, for every sector claimed XD.

This also means that uninstalling means not just removing the mod, but killing every last one of the bastards in 101/023, I think XD.

Script/Mod authors
The mod only does what is described above. If your scripts depend on Xenon swarming migration behavior, This can be turned off by setting the global 'noswarm.enabled' to FALSE, and destroying every ship in 023/101 with the local variable 'job.homesector'.

Todo
Trickmov informed me that one can move ships to the 'null' sector. This might be better than the entrenchment side effect.

(old OMGWTF post below)
It never ends, literally. I used STO to claim 472 and since then there's been what can best be described as a CONGA LINE OF ANGER leading from Xenon Sector 101 or core 023 to 472. There's a new Q every minute or so with COMMAND_MOVE_SECTOR flying from 101...thanks to Gazz's tractor beam it flys from 101 into an asteroid but that only works if I'm IS.

Does it end? What causes this? A stock script, a director file, a jobs entry? Is it possible to adjust?
Last edited by AtomicDryad on Sat, 3. Apr 10, 22:58, edited 6 times in total.

ThisIsHarsh
Posts: 1135
Joined: Sun, 19. Oct 08, 18:46
x3tc

Post by ThisIsHarsh » Sat, 3. Apr 10, 06:32

This is a common problem with no easy solution. The engine spawns ships at a Xenon shipyard, which then move to their homesector, which happens to be the one you own.


I've been toying with an idea to add a sanity check to all vanilla !job scripts. This would would move them into a valid sector the instant they are created, and also set their homesector/homebase to be valid, etc. This would solve the biggest problem with all the sector takeover scripts - the constant respawn of ships despite the change of ownership.

The problem is it's a controversial idea, since it means replacing all the vanilla !job scripts, which could cause script incompatibilities, and will be invalidated by any new patches that egosoft release.
There are 10 types of people in the S&M forums - those who understand binary, and those who don't.

Black holes are where God divided by zero.

User avatar
AtomicDryad
Posts: 209
Joined: Sat, 19. Jan 08, 01:04

Post by AtomicDryad » Sat, 3. Apr 10, 07:23

ThisIsHarsh wrote:This is a common problem with no easy solution. The engine spawns ships at a Xenon shipyard, which then move to their homesector, which happens to be the one you own.


I've been toying with an idea to add a sanity check to all vanilla !job scripts. This would would move them into a valid sector the instant they are created, and also set their homesector/homebase to be valid, etc. This would solve the biggest problem with all the sector takeover scripts - the constant respawn of ships despite the change of ownership.

The problem is it's a controversial idea, since it means replacing all the vanilla !job scripts, which could cause script incompatibilities, and will be invalidated by any new patches that egosoft release.
So it's !job(somethingblahsomething) that's doing this? Good to know it's not hardcoded into X3.exe or something >.>


Just slapped together a less elegant, but quite effective solution:
http://fnord.to/x3/al.plugin.anticongaline.xml
This depends on the sector being taken over by STO, it will need changes to be compatible with IR or RRF or MBR (if that too is doing takeover stuff).

Right now it's in initial testing configuration with verbose logging and a 30 second cycle. No noticable performance impact, the most of which likely comes from logging. The cycle can be slowed down as soon as I determine the speed of the fastest N and the shortest distance from a shipyard to sector gate >.>

Further improvements may entail a user configurable setting for allowed 'leaks' vs age of sector takeover. (ie, full strength for N days, then decreasing from 100% to N% over N days...perhaps further options for randomness, and hooks for RRFIRMBR(tm) style scripts.)

djrygar
Posts: 1841
Joined: Mon, 10. Aug 09, 02:09
x3ap

Post by djrygar » Sat, 3. Apr 10, 12:05

the only hardcoded thing is gropup of Khaak (I think it called {Khaak 7 Sphere} ) that is spawned at [playership] every minute when IS if sector belongs to Khaak. Now THAT is irritating. and no solution I guess, even some script that would remove them is out of question - they would appear and disappear in front of your eyes, and that is not acceptable I think.

When you look at xenon jobs you'll see they are tied to particular sectors, and are given specific commands (like patrol long), so its enough to just remove job instead of running script.

mark_a_condren
Posts: 1468
Joined: Wed, 3. Aug 05, 05:05
x3tc

Post by mark_a_condren » Sat, 3. Apr 10, 12:26

they would appear and disappear in front of your eyes, and that is not acceptable I think.
I find this perfectly acceptable, my reason being, besides that fact that it seems to be ok for them to just appear like that,

- Kha'ak all angry and PO'ed about "Invader"
- Kha'ak jump in
- Kha'ak pilot go "OH crap .. "HIM / HER" .. They kill cousin 'ZitZit' last week! me lik'in cousin 'ZitZit'. but me no wonna ends up like cousin 'ZitZit'.
- Kha'ak goes "Bye, me outta here, me goes back en hides in Bug nest" .. Poofff gone.
- All rest of Kha'ak goes "Me Too" Poofff

Hey, them bugs! All prob related to cousin 'ZitZit'

Sorry, had to have some fun with that. :roll:

MarCon

djrygar
Posts: 1841
Joined: Mon, 10. Aug 09, 02:09
x3ap

Post by djrygar » Sat, 3. Apr 10, 12:50

hehehehe, yeah. But it still be wrong. They ONLY, ONLy appear near player ship. If you are surronded/protected by wingmen, or some military ships - they still choose PLAYER ship. This is so silly and counter-immersive I just cannot grasp how ES could create something like that, and in addition - hardcode it (even if they created plenty of tools to make this in other ways - jobs, script, MD). Seems like some development leftover.

The-Last-Communist
Posts: 405
Joined: Sun, 21. Feb 10, 13:51

Post by The-Last-Communist » Sat, 3. Apr 10, 13:15

i think its related to x2 , where going to Kha'ak sectors was ment to be dangerous , and in thos days there was no job file , there for Kha'ak spawning was the solution

EDIT wow! when you type Kha'ak in atached leterse it corectis to the won with the apostrophe ! cool!
Splits , for the better things in life...

djrygar
Posts: 1841
Joined: Mon, 10. Aug 09, 02:09
x3ap

Post by djrygar » Sat, 3. Apr 10, 13:45

mark_a_condren wrote: - Kha'ak all angry and PO'ed about "Invader"
- Kha'ak jump in
- Kha'ak pilot go "OH crap .. "HIM / HER" .. They kill cousin 'ZitZit' last week! me lik'in cousin 'ZitZit'. but me no wonna ends up like cousin 'ZitZit'.
- Kha'ak goes "Bye, me outta here, me goes back en hides in Bug nest" .. Poofff gone.
- All rest of Kha'ak goes "Me Too" Poofff

I just imagined, that this could be voice-over when they spawn. With silly cartoon-like voices (like those Evoks voices from starwars or Gremlins). I would LMAO for a week :D

but who would be able to kill them then ;D

User avatar
AtomicDryad
Posts: 209
Joined: Sat, 19. Jan 08, 01:04

Post by AtomicDryad » Sat, 3. Apr 10, 17:35

djrygar wrote:the only hardcoded thing is gropup of Khaak (I think it called {Khaak 7 Sphere} ) that is spawned at [playership] every minute when IS if sector belongs to Khaak.
That's pretty lame =[
When you look at xenon jobs you'll see they are tied to particular sectors, and are given specific commands (like patrol long), so its enough to just remove job instead of running script.
Remove job entry from types/jobs.txt? Or is there a way to globally suspend a job entry via script?

User avatar
AtomicDryad
Posts: 209
Joined: Sat, 19. Jan 08, 01:04

Post by AtomicDryad » Sat, 3. Apr 10, 17:41

djrygar wrote:the only hardcoded thing is gropup of Khaak.
Does this mean it's possible to restore pre 2.5 boarding via script edits? :D :D :D

User avatar
AtomicDryad
Posts: 209
Joined: Sat, 19. Jan 08, 01:04

Post by AtomicDryad » Sat, 3. Apr 10, 22:33

Bump because I've turned this from a question thread to a release thread. Please test XD

User avatar
Sublogics
Posts: 197
Joined: Tue, 24. Oct 06, 12:53
x4

Post by Sublogics » Wed, 16. Feb 11, 18:21

Tried to download these fix files today, but seems to be down. Any possibilities to make it downloadable again?

User avatar
Litcube
Posts: 4254
Joined: Fri, 20. Oct 06, 19:02
xr

Post by Litcube » Thu, 12. May 11, 21:27

I just ran across this problem in my own game. The problem is that these ships aren't job engine spawned, their spawned by the GOD engine.

Firewrath
Posts: 121
Joined: Fri, 3. Aug 07, 05:49
x3tc

Post by Firewrath » Fri, 13. May 11, 00:05

So i havnt played X3 in like Months* (Jan/Feb or so, :P) or really ran into this, and im getting a 404 on the links too,
(*stupid life *mutters* :P)


But if someone is going to redo this script as a fix or something like it,
wouldnt it make more sense for the Xenon ships to attack each sector as they travel back to their home sector?

the OP said the 2nd script checked if the ships were Xenon, so you could Basically do that to prevent the script from telling the other races to attack enemy sectors between their respawn and home sector, because while it seems fitting for the Xenon, it doesnt really work with the rest of the races.

Anyways. Just thought i'd toss that out there if anyone else was interested in redoing the script.

Post Reply

Return to “X³: Terran Conflict / Albion Prelude - Scripts and Modding”