[ALPLUGIN] Xenon Migration V1.40 : Update 09/01/2007

[Hieronymos]

When assigning hotkeys, all the scripts currently on my current campaign were active. I chose "b", and was not informed of any conflict.
Feedback?

Hieronymos

[leecarter]

Just an FYI:

For whatever reason it was never getting/setting the $level variable. I changed the if $level null statement (which calls the message) to a hardcoded $level = 2 and it works now.

Don't know the cause, but at least it's not asking me everytime I load a game now.

[bahaal]

sorry but it is a probleme with french file(33)
see the file:

447546:

<?xml version="1.0" encoding="UTF-8" ?>
<language id="44">

<page id="7546" title="Xenon Mirgration">
<t id="1">Xenon Migration</t>
<t id="2">[author]Xenon Migration Configuration[/author]Select the level of difficulty you wish to use for Xenon Migration\n\n
[select value="1"]Easy[/Select]\n
[select value="2"]Medium[/Select]\n
[select value="3"]Hard[/Select]\n
[select value="4"]X-Treme[/Select]\n
[select value="auto"]Auto Difficulty[/Select]\n
</t>
<t id="3">Xenon Migration: \033GConfiguration\033X</t>
</page>

</language>

337546

<?xml version="1.0" encoding="UTF-8" ?>
<language id="33">

<page id="77546" title="Xenon Mirgration">
<t id="1">Migrations des Xénons</t>
</page>

</language>

the french file is empty.... and in game we have a readtext75xx-2(forgot75xx sry)

edit:
if have a similare probleme with the marchand guild(readttext....) and can'tuse it too

[Cycrow]

you could simply copy the missing entrys over into the french file for it to work. I didn't actually make the french text files, so i dont really know whats missing from them all.

leecarter, are you remembering to save the game after you have selected the level to use ?

[leecarter]

Yup, selected difficultly level > saved > continued playing > saved again (multiple times) > died > loaded most recent saved game > select difficulty dialog appears again. Rinse and repeat. The xenons would still migrate after I made the selection anew each time, but it was getting a little bothersome so I just hardcoded the medium value.

The earlier version (pre X3 2.0) worked fine.

[pmachin]

I've been using the latest version and it's still creating invincible Xenon. I tried using your Destruct Ship script to get rid of them but that doesn't work either. Is it possible that these Xenon have ceased to exist but haven't been removed? Any ides on a quick fix to rid my universe of these phantoms? ....Oh and removing the script didn't work.

Just had a thought. If the Xenon reach their final destination what happens to them? Are they removed by the script? Because all my invincible ships are hanging around in Xenon Sector 347.

[Cycrow]

they should be removed once reching thier destination.

you could check what commands are running on the ships that are invicible. but as i said, the improves will only effect new ships that are created, not ships that are already in the game.

so if you already had invicible ships, then it wont effect them.

but it does make sense for them to hand around the target sector, they are removed exactly the same way the destruct target works, so if that doesn't work, then they also wont be able to get removed by the script.

ill carry on testing it when i get chance to c if it can find any other problems

[pmachin]

A few of the ships (they are all Xenon Ns) are running

al.xenonleader.dies prio = 100

The ships that are within range of other ships are running

!ship.cmd.killenemiesrange.std prio = 0
!fight.attackeneemiesrange.land prio = 0
!fight.attack.object prio = 0

[Cycrow]

the leaderdies is the one thats causing the problem from xenon migration, if the other ships are just running standard attack scripts, its likly they were not part of Xenon Migration.

whats happening is the script gets stuck for some reason, even thou all it does is change the leader and assigned the xenon move script to the new leader.

coz it gets stuck and doesn't finish, the ship never dies.

im gonna try to work on a script that will attempt to remove this, most likly creating a temport station, moving all the ships to this station and blowing it up

[leecarter]

Thanks for all the work you're doing.

[aroka]

I can`t donwload any of the cycrow files. Appear the website doesn`t work anymore or at this time.

[goulchewer]

Hello everybody and happy new year. I am new to the forum and to the world of sripting in X games, though I have some experience in general sripting and programming.

In fact, I have begun to learn about sripts due to the bug of indestructible ships in Xenon Migration AL plugin and I have just realized that in al.xenon.move there is mistake, or I think so. I think that inside the loop the variable $sector should be updated. Maybe I am wrong, but this script is causing an endless loop (although I cannot see a connection between this and the bug)

Anyway, I have been doing some tests and I have seen that indestructible ships are all running on top al.xenon.leader.dies (why all of them?) with prio 100 and interrupts tagged as blocked. Does it mean that there is no way of interrupting al.xenon.leader.dies (it seems to be stuck) and destroying these ships?. Because I think that these indestructible ships are the cause of my savegames being bigger and bigger. Maybe all of this are paranoias .

I know that Cycrow has not posted in the forum since acouple of weeks (I guess is on holydays) but I also know that in this forum there are a lot of good sript gurus. Could someone tell me something about all of this?. Thank you.

PS: ... not bad for my first post

[jbaron1980]

Cycrow, are you nearer to finding a solution to the invicible xenon ships problem ??
I was really enjoying using this script but had to turn it off since some of the xenon sectors were starting to fill up with these indestructible little buggers.

I know you are probably busy but this script really livens up my universe. Cheers.

[Cycrow]

i've not had chance to look yet, but i should be testing it out soon to c what i can find

[goulchewer]

Cycrow,

after doing several tests, I think I've found the origin of the bug. For what I read in your scripts the idea is that once the patrol have reach their destination the leader is destroyed (in al.xenon.move) and a new leader is designated (in al.xenon.leader.dies) and given the order of starting al.xenon.move. Since they are at the destination sector, the new leader is destroyed and so on, until the whole patrol is destroyed.

It seems that this process of destroying the leader, designate a new leader, destroy the new leader... ; is done too fast without any interruption and the script engine get messed up.

Including a random wait just before the destruct instruction in al.xenon.move makes the process working as it should.

Code: Select all

001   $sector = [THIS] -> get sector
002   
003   while $sector != $destination
004 @  = [THIS] -> call script '!move.movetosector' :  sector=$destination
005 @  = wait 100 ms
006   end
007   
008 @ = wait randomly from 100 to 200 ms
009   [THIS] -> destruct: show no explosion=[TRUE]
010   return null

Anyway, I cannot find a way to destroy these immortal ships; and I have tryed almost everything (getting some odd results). At least I have checked that your idea of putting them into a station and then blow up the station works fine.

Hope this can help you

[Cycrow]

actually i've thought of a better way to do that. Ill try get it added to the script soon.

but basically, its reverting the signals back to defaults, then killing the whole patrol in one go, should work.

i will also be testing this with invinicle ships too, and possibly add a way to make sure it removes all of them as well

[Red Spot]

Seeing this script and reading only the last 3 posts on this topic I think I may have an answer to *some* problems ...

this bit of code

Code: Select all

001   $sector = [THIS] -> get sector
002   
003   while $sector != $destination
004 @  = [THIS] -> call script '!move.movetosector' :  sector=$destination
005 @  = wait 100 ms
006   end
007   
008 @ = wait randomly from 100 to 200 ms
009   [THIS] -> destruct: show no explosion=[TRUE]
010   return null

wont work ....



first the current sector of the ship is taken than it enters a loop to compare its destination with that current sector, now as the current sector is never updated the loop will never end and the ship will always (try) to keep flying to de destination-sector (even if it already is there)


changing the code to something like this should already solve that

Code: Select all

002   
003   while $sector != $destination
004 @  = [THIS] -> call script '!move.movetosector' :  sector=$destination
005 @  = wait 100 ms
001   $sector = [THIS] -> get sector
006   end
007   
008 @ = wait randomly from 100 to 200 ms
009   [THIS] -> destruct: show no explosion=[TRUE]
010   return null

the first time there will be no sector and so the script will enter the loop as null != an existing sector (nice feature is that if the destination would be forgotten the script will pass the loop and go right to the destruction part, keeping the uni. clean of unused ships)
than it will get its current sector (wich is hopefully already the next sector, saving you a single check (not much but its something ..)) and as long as it isnt the same as the destination it will stay in the loop
(only thing that than may be added is a check for a possibilty to get to the destination, as not every game is in a vanilla uni. where all sectors are connected)



G

[Cycrow]

hmm, strange i cant beleive i missed that, but your right.

but i think i know what the problem is, the script is actually an old imcomplete version, not sure how that slipped in, but it seems to have overwritten the proper one.

should be an easy fix now i know what the problem is

[goulchewer]

yes, that is the problem that I pointed out in my first post (and the reason why you find so many xenon when you entered a xenon sector ), and I think that making a new version of the plugin that work fine should not be very difficult.

But the problem of indestructible ships still remains. All these ships won't disappear just updating the plugin. Cycrow, I have tryed your idea of reverting the signals back to defaults, and then killing the ships, and it does not work with these ships. What I have done is writing a script that find the problematic ships and, for each ship, call another script (with START) which reverts the signal and destroy the ship:

Code: Select all

008   [THIS] -> set ship command/signal SIGNAL_KILLED to global default behaviour
009   [THIS] -> destruct: show no explosion=[TRUE]
010   
011   return null

The only thing I got is interrupting al.xenon.leader.dies. I have also tryed to set the owner race for these ships as player and then sending them to a shipyard in order to sell them. To my surprise, after selling them, they appeared again

PS: sorry to be such a bore but I would like to see the plugin working again

[Cycrow]

ill hopefully have a new realease either today or tommorow, depending on when i get chance