.:: Bots United ::. - View Single Post

TomTom · **Re: breakout_et_b2 navigation -** 17-04-2008

the
//the fake toi
faketoi1 ...
is just a standard empty scriptblock. CrapShoot wanted (and I concur) that entities scripted in should have the basic OOPs style support as it were to deallocate instances afterwards. It is just good practice, not that they are needed.

The stability issues seem to be related to the trigger_objective_infos (tois), rather than the func_explosives. Since the game code is in C there is a good chance that someplace there is a data stucture with a fixed size related to tois (such as that which communicates server to client) that limits the tois more so than the func_explosives (which are used in many places in a map).

You can get around this by using just one toi with a fake construct to trigger an update in the aiscript in the fake construct block. The func_explosives are not targeted by any tois in this case. Then inside that fake construct action you test for the state of all the func_explosives.

If you look at most of my later waypoints that have vehicles (eagles, v1rocket...) you will find that I have combined multiple func_explosives with one or two toi-constuct pairs. Then in the script after the alertentity on the func_explosive entity there is an immediate construct of the fake construct entity. The two limitations on this form are; (1) the 64 keyword limit in an action test block is easy to exceed since most every command line is prefixed by a 2 part test of whether one point has exploded but not the next point in the vehicle path and (2) nuisance too many connection warnings for node_connect commands sometimes when reusing the fake construct for other updates (but there are workarounds).

BTW In Transmitter Craig skipped the tois for the func_explosive and did not use the toi-construct pair and it seemed to work (with separate event_explode action tests), whereas in at least one map when I tried that the aiscript was not updating in a timely fashion.

Like most C when you leak you access/destroy nearby data structures, so you will know it when it happens by the mess it makes.

	(#14)
TomTom ET Waypointing team member Status: Offline Posts: 745 Join Date: Jun 2006	Re: breakout_et_b2 navigation - 17-04-2008 the //the fake toi faketoi1 ... is just a standard empty scriptblock. CrapShoot wanted (and I concur) that entities scripted in should have the basic OOPs style support as it were to deallocate instances afterwards. It is just good practice, not that they are needed. The stability issues seem to be related to the trigger_objective_infos (tois), rather than the func_explosives. Since the game code is in C there is a good chance that someplace there is a data stucture with a fixed size related to tois (such as that which communicates server to client) that limits the tois more so than the func_explosives (which are used in many places in a map). You can get around this by using just one toi with a fake construct to trigger an update in the aiscript in the fake construct block. The func_explosives are not targeted by any tois in this case. Then inside that fake construct action you test for the state of all the func_explosives. If you look at most of my later waypoints that have vehicles (eagles, v1rocket...) you will find that I have combined multiple func_explosives with one or two toi-constuct pairs. Then in the script after the alertentity on the func_explosive entity there is an immediate construct of the fake construct entity. The two limitations on this form are; (1) the 64 keyword limit in an action test block is easy to exceed since most every command line is prefixed by a 2 part test of whether one point has exploded but not the next point in the vehicle path and (2) nuisance too many connection warnings for node_connect commands sometimes when reusing the fake construct for other updates (but there are workarounds). BTW In Transmitter Craig skipped the tois for the func_explosive and did not use the toi-construct pair and it seemed to work (with separate event_explode action tests), whereas in at least one map when I tried that the aiscript was not updating in a timely fashion. Like most C when you leak you access/destroy nearby data structures, so you will know it when it happens by the mess it makes.