Cool Pog Tricks

Actually it wasn't stations but gunstars that had a station avatar. They were type icShip.

I played around with the following task for the MP game. The purpose was to set a "station" gunstar from neutral to hostile to the players faction whenever a player had fired at it. The task then resets the gunstar to neutral whenever the player is more than 15 km away from it, but everytime he gets within 15 km it goes hostile again. (This never came into actual usage in the MP game because I would need to create a faction dynamically for each player that entered the game). It does however show you a little about how the iShip.Attacked function works:



The debug readout is like this:

SCRIPT: [unknown] WRMOD: sim was attacked: 16779278 ("CMC_Supply", "icShip")
SCRIPT: [unknown] attacked status is: 0
SCRIPT: [unknown] WRMOD: reset to ! shot:
SCRIPT: [unknown] attacked status is now: 0
FLUX: [unknown] Bcast Message "^shot station now hostile"
FLUX: [unknown] Bcast Message "^now neutral at 18 km"
FLUX: [unknown] Bcast Message "^moving in to 15 km"
FLUX: [unknown] Bcast Message "^now hostile at 15.2 km"
FLUX: [unknown] Bcast Message "^moving out"
FLUX: [unknown] Bcast Message "^now neutral at 16 km"

Notes: Bcast Message is an ingame chat message I sent to myself during gameplay to document what I was doing.
(!) Although the script will alternate between hostile and neutral every time you get closer than 15 km, the script only runs through the debug part once because (iSim.Attacked( got_shot ) == true)
is only true once (in this case).

Sorry, but after looking at the code more closely (I did it about a year ago) I notice, that it works by simply alternating the faction and only changes the attacked status once (it doesn't alternate hostility by alternating the attacked status).


Iwar2 Multiplayer Fan Site

Hi Tom, I appreciate your helps very much. Now I have finished the latest improvements over Skull Squadron. You can check out it later.

Life is half spent before we know what it is...

Pog Linker Issue:

The POG linker cannot handle circular dependency between pog packages. This can happen very easily. Say you have a station.pkg
that gets called when the player arrives near a station. The station.pkg calls guard.pkg to create some guards for the station. The guard.pkg calls back to the station.pkg to find out what kind of station it is (so it can pick the proper kind of guards).

station.pkg calls guard.pkg. Guard.pkg call station.pkg. This circular dependency will lock up flux. No error will be reported into the flux.ini file, but the last few lines will be talking about the PDA. Something like this:
The simple circular dependency is easy to notice and fix, but it gets harder to track down when you have 40 to 60 active packages. This kind of linker forces you to use strict hierarchy, where higher level layers call down into lower level layers, but lower levels never call up to higher layers.

There are a few useful tools for breaking the dependencies:

Use global variables to pass information between packages. Or attach object properties to items and share information this way. (This technique is normally avoided, but it can be your only choice.) So the guard package could directly reference an object property on the station to learn the kind of guards it should build.

Use "Task.Call" and "Task.Start" to invoke the function you need. Sometimes it is just impossible not to make a call from a lower layer back up to a higher layer. Because these two calls cannot take standard arguments, you need to use an argument passing convention like the one that starts this forum thread.

The station package could use Task.Call to start the guard code, creating a handle property on the task handle that contains the station it would like guards placed around. The guard code could then call the station code safely without circular link.

The best fix is to use pure hierarcy. A new package is defined called StationDefense.pkg. It calls the station package, and the guard package. The station package no longer needs to call the guard package. And the guard package is free to call the station package. The station package is lowest in the hierarcy, the guard package in the middle, and the StationDefense at the top.

-Gtrout

I find that actual crashes to desktop are rare when writing script. Normally the script dies, but the game keeps running. There are some exceptions, and it is helpful to know of them when you are debugging crashes or lock up problems.

iSim.FindByNameInSystem. If you pass in junk strings to this function, you can sometimes crash the game to desktop. Make sure to only search for items you know exist. Which can be hard in a game where the player is supposed to blow things up.

String.FormatInt. If you hand in an invalid format string (say missing the %d) you can crash the system. Because this function is often used in debugging it is easy to be looking for one problem, and accidentally add a crash with your debug hunting code. All the String.Format calls may have this issue.

Keypress functions, or Button press functions: Some function are always executed in an atomic manner. Meaning that no other code will run until the function finishes. Keypress functions are like this. It is easy to lock up the game by writing functions that loop waiting for something to happen (which never will because no other code can run). Or functions that take a long time to finish. The way to get around this is to start a new task with Task.Detach(start new_task). This allows your task to wait, or do time consuming calculation without locking up the game.

Atomic functions are also used for deathscripts, and some of the early Multimod calls, like EnterSpace.

-Gtrout

Originally posted by GrandpaTrout

The POG linker cannot handle circular dependency between pog packages.
-Gtrout

I find that actual crashes to desktop are rare when writing script. Normally the script dies, but the game keeps running. There are some exceptions, and it is helpful to know of them when you are debugging crashes or lock up problems.

A quick way to crash the game due to interdependencies is in the application of "uses"
Say you have a GUI function that should pass information back to the script calling it:

my_script "uses" GuiFunction_script. That works fine but if you put my_script in the "uses" section of GuiFunction_script the game will crash every time when the linker tries to load: without the slightest indication why

Iwar2 Multiplayer Fan Site

Is there a way to get source code of some iw2 scripts? (iEscort, iFight, iFormation, iLagrangePoint, iWingman and some others) I don't need SDK's headers, but the code logic. No commercial use, of course.