[Discussion] Generic X3TC S&M questions II

[mark_a_condren]

SlapNTickle

<RetVar> = get index of <Value> in array <Var/Array> offset = <Var/Number> + 1

Returns the position of the element <Value> in a specified array <Var/Array>. This position can have a specified offset <Var/Number> +1

I use this to find the position of something in an array if i want to remove just that one element from the array.

Say i have an array with all the Bio wares in it and i want to remove Argnu Beef from it.

($Argnu.beef is a variable set to Argnu Beef for arguments sake)

$index = get index of $Argnu.beef in array $Bio.wares offset = -1 + 1

remove element from array $Bio.wares at index $index

I started doing an updated MSCI handbook some time ago, but as i am FAR from proficient in most of it i asked for some help with the bits i didn't know from those who did. I got ZIP help from any of them. Out of the 10 PM's i sent i got 1 reply "sorry to busy". Those who know want to keep the info for themselves. So far the document is far from complete but upto 100 pages and rising. It does have ALL the TC new commands listed though and in what section they belong to.

MarCon

[s9ilent]

It has *most* of the TC commands, most of the newer ones haven't been added yet (I added some with v 2.1 but I haven't done any scripting since then, so I don't know if it has any of the 2.1+ commands)

[Guest]

if you tell me which commands have no info for them, ill help out. whilst i dont understand alot of the very advanced general commands, i have experimented with many of the other commands.

[s9ilent]

A random thought occurs to me.....

I have been getting .. frustrated at having to write polling scripts for X3 due to my perceived lack of events in x3scripting but then I realized, hold on, signals are events.

And then I thought, wouldn't it be awesome if there was a script lib that could allow you to
1. Have fire "events"
2. Thread lock (and release, and change a scripts priority who is waiting for something to unlock)
3. When complete, fire unlock, fire start next

My idea to achieve this is to create a dummy object, "some where" (e.g. sector null - although, people some times clear that sector... so maybe somewhere else -xenon hub if exists?), and just keep attaching secondary signals on that.



Do you think this script lib could be useful? (is it worth scripting it?)

[Gazz]

With the exception of using "real" signal events, like a ship getting destroyed, how is that different from polling?

The Mission Director is completely "event driven" but if you have too many conditions waiting to fire without slowing down their polling frequency, then you get the same script overload effect (slowdown) as if you were polling quickly using the script editor.

Apparently the MD does not have a way to magically check conditions without using CPU time to do so.
I was toying with the exact same thought. Using the MD to cheaply and flexibly check for events/conditions.
And it doesn't work. There ain't no such thing as a free lunch.

If you want to use a signal, you can attach a signal to the relevant object.
Signals only fire on the actor they pertain to.
And always on task 0 if I'm not mistaken.

If there's already a Prio 100 (signal) script on that task, another Prio 100 interrupt/signal will bounce.
Normal script interrupt rules.
That's why a ship that is under attack never switches targets. It's already running the Prio 100 "defend" script so any other, that would change the target yet again, will bounce.

What exactly would be the advantage of a control actor doing the polling over the "real" actor's watcher script doing the polling?

[Cycrow]

A random thought occurs to me.....

I have been getting .. frustrated at having to write polling scripts for X3 due to my perceived lack of events in x3scripting but then I realized, hold on, signals are events.

And then I thought, wouldn't it be awesome if there was a script lib that could allow you to
1. Have fire "events"
2. Thread lock (and release, and change a scripts priority who is waiting for something to unlock)
3. When complete, fire unlock, fire start next

My idea to achieve this is to create a dummy object, "some where" (e.g. sector null - although, people some times clear that sector... so maybe somewhere else -xenon hub if exists?), and just keep attaching secondary signals on that.



Do you think this script lib could be useful? (is it worth scripting it?)

my Advancaed Navigation has something abit like that.

it replaces some of the built in scripts and has a kind of event system for them.

so when a script calls modified !move.movetosector for example, Advanced Nav will fire the move to sector event, any scripts that have been registered for that event are run in order of thier set prio until one of them completes the task

[s9ilent]

I find that polling gets messy, and then I have to worry about the waits, and think about what is a sensible wait time etc.

The implementation I want it for is:
I have a "dowork" script, it has small waits in it and must run only once instace, with many other scripts waiting to enter into it that need to do an "idletask" whilst waiting for "dowork". And all of this is generally easier with events (I hope...)
(And with out waits, it causes noticable ingame lag, so I can't make it run instantly)



@cycrow
Would I be able to take a look at some of your scripts? Which package are they in? I can only find a move to co-ords script under the Navigation script stickies

[sharpneli]

Is there a way for a script to change the location where shots are aimed and sample the location of enemy vessel suitably quickly?

Considering how lousy the standard first order approximation (Assumes that target is flying at constant speed) tends to miss most of the time. In order to improve the hit rate a lot of different techniques have been in use in the real world. I'd like to bring some of the simpler ones to X3. As an example an autoregressive model (basically few simple filters mashed together which is quite cheap computationally) could provide a nasty suprise to some fighters and in addition make an excellent excuse to make a new targeting software.

[Gazz]

There is only one fire instruction and the first order target lead calculation is hardcoded into it.

The other problem is that all such calculations have to run in real time, like once every 100-200 ms for every single turret in the sector.
Heavy math is something the script editor is not very well suited for. (which is putting it mildly)

Nice challenge, isn't it? =)

[Cycrow]

I find that polling gets messy, and then I have to worry about the waits, and think about what is a sensible wait time etc.

The implementation I want it for is:
I have a "dowork" script, it has small waits in it and must run only once instace, with many other scripts waiting to enter into it that need to do an "idletask" whilst waiting for "dowork". And all of this is generally easier with events (I hope...)
(And with out waits, it causes noticable ingame lag, so I can't make it run instantly)



@cycrow
Would I be able to take a look at some of your scripts? Which package are they in? I can only find a move to co-ords script under the Navigation script stickies

http://forum.egosoft.com/viewtopic.php?t=250425

also, my advanced jumpdrive script makes use of it as well, hooking up the FTL drive into the movement commands

[sharpneli]

The other problem is that all such calculations have to run in real time, like once every 100-200 ms for every single turret in the sector.
Heavy math is something the script editor is not very well suited for. (which is putting it mildly)

Shame. With good implementation the code would have to run only once per each ship by simply calculating the predicted future place of the ship and the firing code of each turret would simply ask where to shoot.

As for the difficulty of the math a second order calculation would require only few more multiplications and additions as the first order.

I presume it's certain that the possibility of getting access to the targeting code (And hey, while we're at it the flight AI for upgrading your ships. Think of the possibilities of community flight AI programs) is nigh zero. Ah well one can always hope

[cheezy379]

Ok, so ive finaly come around to trying some stuff out and got confused straight away , its supprising how often I get confused.

I've tried this walkthrough to no avail http://forum.egosoft.com/viewtopic.php?t=261816

I also looked at the other but I didnt want to download the tool.

Is it possible to create a custom menu without downloading the tool? As in just through the in game scrip editor? Or is that my problem all along lol.

Thanks guys.

[s9ilent]

@sharpneli Even if you took it to the second order (I'm assuming you mean just in terms of x-y-z), you would be totally ignoring the affects of rotations and rotational acceleration, which is a large component of why ships can evade projectiles.
Further more, the projectiles are modified by the vector the firing ship is going (as well as the vector it's firing at)
You have to remember that in a 3 dimensional world, you can actually move in 6 directions (along the 3 axis, and rotate along at least 3 axis)
Also, as you move to the second order, you start to depend more heavily on squared and squared root functions, and given that the script engine only run's with int's, this is unlikely to happen.



@ cheezy379
Yes you can just use the script editor
If you look at the other stickies you can find other materials on it (There is a nice pdf floating around)
You an also try the MSCI guide book on Xai Corp

[Kitarn]

Small question. How hard would it be to set up a script to check the name of a station and append the next designator for stations of the same class so that every station you build isn't '<station> alpha' when Betty tells you what you targeted? As just changing the name doesn't work. Where would I look to find how the game set them up for the NPC stations in systems? (alpha, beta, delta, gamma, etc)

[Gazz]

Shame. With good implementation the code would have to run only once per each ship by simply calculating the predicted future place of the ship and the firing code of each turret would simply ask where to shoot.

As for the difficulty of the math a second order calculation would require only few more multiplications and additions as the first order.

Why don't you give it a try?

[xiriod]

I've been at it for a long time, and I might not see the forest for all the trees here. I'm working on a rather large script, too much code to paste.

Basically I have $station and I want $station.sector = $station -> Get sector to contain the sector name where the station is located.

When putting these two lines in a lone script, it works. But when I have them in the larger one it returns null

Before I might describe anything else, is there something obvious I have forgotten here?

[s9ilent]

@xirod,

Print the $station the the log book, I suspect that it is probably null
(Either that or it actually is in sector null, thou it is unlikely)

[xiriod]

@xirod,

Print the $station the the log book, I suspect that it is probably null
(Either that or it actually is in sector null, thou it is unlikely)

That's what I did, and yes it says null, which is why I am here in the first place

But as I said, if I just put those two lines alone in a new script it returns the correct data. But inside my larger script, nothing....

[mark_a_condren]

xiriod

Can you post the section of code were you cycle through the stations in an array or how you get the station value.

MarCon

[xiriod]

Here's a snip from the preload script:

Code: Select all

$station = [THIS]->get user input: type=[Var/Station], title=null

....snip

$return = create new array, arguments=$station, null, null, null, null
return $return

Then main script:

Code: Select all

....snip

$station.sector = $station ->get sector

....snip

There is only one station, the one you select when executing the command.