[Discussion] Sector Takeover and Locking

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

User avatar
Serial Kicked
Posts: 3493
Joined: Fri, 12. Aug 05, 20:46
x3tc

[Discussion] Sector Takeover and Locking

Post by Serial Kicked » Wed, 1. Sep 10, 02:52

Well, this topic is mainly aimed at those who are writing a script that take over sectors (LV, Litcube, djrygar, ThisIsHarsh, i'm looking at you) or need to "lock" a sector for a given period of time. It's not a big secret that i'll go down that road with PG and other future plugins very soon and i'd like a way to stay compatible with 3rd party faction plugins.

So, could we all agree on a global variable array that we'd use to tell other plugins that we're locking a (or several) sector(s) exclusively until we remove this sector from the list ?

This could be used to avoid that 2 different plugins invade a sector at the same time, and probably for other purposes.

I'd suggest to use something like this (except if you've got something better)

Code: Select all

$sectors = global variable "plugin.lockedsectors"
$locked = $sectors[x]

$lock.sector = $locked[0]        // Var/Sector -> Argon Prime
$lock.plugin = $locked[1]        // Var/String -> "anarkis.pirate.plugin"
$lock.optionaldataX = $locked[X] // optional additional data if you need those
where $locked[1] should be the name of the global used to check if your plugin is still active (just in case) or not.


When you need to lock a sector, you'll have to check if it's already in the global array first. If it is, you will have to choose another (otherwise it's pointless :p). If it's not, you add a new value to the array like this:

Code: Select all

$locked.sectors = get global variable "plugin.lockedsectors"

$new.lock = Array alloc, size=2
$new.lock[0] = Your Sector
$new.lock[1] = your global name

append $new.lock to array $locked.sectors
And when done with the sector (invasion finished), you remove the line from the array.

I realize i could write the library needed for that (it's only 2 or 3 commands anyway) right now, but i'm waiting for your opinions / advices / ideas first :)
Last edited by Serial Kicked on Thu, 2. Sep 10, 04:49, edited 2 times in total.
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

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

Post by djrygar » Wed, 1. Sep 10, 03:50

well, I think that 2 takeover script sooner or later will clash.
only way I see IR could work well with this, is when IR user will disable conterstrikes, so IR will not maintain its own takeover array (it has 2 assault modes - one could easily be adjusted to your needs, second, well.. I can see some problems...

Yet, sooner or later we (I've got help now ;) ) will be forced to rewrite whole takeover part, along with 7ate's global nightmare, so this can be taken into consideration/included.

and there is another thing:
http://forum.egosoft.com/viewtopic.php? ... 59#3376459
tell me what you think

this is bit different thing, but I'm thinking if this could be connected somehow.. hm. It could be extended by 4th array, yet general idea was that scripts should not mess with this array so everybody will know its safe to use this information.

....And I love simultaneous invasions :D
this is where things are getting interesting :D Blood! Carnage! Crahes!
I want IR vs F:AI wars :D

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

Post by ThisIsHarsh » Wed, 1. Sep 10, 04:06

I'm all for compatibility. The basic structure looks fine to me, but perhaps the sector array should be a 2D array, indexing every sector by x,y coordinate. With that method, there is no searching through the array, so it's potentially faster. Though for basic use with a small array, it probably wouldn't make much speed difference.

I think djrygar's "backup" array could be incorporated into this, to store the original vanilla owner and have a plot protection flag.

I've had some communication with Trickmov regarding using STO as a sector takeover library, so I can offload as much effort as possible to something tried and true. I've also now had a browse through the scripts and, unfortunately, aside from station repopulation, they aren't really coded with 3rd party use in mind, which is fair enough.

But it would be good to have some kind of sector takeover library to do common functions like spawn suppression, reversion to vanilla owner, intelligent station repopulation, plot protection, etc.
Last edited by ThisIsHarsh on Wed, 1. Sep 10, 05:59, edited 1 time in total.
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.

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

Post by djrygar » Wed, 1. Sep 10, 04:25

after bit of thinking.. actually I already have separate script that tells me if I am allowed to invade given sector..so this should not be so much trouble. I can just add another array to check. Well, then no problems from IR's side.

but what if some script permanently sets a flag and goes boom ? (reinstall, crash, bug etc) Then this sector will be locked forever for others..

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

Post by djrygar » Wed, 1. Sep 10, 04:30

ThisIsHarsh wrote:But it would be good to have some kind of sector takeover library to do common functions like spawn suppression, reversion to vanilla owner, intelligent station repopulation, plot protection, etc [*cough* LV and djrygar *cough* - although LV has been slient for a while, so I take it he's gone and got one of those real life things I keep reading about].
will not elaborate on libraries - I am a rookie here, so my input in such things would rather make things worse than better :D
Another thing.. wouldn't such libraries cause melting those scripts into one with several variations?:) (like I've got Response, you've got Rearguard, and thats where differences end :) exaggerating of course but you know what I mean)

for example - already wrote signal based on your finding, but it spawned several other ideas and I use it for several different purposes, so I'm afraid that if other script will mess with them - There Will Be Blood. Those scripts are just too massive and change environment too much to leave room for similar one. MBRR can still be launched along with IR, but as soon as you include wars/takeovers things will get messy, you'll see

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

Post by ThisIsHarsh » Wed, 1. Sep 10, 05:53

djrygar wrote:but what if some script permanently sets a flag and goes boom ? (reinstall, crash, bug etc) Then this sector will be locked forever for others..
I assume that's why Serial included a global variable at index 1, to check for if a plugin has been disabled. Can't catch all possibilities, though. E.g. if player uninstalls script files without disabling script in game menu, or running an uninstall script, then flag could stay set. But there are things us scripters can do to help. E.g. plugin manager has support for uninstall scripts as part of the spk package.


djrygar wrote:
ThisIsHarsh wrote:But it would be good to have some kind of sector takeover library to do common functions like spawn suppression, reversion to vanilla owner, intelligent station repopulation, plot protection, etc [*cough* LV and djrygar *cough* - although LV has been slient for a while, so I take it he's gone and got one of those real life things I keep reading about].
will not elaborate on libraries - I am a rookie here, so my input in such things would rather make things worse than better :D
Another thing.. wouldn't such libraries cause melting those scripts into one with several variations?:) (like I've got Response, you've got Rearguard, and thats where differences end :) exaggerating of course but you know what I mean)

for example - already wrote signal based on your finding, but it spawned several other ideas and I use it for several different purposes, so I'm afraid that if other script will mess with them - There Will Be Blood. Those scripts are just too massive and change environment too much to leave room for similar one. MBRR can still be launched along with IR, but as soon as you include wars/takeovers things will get messy, you'll see
Well I meant just a library for handling the very basic functions, as I say things like spawn suppression, intelligent station building, interfacing with the above array(s). How, when and why a sector is taken can be handled separately.

No big deal, just means we could capitalize on other people's hard work and avoid similar pitfalls. In-particular, intelligent station repopulation by conquering race, which takes supply-demand into account when choosing stations to build. This would be a hell of a job requiring looong periods of testing to get it right, I would imagine.

Just seems pointless 3 or more people writing their own versions. Of course, different scripters will have different opinions - but a sufficiently well written library could allow for choice whilst still being useful. E.g. STO station repopulation takes an array of ware classes (TECH, BIO, etc) and builds stations to suit. I think that's a brilliant concept - enough control without having to define specific station types and wares.
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.

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

Post by djrygar » Wed, 1. Sep 10, 06:33

ThisIsHarsh wrote: Just seems pointless 3 or more people writing their own versions. Of course, different scripters will have different opinions - but a sufficiently well written library could allow for choice whilst still being useful. E.g. STO station repopulation takes an array of ware classes (TECH, BIO, etc) and builds stations to suit. I think that's a brilliant concept - enough control without having to define specific station types and wares.

and IR has such logic for 2 years now I think. while 7ate had bad coding habits, he did lots of good job. And I see the point, because we will now extend it with custom shipyards etc. I want create market for nividium etc etc etc. Thats whole point of writing separate scripts (besides fact that's is fun to do by itself)

Of course I'm not against sharing etc, your approach with using STO is very wise, especially when its huge work and you would need to sped hell lot of time on boring things instead of playing with those that are more fun for you (AI for example or whatever else). I use ready 7ate's code, if nto for that, there would be no economic booster in IR (probably just stupid spawning of random fabs)

Yet I still like differences. They make things interesting ;)

User avatar
Serial Kicked
Posts: 3493
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Wed, 1. Sep 10, 07:54

Soo,

yeah LV is on holidays, but he'll probably be back soon.
well, I think that 2 takeover script sooner or later will clash.
Not necessarily. As long as i know "who is invading what" i can make sure that PG stays out of the area to avoid unwanted events (or better, react accordingly). That's something that can't really be determined otherwise.

Of course it's not a perfect solution, but it give at least a common ground.
....And I love simultaneous invasions
this is where things are getting interesting Blood! Carnage! Crahes!
That's also why i'm proposing this. With such list, if plugin X know how to handle invasions from plugin Y it can react accordingly, otherwise it still knows it should stay out of the said sector :)
The basic structure looks fine to me, but perhaps the sector array should be a 2D array, indexing every sector by x,y coordinate. With that method, there is no searching through the array, so it's potentially faster. Though for basic use with a small array, it probably wouldn't make much speed difference.
I've not thought about the 2D array, tbh. I rarely use them.

Speedy finding is balanced by the fact that you need to ask for the coords of a sector first (and retrieve the sector and check its existence the other way around). Like you said it's not like the array will be overloaded, with around 12 races in the universe if we include Race1 and Race2, it shouldn't go beyond that size (except for plugins attacking several sectors at the same time). And it's not something that will be called every few seconds anyway :p

But yeah i may use this method to store the data.
http://forum.egosoft.com/viewtopic.php? ... 59#3376459

this is bit different thing, but I'm thinking if this could be connected somehow.. hm. It could be extended by 4th array, yet general idea was that scripts should not mess with this array so everybody will know its safe to use this information.
I think djrygar's "backup" array could be incorporated into this, to store the original vanilla owner and have a plot protection flag.
That's where we go from a "hey guys i locked this sector" simple library to the first step of a full fledged "faction handling framework". Not that i've something against that, not at all, but one step at a time is a better approach.

Yes, the library could/should keep the "original map" in a nice array, with core/border properties. However, i don't see why it should include any kind of "plot protection", that's the business of each plugin imho (who, in his right mind, is going through the plot while IR or RRF or whatever is installed with takeover enabled anyway? :mrgreen:)
But it would be good to have some kind of sector takeover library to do common functions like spawn suppression, reversion to vanilla owner, intelligent station repopulation, plot protection, etc.
I know there's a lot of talks between you these times on that matter (yeah i wasn't able to resist browsing the web a little during holidays, shame on me), but it's off topic here :)

I'm writing such framework for my plugins, but it will be more permissive than that (granted i finish it before tnbt) and use the lock system we're discussing. But i'll probably keep the takeover and station building out of the system.
after bit of thinking.. actually I already have separate script that tells me if I am allowed to invade given sector..so this should not be so much trouble. I can just add another array to check. Well, then no problems from IR's side.
I'm asking nothing more than calling a script before attacking a sector and another one post invasion :)
but what if some script permanently sets a flag and goes boom ? (reinstall, crash, bug etc) Then this sector will be locked forever for others..
what ThisIsHarsh said.

Of course it's not 100% fail-safe as users have creative ways of breaking the game. But nothing prevent from adding another script that will look for every occurrence of plugin X, remove them from the array, and restore the original sector owner while at it.

Not a major issue, especially with AL plugins imho (as long as it's implemented correctly).

--

The few scripts that will be needed so far:
(i may have missed something here)

plugin.sk.sector.islocked($sector)
Check if a sector is locked
-> [FALSE] : $sector is available
-> "global var" : if $sector is locked.

plugin.sk.sector.lock($array)
Locks a sector
-> [FALSE] : no such sector / already locked / whatever
-> [TRUE] : sector locked

plugin.sk.sector.unlock($sector,$global)
Unlocks a sector
-> [FALSE] : no such sector / wrong global
-> [TRUE] : sector unlocked

plugin.sk.sector.restore($sector)
Forcefully restore a sector to 'vanilla' ownership
-> [FALSE] : no such sector
-> [TRUE] : sector reset to vanilla ownership / security

plugin.sk.sector.clear($global)
unlocks all sectors from plugin $global
-> [FALSE] : nothing found
-> [TRUE] : at least one sector has been unlocked
Last edited by Serial Kicked on Wed, 1. Sep 10, 08:30, edited 2 times in total.
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

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

Post by ThisIsHarsh » Wed, 1. Sep 10, 08:26

OK, I concede, the idea of a sector takeover library was a bit of wishful thinking. A bit too much work to expect someone to do properly in a truly modular cross-script compatible way. Maybe I'll come up with something others can use in the end anyway.


Those locking scripts sound fine to me. Nice 'black box' implementation abstraction, rather than accessing the array(s) directly. Plus, extensible if further flags need adding. Sounds good to me, sign me up.
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
Trickmov
Posts: 1432
Joined: Wed, 7. Nov 07, 20:48
x3tc

Post by Trickmov » Wed, 1. Sep 10, 09:25

Hm, I don't know, if I am the right person to say something to that. STO is no invasion script, but "only" sectorovertaking for the player. While I understand the idea to lock a sector for different invasion-scripts, I don't see a reason to include this into STO, as there would be a lot of players asking me, "hey man, why can't I overtake that sector?".
Also the other way around - hey, why did STO lock this sector? Pretty useless, as whenever the built player-tradedock is destroyed, the sector will go back to it's original owner anyway - thus a "normal" conquering of the sector with destroying all stations first, will lead to STO setting back the ownership and after that there will be no issue.

However, there is one possible problem with STO when the player has installed one or several invasion-scripts:
As soon the player overtakes that sector, STO will store the current owner of the sector, regardless, if that is the real owner or that of an invasion-script (with setting it back to that owner in case of uninstall or loosing the sector). Additionally the invasion-script may have also some problems with spawning ships in the sector or still having it in it's arrays.

So, after all I think the idea of locking is not the right way. Instead I propose to use a couple of scripts, which handles these arrays:

a) array of overtaken sectors
b) original owner of the sector
c) which script should be informed, that the sector has been interfered with. There is a command "call named script", which works with strings, that would be ideal for that purpose.


Thus in the end, any script that tries to overtake a sector checks these global arrays.
- is the sector in there, c) will be informed and the overtaking can be done without problem, adding the new information afterwards
- is the sector not in there, just add the informations.



However, I am still having one problem with STO then - as long a player tradedock exists in that sector, STO will overtake the sector on it's next cycle (in principle directly).

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

Post by djrygar » Wed, 1. Sep 10, 14:21

Serial Kicked wrote: Yes, the library could/should keep the "original map" in a nice array, with core/border properties. However, i don't see why it should include any kind of "plot protection", that's the business of each plugin imho (who, in his right mind, is going through the plot while IR or RRF or whatever is installed with takeover enabled anyway?
well, core/borders is something I forgot about, I shall include it.
anyway, you need plot protection. For example Hub plot takes a lot of time to complete, then unlocks next ones. If you want users to disable half of your plugin until they finish plots, then there is no point in using it, flankly, unless you aim directly at RTS approach with custom map (in this case other plugins should be even banned)

I play ALWAYS plots with takeovers enabled. Makes every game different and interesting. You should play sometimes instead of scripting :D

when I think more of this..
actually telling other scripts that you are going to attack something kinda contradicts with what you said once about relying on game-state. To know that given sector is under attack, you should drop patrols there. And decide for yourself if it's danger or not. You can release reconnaissance/scouts to other sectors to scan for incoming enemies if you want. Checking array is cheap :D

only sensible reason to put information about targeting some sector would be performance - meaning if one or two scripts decide to attack the same sector and it could end with 5 fleets fighting there (possible crash). In this case this common-array should look bit different

'backup/plot' array I proposed is more a tool you could use to avoid problems caused by Mission Director, not other plugins (as missions have hardcoded sectors, stations etc). It has nothing to do with IR itself except fact that it already uses it and it could be used by others for the same purpose. It's not exactly aimed at script compatibility. It is named 'plugin.ir.*' but I am not personally attached to this prefix ;) and frankly it should be changed to not confuse. We need just beg Ketraar or kliaden to make base MD for it (I had some experience with MD but for such thing I think we'd need well written MD, but even simple reworking of his 'plot skipper' will do)

what COULD work is common takeover array - this is something worth pursuing; different scipts can have different rules, what requirements have to be met to claim sector. I am not even sure if those should be common or not (that touches topic of differences between script and what makes them unique)

interesting topic anyway, could be renamed to Takeover Caffe Corner :D

User avatar
Serial Kicked
Posts: 3493
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Thu, 2. Sep 10, 04:40

Those locking scripts sound fine to me. Nice 'black box' implementation abstraction, rather than accessing the array(s) directly. Plus, extensible if further flags need adding. Sounds good to me, sign me up.
Roger. I'll start writing the lib. But I'd like the input from LV and LiteCube also, just in case they have special needs related to this. I'm pretty sure it will work for RRF, but i don't know about revelation and phantom, never studied the code behind those two.


@Trickmov:

In short, no, that lib is definitively not designed for your script. The goal of the lib is to tell others "hey there's an invasion going on in that sector, come back when the sector is conquered (or not)".

Moreover, you can't possibly lock a sector before the player start to invade a sector because you can't monitor him as we can monitor our troops/factions. That's also why i've not cited your name in the original topic. It's no big deal as the user usually know when a plugin is already attacking a sector as we're kind enough to warn him in a way or another.

well, core/borders is something I forgot about, I shall include it.
anyway, you need plot protection. For example Hub plot takes a lot of time to complete, then unlocks next ones. If you want users to disable half of your plugin until they finish plots, then there is no point in using it, flankly, unless you aim directly at RTS approach with custom map (in this case other plugins should be even banned)

I play ALWAYS plots with takeovers enabled. Makes every game different and interesting. You should play sometimes instead of scripting
I said someone in his right mind, not someone who think that TC is something else than a development platform :mrgreen:

Nah more seriously. In fact, nope this lib doesn't need it, it's out of the scope. BUT you need it, and others too, and as I now realize the system described above could very well be used for plot protection too without any modification, why not.

The lib just has, on new game, to determine if it's a vanilla map, and if so, it add the list of protected sectors to the array.

Code: Select all

$plot.sector = Array, alloc: size=2
$plot.sector[0] = Unknown Xenon Sector
$plot.sector[1] = "plot.protection"

call script 'plugin.sk.sector.lock' arg=$plot.sector

(and do the same for each plot protected plugin)
So, when a plugin ask if the HUB sector is available for conquest using "plugin.sk.sector.islocked", the lib will tell him to find another sector.

Here you go, plot protection, without the need for an additional array :)
Consider that done (well, included in first release). You'll have to provide me with the list of plot sectors.
actually telling other scripts that you are going to attack something kinda contradicts with what you said once about relying on game-state. To know that given sector is under attack, you should drop patrols there[...]
Hehe. Well, it still relates on game state granted you're not playing with the library to f*ck with other scripts' logic :p. Yes it's probably cheaper than patrol ships which try to determine what's going on (and nothing prevent THEM from checking the array when a nearby sector is full of 3rd party ships).

But the final effect is the same, it saves a lot of CPU, and ensure a better compatibility. The pros outweighs the cons. And TBH, the only other valid solution is to find what your plugins are doing is to pick in your own arrays (different for each plugin, may change from a version to another, etc.).
interesting topic anyway, could be renamed to Takeover Caffe Corner
The topic was supposed to be renamed something like that instead:

[Library] Temporary Sector Locking v1.00

But, yes I guess I could let you guys go wild (as i apparently can't prevent you from doing it anyway :p) with your "common sector takeover system" and create a new release topic when done with the lib.

Just 2 words on that matter:

- I'm not gonna use a 3rd party takeover script/lib myself no matter how good it is. I've my reasons for that, one is that none of my scripts will use the same method to take over sectors. F:AI related factions will use their own stations/ships, completely ignoring what the game will spawn or not (yes it's designed to be used on a blank map). The invasion itself won't be based on stations. PG will use something somewhat similar to STO (kill the Trade Station, build a PB) but will be limited to border sectors around pirate ones. YA will be fleet based only, etc.

- There's no incompatibility with your idea(s) and this lib, it's rather complementary tbh. You use whatever method you want to takeover sectors and log them (or not) even a common lib, but you could still use this lib for keeping track of the original map, of protected sectors, and telling others that an invasion is going on.

- There's also a few unrelated usages that could be made out of this library. As an example, a 3rd party script could allow the player to protect his sector(s) from invasions for a fee.

I now realize that i should have let the word "takeover" out of the title (it was here to drag your attention in the first place :p). But it's a bit too late for that, so yes, if you want to continue the discussion on sector takeover issues, feel free to proceed (i'll follow it anyway) :)
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

User avatar
Trickmov
Posts: 1432
Joined: Wed, 7. Nov 07, 20:48
x3tc

Post by Trickmov » Thu, 2. Sep 10, 09:23

Serial Kicked wrote:
@Trickmov:

In short, no, that lib is definitively not designed for your script. The goal of the lib is to tell others "hey there's an invasion going on in that sector, come back when the sector is conquered (or not)".

Moreover, you can't possibly lock a sector before the player start to invade a sector because you can't monitor him as we can monitor our troops/factions. That's also why i've not cited your name in the original topic. It's no big deal as the user usually know when a plugin is already attacking a sector as we're kind enough to warn him in a way or another.
Ok so far... could we then all agree to two points:
a) before the invasion-script overtakes a player-sector, destroy at least all player-tradedocks
b) wait until the ownership has gone back to the originalowner - this takes not more than a few seconds

If STO overtakes an invaded sector I will look, if this sector is in your global arrays and reflect that - but there is nothing I can do about your script having the sector still in it's arrays.

User avatar
Serial Kicked
Posts: 3493
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Thu, 2. Sep 10, 18:15

Trickmov wrote:Ok so far... could we then all agree to two points:

a) before the invasion-script overtakes a player-sector, destroy at least all player-tradedocks
b) wait until the ownership has gone back to the originalowner - this takes not more than a few seconds

If STO overtakes an invaded sector I will look, if this sector is in your global arrays and reflect that - but there is nothing I can do about your script having the sector still in it's arrays.
a) No problem for me. You'll just have to be a bit more specific. By Trade Dock, do you mean Trade Stations + Eq Dock + Shipyard (the "Dock" class) or something else?

b) Oki, i just need a global variable used to check if STO is currently installed or not.

Another question, what happen if I change the ownership of the player owned dock instead of destroying it ?
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

User avatar
Trickmov
Posts: 1432
Joined: Wed, 7. Nov 07, 20:48
x3tc

Post by Trickmov » Thu, 2. Sep 10, 18:33

Serial Kicked wrote:
a) No problem for me. You'll just have to be a bit more specific. By Trade Dock, do you mean Trade Stations + Eq Dock + Shipyard (the "Dock" class) or something else?

b) Oki, i just need a global variable used to check if STO is currently installed or not.
a) Just tradestations, HQ and HUB at STO. Don't know what the other scripts use.
b) use "STO.Page.ID", in case of uninstall that's becoming "FALSE" again
Another question, what happen if I change the ownership of the player owned dock instead of destroying it ?
Hm, interesting question... I think it will go on working as if nothing had happened - but I could add this easily into the script, so that the destruction is not necessary. BUT: There could be the case, that the player has several tradedocks in that sector, thus you would have to change the ownership of all of them.
Last edited by Trickmov on Thu, 2. Sep 10, 19:00, edited 1 time in total.

Post Reply

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