[Discussion] Generic X3TC S&M questions II

[Shuraalex]

How do i fix this?:

http://i297.photobucket.com/albums/mm21 ... n00313.jpg

Edit:
Sorry for this stupid question, i did some digging around and well it turns out its better to delete the EMP package and leave it at that, the Plugin has its own EMP shares
For all those who have the same problem just uninstall the EMP with your Xtended Plugin Manager

[Cycrow]

How do i fix this?:

http://i297.photobucket.com/albums/mm21 ... n00313.jpg

Edit:
Sorry for this stupid question, i did some digging around and well it turns out its better to delete the EMP package and leave it at that, the Plugin has its own EMP shares
For all those who have the same problem just uninstall the EMP with your Xtended Plugin Manager

that would actually fix your problem.
because you dont really have a problem.

the ware lists, like the one on the cheats menu simply displays all wares that are available to the game.
this includes any built in custom and emp wares.

as long as you dont seem them elsewhere, like for sale at stations, on ships, etc
then it should be fine.

however, if u are using the plugin manager, u dont need emp installed seperatly anyways

[SimB]

Hi,

can somebody please help me with modding ships via X3 Editor 2? ^^

I want to mod the Galleon to have more than 2x 2GJ Shields, but they will not install on my ship...
When I look up the ships information in X3TC it says that the maximum amount of 2GJ shields is 4, but the Galleon only mounts 2!

Do I need to clone the ship first?

Hope you can help me...

[The Univerce builder]

If you are loading a saved-game, you should jump out of the ship you are in (I'm assuming that this is the Gally,) fly to another sector to be sure, save, make your change, then reload. for some odd reason TC doesn't recognize changes to the ship the player is in, I'd assume due to the PLAYERSHIP tag being added. any updates will not take effect if you are flying the ship.

[SimB]

If you are loading a saved-game, you should jump out of the ship you are in (I'm assuming that this is the Gally,) fly to another sector to be sure, save, make your change, then reload. for some odd reason TC doesn't recognize changes to the ship the player is in, I'd assume due to the PLAYERSHIP tag being added. any updates will not take effect if you are flying the ship.

Sadly this didn´t work...

I now downloaded Cycrows Cheat Package and cloned the ship.
Now it has finally more Shields.

Thanks for your help!

[s9ilent]

I had this idea whilst I was doing my Silverlight programming, currently the sort of scripts we see in x3 are rather... well code wise, they are rather basic in that they lack the sort of neat tricks that you see in ... other...?? code.



So I thought it would be a good idea if we all listed a few things that could be done in X3 scripts (thou I don't really script all that much for x3 any more.. so this is more for other people)




So, my neat tricks are:


1. Lazy Loading / Lazy Loaded Variables
Basic idea is to create variables as late as possible, instead of right away. The most common usage of this is in AL Plugin scripts / some other global variable scripts.
Pro's: As long as you "get" the global variable with this code, it ensures the global var is never null. Slightly more memory efficient
Con's: Slightly less CPU efficient. Have to use this code to "get" the global variable.


Rather than having a setup script go create some arrays for you, instead, on each and every run, you check if the variable exists, if not create then it.
(Note my correct usage of than and then )

e.g.
002 $al.state = get global variable: name=$al.PluginID
003
004 if not $al.state
005 |$al.state = = array alloc: size=2
006 |$al.state[0] = $version
007 |$al.state[1] = [TRUE]
008 |set global variable: name=$al.PluginID value=$al.state
009 end


e.g. You might make a script to LazyGet some variable? (or a gosub, or just stick the code in directly)





2. Asynchronous tasks
(Wiki Asycnchrony if your unsure of what this means)

Basically, if you need to "do work" rather than doing work on yourcurrent task (e.g. the main autopilot) , you will do the work somewhere else, allowing you to continue using the task 0 for other things.

e.g. Rather then your ship sitting still whilst it is computing something, it will send the task else where, and it can continue flying.

Issue: Doing the callback, will require replacing your task 0. So rather then going
task 0 -> task 100+ DoWork
Task 100 on complete, -> task 0 do, on Work_Completed
You will need to do some sort of check, to see if task 0 SHOULD be replaced by the on Work_Completed.

Pro: Free up the current task. Can allow multiple separate tasks to be run concurrently. Separate your thinking and doing
Con: More complex (Probably more CPU intensive). Call back script will probably should replace the task 0 on complete. Obviously is not beneficial to things that need to be run synchronously.

e.g. In my trade scripts picking the next ware to trade is a time intensive process. Rather then blocking the auto pilot, the auto pilot should continue whilst it is busy thinking.





Hmm... dam.. could've sworn I had a third neat trick before... Oh well...

*edit* ok a third trick, not really from out side sources, but specific to X3.
If you have a global loop script, pretty much it will never update it self.
So if you ever plan on making changes to it, it is best to have 1 global loop script that you never change that just calls another script.
(Each time you call a script, it will use the latest version of it)

e.g.
I have a "global" loop script that does this:


016 while [TRUE]
017 |inc $min =
018 |skip if $min <= 60
019 ||$min = 1
020 |
021 |@ START = [THIS] -> call script 'plugin.sfm.global.loop.actual' : Minute=$min
022 |@ = wait 60000 ms
023 |
024 |$global = get global variable: name=$scr.var.run
025 |skip if $global != 'uninstall'
026 ||break
027 |
028 |$time = = playing time
029 |set global variable: name=$scr.var.run value=$time
030 end

So in this case, my actual "do work" in the loop plugin.sfm.global.loop.actual is ALWAYS the latest version. and I don't need to cancel this task and start a new one, or anything like that.

- Oh I would also recomend not doing what I've done... mixing variable data types for the same variable... ($global = string and int depending...)

[Gazz]

Rather than having a setup script go create some arrays for you, instead, on each and every run, you check if the variable exists, if not create then it.

What's the advantage over a setup script?
When loading a game all setup scripts are executed in sequence before any other script can run.
That solves all initialisation issues far more efficiently than using multiple lines or even a script call for every single GET.

Setup scripts can also easily alter the format or dimension of a config array when it needs to change for a new script version.
Adding this updating code to every single script that accesses the array seems overkill to me.

If you have a global loop script, pretty much it will never update it self.
So if you ever plan on making changes to it, it is best to have 1 global loop script that you never change that just calls another script.
(Each time you call a script, it will use the latest version of it)

With this way you still have the calling script that is stuck forever and will never be updated.

Try:

015 $validate = last load time
016 while [TRUE]
017 |@ = wait 60000 ms
018 |$test = last load time
019 |skip if $test == $validate
020 |return null
021 |
022 | * do stuff *
023 |
024 end

The setup script simply starts the global script every time and the old global script automatically goes poof because it knows that it's from an older start.
You don't even need any way to clean up such a global script for an uninstall script. It automatically goes poof in any case so you never ever have unwanted or outdated global scripts hanging around.

[ScRaT_GER]

Rather than having a setup script go create some arrays for you, instead, on each and every run, you check if the variable exists, if not create then it.

I wouldn't say that this should be done everywhere. There are some places where I use that technique, i.e. if some object needs a local variable, which has some default value.
Instead of doing this:

Code: Select all

= [THIS] -> call script 'initialize.this.local.variable': object=$object

I say:

Code: Select all

if not $obejct -> get local variable: name='XYZ'
  $object -> set local variable: name='XYZ' value=$default
end

Since by far not every object has that local variable, I'm better of this way than using some setup script.

However MSCI is not a real programming language, so paradigms like lazy evaluation from other "real world" languages are not always suitable.

What I really encourage however, is not to initialize variables somewhere way at the beginning of the script and then use it just before the end. This doesn't help readability.
Also, give your variables meaningful names. It's not that creating new named variables would cost the SE terribly much time, so if time is'n really, really, really a factor, don't use $dummy or $tmp everywhere.
I used to do that quite a lot, but it doesn't help understandability at all. If you cannot think of another name than $dummy you maybe should overthink your design anyways.

With this way you still have the calling script that is stuck forever and will never be updated.

Under the premise that the calling scripts never changes this is equally good to yours, I think.
In all other cases, your approach works better.

Greetings,
ScRaT

[Gazz]

Under the premise that the calling scripts never changes this is equally good to yours, I think.
In all other cases, your approach works better.

Mainly it's a very simple and sturdy mechanism that cleans itself out out of the system if the user goes crazy with deleting script files.
There are cases where this approach can be suboptimal, especially if the user manually "refreshes script cache".
That would spawn multiple global script with the same valid LastLoadTime.


If that's a serious issue it can be fixed by altering the LastLoadtime to a global variable that is seeded with a 10-digit random number by the setup script.
The GV is re-seeded and the global script started with that number as an argument.
If the value in the GV should change from the starting argument, the script terminates.

This by itself is not an ideal solution, either, because the global script keeps running if the user deletes all script files... so the setup can not seed a new number.

If you want to make everything extra solid, you use both ways.

Ok, quick Q re your post in S&M about stopping global scripts. The method you showed is good and works great. I just wanted to know if there is a reason you don't check to see if the 't' file has been removed instead.

You could indeed check for a case of the TFile being deleted but the scripts being left operational.
Personally I think it's unlikely that someone would "uninstall" a script like that but it doesn't hurt to make extra sure in case the user has screwed up the installation.

However, I check for the TFile in the setup script because such a thing only needs to be checked once for a script package.
The new global script would not be (re)started in such a case and the script as a whole would shutdown peacefully.
That removes redundant and reoccurring checks from a global script and saves a little CPU time.

[Carl99]

Ok i have 3 questions:

1. if i wanted to modifiy a station so that GoD won't touch it what file do i need to acess?

2. i've recently learned there are several things i can do via script more easily than via modding. A kind user even PM'd me the text of a script. But i have no idea how to get it into game or anything. Is there a "101 gyuide to scripting for novices" thread or similar lying around anywhere?

[Gazz]

Just a wild guess but maybe "disable ship rebuild" will help.
It prevents asteroids from respawning after destruction.

[ScRaT_GER]

1. if i wanted to modifiy a station so that GoD won't touch it what file do i need to acess?

Remove it from the map file and build it yourself via SE or MD, then GoD won't touch the station.

Greetings,
ScRaT

[Carl99]

I'm wanting to do the whole of terran and aldrin space so manually doing it probably won't be helpful.

Just a wild guess but maybe "disable ship rebuild" will help.
It prevents asteroids from respawning after destruction.

Yes but which file? I'm not sure where the data relating to stations and their respawn characteristics is stored atm. Also i'd honestly like them to behave more like EQD's, Shipyards, and Military bases. I.e. they'll respawn if somthing kills them, (say by ramming), but won;t despawn via GoD.

[ScRaT_GER]

Yes but which file? I'm not sure where the data relating to stations and their respawn characteristics is stored atm.

There is not such file. It's all done via the SE:

Code: Select all

$stations = $sector -> get station array from sector
$i = size of array $stations
while $i 
  dec $i =
  $station = $stations[$i]
  $station -> disable ship rebuild
  = wait 1 ms
end

Something like that. But I don't know if it will work.

but won;t despawn via GoD.

That's not possible, afaik. You can of course check, if the station is destroyed an the rebuild it.

Greetings,
ScRaT

[Carl99]

That's not possible, afaik. You can of course check, if the station is destroyed an the rebuild it.

Greetings,
ScRaT

EQD's Shipyards, and Military Bases do it no problem so it clearly IS possibble.

Or is that just a case of me getting lucky in not losing any of them?

[h2o.Ava]

EQD might be using it's own script to respawn them.

[Carl99]

Ahhh, right. Hmmm. Gonna have to have a think on this one then.

Lastly any chance of tha basic scripting tutorioul i asked about please?

[EmperorJon]

Quick Q, what do I require to pack files into a CAT/DAT? I've got ModManager and made some gamestart stuff etc.

[Ketraar]

Modmanager is all you need, although I recommend use the Cat-plugin from the X3Editor 2.

Create new file and name it accordingly, then drag-drop the files to the new catalog.

MFG

Ketraar

[EmperorJon]

So I just have to make a Cat and drag the files in? Ah!


EDIT:

I've just realised there's a Start and a Gamestarts file...