Cool Pog Tricks

A new thread for posting bits of pog or mod info that might be handy for others.

Here is my entry:

Suppose you want to create something like a deathscript. TroutDeathScript(hship dying_ship);

This function gets attached to a ship and will be called when some handler task notices the ship is dying.

Like so: Task.Start("tTrout.TroutDeathScript");

The only problem is Task.Start does not allow arguments. So there is no way to tell the deathscript what ship is dying.

I had an idea for passing arguments to tasks, and it works. Code is below. Basically, the task is started inside an atomic statement (so it cannot execute), then a state variable is created for the task and properties are attached to the state variable. Then the Atomic block ends and the task is allowed to find the state variable and collect its arguments.

-Gtrout

I did some performance testing to support the chessboard work. If each station gets a defense fleet on the chessboard, then that could be roughly 30 systems with 100 stations, or 3000 fleets.

I created 3000 tasks that all looked for the player each second. There was about a half a ms delay added to the game tick. I jumped 10 - 12 ms delay by just swinging my view to include a station. I think pog render time for tasks will be a small worry.

(now I just need to prove that all 3000 are running).

-Gtrout

Originally posted by GrandpaTrout

A new thread for posting bits of pog or mod info that might be handy for others.

Here is my entry:

Suppose you want to create something like a deathscript. TroutDeathScript(hship dying_ship);

This function gets attached to a ship and will be called when some handler task notices the ship is dying.

Like so: Task.Start("tTrout.TroutDeathScript");

The only problem is Task.Start does not allow arguments. So there is no way to tell the deathscript what ship is dying.

I had an idea for passing arguments to tasks, and it works. Code is below. Basically, the task is started inside an atomic statement (so it cannot execute), then a state variable is created for the task and properties are attached to the state variable. Then the Atomic block ends and the task is allowed to find the state variable and collect its arguments.

Code:

// Called when the b key is pressed by the player. StartAction() { htask new_task; hstate new_state; debug Debug.PrintString("Test Task\n"); atomic { new_task = Task.Start("tTestTask.Tester"); new_state = State.Create(new_task, 1); Object.AddStringProperty(new_state,"New Name","Hi Mom"); } Task.Detach(new_task); } task Tester() { hstate state; string name; state = State.Find(Task.Current()); name = Object.StringProperty(state,"New Name"); debug { Debug.PrintString(name); Debug.PrintString(" the mission name\n"); } while (1) { Task.Sleep(Task.Current(),10.0); } }

-Gtrout

Why not simply add the properties to the task itself?

You can do that? I assumed no, since the state package was provided. Hmmm, wanders away in search of a compiler.

-Gtrout

Hmmm, a candidate for SoupDragon to try out sticky threads?

Object properties work on any handle. I think they're just globals with a reference to their parent's id in their key, but that's idle speculation.

Can't think of any cool tricks; are caveats ok, or should they be in another thread?

Not sure if it's too obvious to need highlighting, but complex data types (list, set and string) are passed as pointers. This isn't without potential uses, but can break stuff if you don't bear it in mind. The simple types are copied.

Caveats are especially welcome - cause they eat hours of time.

Here is one. Lists can be passed between threads. Groups CANNOT. Groups only exist in one threads address space. Somehow lists cross. [edit] Groups can be passed to tasks as arguments. But it turns out to be a copy, because updates never cross.[edit]

I also find that passing groups into the iAI.SpecificAttackOrder is a sure way to fault Flux. I think it happens when my combat handler thread exits. The thread memory must go invalid, taking the group with it. The iAI code must not like invalid handles. Not sure how to deal with that, beside not using groups, or never letting the thread exit. We will need to be careful that any shutdown code locks everything atomic before halting.

-Gtrout