breakout_et_b2 navigation
 

Hello,

I did the waypoints for the breakout_et_b2 map. The url for the archive is here:
http://www.asymmetrics.com/tmp/fritzbot_et_breakout.zip

I run into couple of problems.

1. I had to permanently open the tunnel gate that is controlled by 2 switches and I think the original intention was to add some latency to the objectives so the allies engies had more time to get back and disarm the dynamite. I checked the transmitter script where the antenna rotation could be used in this case but I think it could be overcomplicated for the tunnel door as it is not part of a main objective.

2. There is an opening towards the tunnel where typically the axis team can get via a grate in. Now no matter how I moved the nodes around I could not make the bots reliably get through, so I had to remove the node connections.

3. I changed the main script for the autospawns so the bots will spawn to the right place. Not sure if it's the right way, I had to alert the spawn entities in each case. In some of the testing I did I noticed I could not switch spawns though that is when a team owns the CP.

Have a look let me know what you think. I did some testing so far.

To Tom: Sorry but I have quite some work the last few months so very little time to do the waypoints for other maps.

CK-Chaos

Re: breakout_et_b2 navigation
 

Great to hear from you again. A pretty good waypoint so far as I look at it. A few general points if I may;

(A) Since you are using strict aiscript triggering for actions, all actions should be set as active forever. That way the goal-tracker won't ever interfere with your waypoints (and it will be simpler to debug).

(B) Window camps and other camps with low obstructions are generally best if the bot stands (action_ent of 1 for camp and sniper camp actions).

(C) If you want Bots to use H&A cabinets you need to place a small node at the cabinets (say node_radius 20 - 30) and then either force them to use that node when passing by or attract them to it with a roam or an alt-roam at that node.

(1) The tunnel gate can still be closed by a human. I'll throw together a script later to show how to avoid this and maybe even a script that gets the bots using levers (similar to the fuel room door in v1_rocket)

(2) I had problems with that spot with bobots too, I'll have a go maybe some time to see if anything can be done (Hey it could always be solved with a teleport lol)

(3) The CP spawns worked the one time I looked but did not monitor it after that.

Thank for keeping at it. Work is obviously more important. The important question now is; Was waypointing more fun than work ;) ?

Re: breakout_et_b2 navigation
 

Thanks for the review Tom. To tell you the truth the waypointing is fun as much as the work is as I have my own business.

Ok now for your points

A) once a primary goal is reached on this map the map ends, so it shouldn't matter. Unless I missed something. Initially when I made the 2 actions (0, 1) to be active forever the bots wouldn't build the CP easily. So I activate the primary actions for a team if the CP is built. Otherwise I disable them. Consequently I should disable the primary constructs for the team without a CP.

B) Now I was wondering how this comes. The bots would always crouch. So you are saying for each "Camp" action if I want the bot to stand its entity should not state 1023 but 1? Is there an article about maybe I missed it.

1) Yes it can I left it there for the time being but if you want to close it a minor change in the main script should do that, basically commenting out where the trigger for gate close is in.

2) I looked around there for an entity as I could put a barrier_remove but there is nothing. I was also thinking about the teleport idea, but how? The references I saw in wiki were for test spawns. I also checked the flags for fakebrushes but there isn't one wit pass-through. (Basically a brush that could override the default ones of the map from the script).

3) For the CP Spawns I noticed in some cases I could not select spawns. So if a team builds the CP and you try to switch to the original spawn does it work?

Couple of other questions/comments I have.

1. For mines I read across other forums that the g_maxTeamLandmines var could be used to adjust the number of mines a team can place. This should work for ETPro servers but not ETMain. As far I understand Fritzbot is based on ETPro but I could not set that variable. It always defaults to 10.

2. On the original maps at least battery, goldrush I run into cases where after the west banker is captured by the allies (battery) or the tank is stolen (goldrush) the allied bots will stop except their engineers and covert ops?. Then they may resume after a dynamite action is successful or something like that.

3. Battery. Ok now try this. Join the allied team as an engineer, let them capture the west banker, blow up the back door then on the gun controls when an allied bot places a dynamite go on and defuse it. Seems if you defuse it a couple of times the allied bots would not attempt to place another dynamite as the defuse action came from their own team? They will however try to camp around the gun controls. The axis engineers would also go in the gun controls camping right at the dynamite spot doing nothing. I also tried it on the oasis and saw the same results. On the mlb_temple waypoint which I was messing around, the engineer will defuse again and again no problem. Until the point when I disarmed it few seconds before it exploded. Then the engineers was like they had no goal. They were stuck. It was different and I do not understand what is going on.

4. I tried the fakebrushes again on the mlb_temple. I tried yesterday a fakebrush in the well coordinates were
5861 9171 485
you can verify its location if you want just in case I did something wrong. In the main script I did as you have in the transmitter. In the game manager of the main map script I did,
// Build some steps to help the bots jump up to their positions at the E side of the castle roof
create
{
scriptName "step1"
classname "func_fakebrush"
origin "5861 9171 485"
contents 65536
mins "-100 -88 -24"
maxs "100 88 24"
}

Then I used the /mal_showfakebrush 1 and I do not see anything. I enabled the node editor did vid_restart I do not see it. I got the origin doing /viewpos in the well. Do you know what is going on? Is it possible that I cannot do that on that particular map?

5. For the railgun I saw the various posts earlier is it possible to use the main script and convert the code for the train to be a truck? (without the need to change the original map with gtk)

CK-Chaos

Re: breakout_et_b2 navigation
 

A)Yes it may not matter in this case (the constructs being set as minor ones). However, All the active "forever" (/action_active .. 1) does is make the g_action_info goalnum follow the current goalnum IF the action is active. It does nothing if the action is disabled. In maps that do not use goaltracker triggering it is good practice to make all actions active "forever" JIC. Your disabling the primary goals if the CP is lost will still work.

B) It was added to rev 0.70 as a quick hack by Mal thus the re-use of the entnum like the reuse for mineplants. Mentioned here in the wiki.

2) No wiki article on adding teleports. My practice waypoints ae_sniper_night provides an example for scripting a new teleport (btw I was kidding about teleporting on breakout).
Most original brushes in the map will have no script name nor an individual entity number, they are compiled into the worldspawn. They can not be removed/modified except in a mapping editor like radient gtk. Exceptions may be those things that you can break (windows... but even then it is rare to have a scriptname on those things).

1. Fritzbot ET is based on ETmain with only a few scripting things borrowed from ETPro (e.g. func_fakebrush). So cvars you read about for ETPro don't work in Fritzbot. btw exceeding 10 mine plants can possibly crash fritzbot.

2. Don't know. Bots may pause briefly if their chosen goal is completed or deactivated before they get to it, or engineers may briefly pause if they chose a dyno action that already has dynamite planted about to blow. Bots may pause indefinitely if they chose an action they can't navigate to from their current position. And if no action is available they zombie and generally complain "no goal..."

3. Could be an interaction between their get-out-of-there self-protect behavior (for dynamite about to blow) and the defuse event. Since I can't change the code I suggest; (a) don't defuse your teammates dyno, (b) make certain that there are at least 2 if not 3 engr bots per team, to increase chances that one is not so affected and (c) roam in other classes of the opposing team to kill any zombie like engrs. (and make sure your actions are set action_active 1 JIC to be sure it is not an unwanted goaltracker interaction)

4. fakebrushes can be hard to see. Your example has all 8 corners and 4 out of 8 vertices embedded in the well walls. Another thing, flying around as a spectator does not let you see them, you have to belong to a team. (use /noclip to see the embedded parts of the fake brush box.)

5. Not certain I understand. ET script has movement commands specific to trains and what they pull and other commands used by everything else script_mover wise. If you mean making the movement trigger like that for a truck well 420blunt's script suggestion does that (also see the bindlestiff's __bridges__). If you mean make the train damageable/repairable I don't know. I have tried to change the truck on supplydepot in that way with little success.

Hope this all helps more than it confuses.

Re: breakout_et_b2 navigation
 

Hi Tom,

Thanks, ok got it so I did setup the actions for bots to stand seems much better now. For the fake brushes I got it also so I had to select teams that was the problem. And the crash that I was experiencing adding fakebrushes was because the entities change also So all of the action_entities and scripting has to be adjusted.

I also re-did the CP spawn nodes as the allied bots would stuck sometimes. I still have the spawn problem however. The team that owns the CP cannot select the spawn. Is this something general with fritzbot or is it my code in the main map script? Because for goldrush I do not see a problem once the allies steal the tank.

For the dynamite issue where the engineer bots stop following the actions is not done on purpose. I did test it that way to figure out what's going on. The et_ice map is a good example. If the allies engineers manage to defuse the dynamite to the main entrance a couple of times, the axis engineers do not plant another one.

One other question I have do you know the names of the map for et those ported from the original rtcw? I found 2 so far the breakout_et_b2 and the tc_base. But I remember there were others. If you recall the names please let me know.

CK-Chaos

Re: breakout_et_b2 navigation
 

I think I have a script for this map where I added a flag by the command post and used it instead of the command post for spawning. I'll look and see if I can find it. I was going to do this map actually but gave up after I found out that the engineer camp actions Mal added for dual obj maps were broken.

The defuse problem is actually a bug it happens to me on warbell. When the defending team defuses a dynamite and the game doesn't say dynamite defused. The defending teams engineers will just run straight to the dynamite action and stand there and the attacking teams engineers just use camp and roam actions.


EDIT: I found the script with the flag. It has 5 spawn entities per team. My idea was to play with a full server and only have some spawn forward and some to spawn back for a possible defuse. You can add more spawn entities if you want more than 5 to spawn forward or you can remove some if you want less than 5. It also has fakebrushes blocking the sewer hole so bots wouldn't fall in.

Re: breakout_et_b2 navigation
 

Hi Blunt ok thanks I will have to test this. The new entities will have an impact to the current nav file as the action entities will need to be adjusted.

I have also fixed the crouch actions, the spawn nodes and the disabled the lever functionality for the tunnel and have updated the file under the original link so should be better now.

One other thing I may try on this map as it's fairly simple is to see if I can setup a helper entity to trigger the engineers repairing the MGs. I know by default this is not supported from the fritzbot actions but my question is there a way to setup the entity for the MG via the main script? The entity numbers are 514 and 409. So I could trigger the aiscript if there is a way to setup a trigger in the main script. Then the engineers could repair an MG using it as a minor construct and kill the action once the repair is done. So like for CPs or MG nests is there a chance that the built final or decayed routines can be setup? If so it should work.

Thanks
CK-Chaos

Re: breakout_et_b2 navigation
 

You probably can use helper ents to get engrs to repair fixed mg nests. the caveats (and why others don't bother) are;

1- You need a fake func_constructible - trigger_objective_info pair for the damaged state as well as another for the repaired state. ET maps become unstable if too many entities or too many trigger_objective_infos (tois) are in the map. The former (entities) have a limit of 1024 but the game needs 100 or so during game play. The latter's limit seems to be around about 16 tois (including those already in the map) but it varies a bit.

2- Repairing mg nests are low priority and in your map minor constructs are rarely if ever built. So you would have to figure some way to script it so they would be built. I have recently experimented with priority shifting a construct by having 2 real actions (one minor, one major construct) target the same thing. Basically depending on some aiscript logic when the construct is destroyed the action block disables the alternate priority construct for a set time then swaps the two after a delay. Discussed here it is still very experimental and would have to be expressly verified if used.

BTW there is supposed to be an ET script command that is supposed to repair the mgs. You could try having the mgs self repair after a delay.

(I don't think the MG nests have all the states of a CP. Most likely just two states (working or not) plus the invisible one when they are destroyed back to construct boxes)

Re: breakout_et_b2 navigation
 

Hello,

I updated the et_breakout_b2.zip to include the changes for the spawn from 420Blunt's code. I also did few other fixes, one is present with the original .script file where the quotes of the announce CP built message weren't properly set.

Have a look let me know if see any problems. The new file is under the same link posted originally.

Tom, yes there is a repair mg command that can be set but what is the event/trigger when the mg is damaged. (for fixed mgs not constructible ones). At least I could experiment a bit if it happens to know how to trigger the event for the damage case.

Thanks
CK-Chaos

Re: breakout_et_b2 navigation
 

misc_mg42 has no events listed, but in any case you could only then work with any mg42s with an existing scriptname definition (BTW Hobbits BSP reader does not handle misc_mg42 entities). Really you would need to use some other event in the game or add a func_timer to trigger the self repair periodically. To see how to use a func timer you can check the weather events I added to a couple of maps (UJE_hospital_sniper, md_bridge) or the mortars exploding (shooter_mortar) I added to Ammodepot. You can also look at ae_sniper_night where I scripted in 2 misc_mg42s (since you may not be able to find targetnames for the existing ones).

I won't be able to spend much time looking at your waypoints before Sunday. Sorry.

Re: breakout_et_b2 navigation
 

Well there is an update. First I managed to setup a teleport for the bots so they won't get stuck in the tunnels. I updated the files under the original link. So I removed the fake brushes that were closing the opening hole. Have a look let me know if you see any mistakes in the .script

Tom, I can see all the entities from the bsp and the entity numbers. I am running a different program for that in php for 2 reasons. First I cannot use the latest waypoint tool as it requires XP sp2 which I don't have and 2nd the old version crashes from time to time especially when it switches between bsp entities and waypoints. So I had to do something about it and what I have now is pretty good for the bsp entities. If anyone needs it let me know its gpl but you need to setup a local server for this to run along with mysql.

Thanks
CK-Chaos

Re: breakout_et_b2 navigation
 

Yes the old version needed a special dance to avoid crashing. Apparently it may be related to how printers are handled (poorly) in sp1.

Your chosen bsp reader sounds worth a look, maybe to include a reference in the wiki. Post any links you have got and requirements (I have not updated my WAMP for over a year). I have occasionally thought about writing small utils in perl or php but figure it would not be received well to ask others to install so much just so I could provide open script.

Tried out the func_timer method. It worked fine;



Did not find any working events invoked for a misc_mg42's scriptblock except spawn{}.

Re: breakout_et_b2 navigation
 

Yes, I tried the mg code works nicely. I will use it but not for this map on the existing mgs. I checked the existing 2 entities, the models appear without targets or scriptnames so there is no way to link them in the .script.

not sure if you can remove them if they do not include a scriptname/targetname seems this particular map was simply ported from RTCW.

I also tried the func_explosive event again using faketois. Now according to the wiki doc, the typical handler looks like:

I don't understand the purpose of the trigger remove function there. The system will call the death event (when alerteentity is invoked) and so everything can be handled there. The remove command also may not be needed. When I checked the entity after the event was triggered the entity was gone as expected.

Also crapshoot mentioned at some point memory leaks with multiple func_explosive entries. How do you detect the leaks is there a dedicated command or from the O/S panel?

I will write some documentation for the reader and send you the links. I will probably get sometime this weekend.

Thanks
CK-Chaos

Re: breakout_et_b2 navigation
 

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.

Re: breakout_et_b2 navigation
 

Hi Tom, I checked a bit there is a command for the ET
/g_debugAlloc 16
that shows allocation during map load and gameplay I suppose. This is basically called by the G_Alloc function that does a malloc and prints the allocated memory. Fritzbot seem to have fixed chunks of memory allocated cannot tell what they are just they happen. I suppose this should happen during the create command. The most efficient command I could find so far is the g_scriptdebug that shows the various events but still during a crash there isn't too much info other than the last command executed. Now if this was intermittent it's much harder to tell.

In any case the func_explode was not related to a TOI in my case. It was just a placeholder on the tank's path so the aiscript will get notified. I understand using the construct instead you could activate it as many times as you want and so with a 2nd one you can also switch something on/off.

One other question i have a script_mover entity can it linked to an action or not? I know fritzbot does it with the tank but how the bots would behave if say I specify a new script mover in the .script and link it to an action?

Actually I found it in the goldrush those 2 keywords set_Vehicle_Owner Allies and set_Vehicle_Number seem to control the script movers. So the owner seems to be a flag like not something that both teams can have.

Re: breakout_et_b2 navigation
 

g_scriptdebug is useful but verbose. It is mentioned in the wiki on debugging script files. I suggest you also read about logging the console to a file.

FritzBot support of script movers is limited. The aiscript directly can support only one at a time that only one team will try to repair and the other damage. Any way I have discussed this in some other thread already. Goldrush is a good one to review since it shows when the vehicle support can be turned off to improve bot focus/priorities and how it can be switched from one vehicle to the other. There is no action normally connected to a script mover vehicle. The bot navigate to the node closest to an active vehicle on their own and their behavior is preprogrammed. The script mover entity # is programmed in the special global command and special set_Vehicle_Number keyword.

If you find you want the bots to use an non-objective script mover then northpole and eagles 2way waypoint show how to trap the bots into using them with out knowing that they are scriptmovers.

Re: breakout_et_b2 navigation
 

Just started looking at the waypoints. 2 comments; The rabbit hopping back behavior at the hole above the teleport is a behavior that we waypoint around. It happens at edges when there is a steep jump down. So to avoid it we commit the bot (when necessary) to walk out straight (like in the cartoons ) into a node in midair and let them fall down to their next node.

2nd point, now that your waypoints are proceeding well you should give some thought to preventing the fast win by a human. I can always win if I take axis engineer (and why myself I prefer playing breakout_et_b1 to b2).
The problem will likely be that you need to focus a class/type of bot to defend the radio and discourage them from leaving their posts. The other thing is that you may need to focus the engineer bots on disarming the dynamite. The latter will take some experimentation because FritzBot does not provide us waypointers with as fine a control on bot priorities as we would like. One thing you can try is faking the gun dynamite plant as a construct dyno plant (32) with a prone setting. Since the dyno exploding ends the game it should not matter which dyno action is used. If that does not work you can possibly script the dynamite planted event like I did in caha tavern to improve bot focus.

BTW playing the other side as allied engr is great, very tuff. Nice:drool:

Re: breakout_et_b2 navigation
 

Hi Tom, ok got the first point and I will change the map, for the 2nd so when you plant the dynamite does your team owns the CP and CP flag? I placed several camp actions for the allies inside their radio building to avoid sneak-ins.

What I haven't done however is to disable the primary objectives if a team does not own the CP/flag (other than instructing the bots).

When I tried it I could win using either team by casting few airstrikes to clear-up the defenders as a Fieldops. As I medic I could not do much for support, as a Cvops same, as an engineer I could sneak-in as I explained when my team did not own the CP.

The attack/defend focus does shift based on the CP ownership.

CK-Chaos

Re: breakout_et_b2 navigation
 

Just join as Axis engineer at the start, go hellbent for the sewers. exit right, hug the far wall round the corner and then into the building, shoot the door, then behind the building to blow the wall, back inside till wall blown, then through the hole up the stairs and set dyno on the radio. I have only been shot at once from a distance, in fact the only time I came close to dying was when I caught a fair bit of the exploding map street shell. Alas It is a feature of the map that makes a fast Axis win easy as compared to a fast Allied win. Don't know who owned the CP (my et_console.log was already reset)

What you can do is class limit the CP flag to exclude say soldiers (but path it so they touch it anyway if passing). Then make either the mobilemg or panzer camps only appear in a varierty of places protecting the wall AND the radio (tricky that part) and roam them up the stairs too. Of course this means class limits on just about all allied general camp / roam actions elsewhere in the map. I often use soldiers defensively when other classes can't be spared (as in this case). Note that weapon specific camps have somewhat higher priority than general ones, and defends are just general camps with longer times. But if the spawnflag action in the cp is not class limited then that is what the soldiers will see as highest priority.

Oh BTW the garden gate team door needs a team specific node and connections so the allies don't have to run through the building to get to the breach. See nodes 142 145.

Re: breakout_et_b2 navigation
 

Hi Tom, yes I will check the map again for the nodes note although the nodes should be connected/disconnected automatically,

I think if you give a bit of time till a the axis team builds the CP the allies bots get into defensive positions.

I would have to change the .script file to hide the main objectives for the team that does not own the CP.

CK-Chaos

Re: breakout_et_b2 navigation
 

Could it be that I am just too fast? We should try it after 1 minute+. If it proves that a short delay lets the bots get to defensive positions then creating a one-time removable barrier could slow the humans down. TBD.

Re: breakout_et_b2 navigation
 

Hi Tom, one other thing if you recall I used a teleport on this map to get around the bots getting stuck in the tunnel entrance. When I placed waypoints for the darji2 I noticed the node radius alters the bot's movement. If you have a node radius of 5 say the bot will crouch. Is there some info about it? I mean if we set it to 1, will a bot prone? Or using a combination of nodes?

In any case I will leave the teleport there for the time being but if I figure some other way to change it I will.

Thanks
CK-Chaos

Re: breakout_et_b2 navigation
 

AFAIK the radius is not a behavior flag. The bots will crouch on their own but the placement of the first node inside a duct or low tunnel will influence the success rate. A large radius could be detrimental in that the bot satisfies the navigation step too early before crouching. Another thing to try is tweaking the node lower to the floor and using the walk flag so the bot does not jump going in. Also align the preceding node so the bot goes straight in not clipping the sides.

In general Avoid node radii smaller than 10. It could adversely affect navigation success rates, make the bots look like bots and could trap/delay the bots affecting game play or balance.

Getting the bots to go prone might be possible with a roam with the prone flag but of course that only works if the bot had the roam as its chosen action. Now you can put two disconnected nodes on top of each other for the path away from the roam but in this case it would not work.

Re: breakout_et_b2 navigation
 

yes I tried already the nodes beneath the ground but at least the combinations I made did not reliably worked. The bots will sometimes pass through sometimes not. I got it in one case - the best case - where the bots will get through but with a delay and several attempts. And if 2 bots were in things again would be unreliable.

Ideally, the prone flag should reference the node not the action.

Re: breakout_et_b2 navigation
 

These difficult navigations I find fun, but often do them in isolated tests first before proceeding to the full project (northpole had at least 4 special cases to do before committing to finish the waypoint). The use of the prone flag via actions is not ideal but in Northpole I was able to use it via an Alt-roam inside the cannon. That worked because the cannon was a longer path so the bots really only accessed the cannon by the route system. In your case the sewer is the natural shorter path so bots will chose it in ways you can not control by routing to an alt-roam. I guess the teleport is the best way, though if you get the bots to crouch you might shift its trigger point to inside the sewer.

I agree that nodes should also have independently a crouch and prone flag to handle a few special cases like keeping under cover. I added in the wiki's FritzBuglist_ET a requested:new functionality sub-section for ideas like this. If you have a well thought out case feel free to add something on new behavior flags for navigation nodes. Bobots as I recall used different types of connection wires for some of its bots behavior.

Re: breakout_et_b2 navigation
 

I just investigated a bit more about the dynamite/defuse problems.

If you want to quickly see what happens was described briefly earlier but here are the steps to reproduce the issue.

1. Load map bettery add a single ally eng bot to make things easier.
2. Join the ally team as an engineer and start the map
3. Follow the bot will construct the ramp and then head towards the gun controls
4. Let him plant do not fully defuse till the last 5 secs. You should fully defuse when the bot walks away (does it the last 5 secs to avoid damage).

5. There are 3 actions linked for the plants so repeat step-4, he will plant just 3 times alltogether and you need to defuse the last 5 secs as explained.

Ok now there is a fix at least as much I tested it works every time.
1. Edit the map's waypoints change actions 74,75,9 to be active forever (1).
2. Remove the linked actions from actions 74,75, 9 so the all links are -1 ie the actions aren't linked together.

And that should be it. The engineer will plant again no matter when you defuse or how many times you defuse the dynamite.

Also if during regular gameplay the dynamite actions aren't processed for some reason check the goal tracker. As Tom mentioned earlier all actions are best to be active forever to get around the goal tracker issues.

Re: breakout_et_b2 navigation
 

Ok in a wholly new map I have confirmed your last 5 seconds defuse bug (using keyword-fix beta but I think the bug goes way back).

However your apparent fix can be explained differently. When the entity changes state to destroyed (killed) FritzBot searches for a single action with the same toi entity number then updates that action and triggers its aiscript test block. For dynamite actions it then checks if any other actions are linked and updates/triggers them. By not linking the actions and setting them active 1 the other dynamite actions are not updated and therefore remain Active till the map ends or until the aiscript deactivates them. This is similar to using regular dynamites where major_construct_plants should be used. (The type mismatch means the aiscript has to provide the activate/deactivate control explicitly.) Now if the de-linked actions were not active forever then the extra dynamites might lose focus if the goaltracker increments twice, but in aiscript method that still could be the rest of the map (depending on map and waypoints).

I think your idea is an interesting workaround, but until I evaluate the defuse behavior I would suggest linking all or all but one. If the defuse behavior suffers then the unlinked dynamite action might need to be located in the same space as a linked one. And of course the aiscript must deactivate the unlinked actions when the entity is blown. And to avoid having to test which action gets updated you can use the event_explode set to the func_explosive targeted by the entitiy's toi.

Re: breakout_et_b2 navigation
 

Hi Tom, thanks for taking the time to investigate this. I also tried placing different dynamite actions around the same toi (unlinked). hobbit's editor complains about it and also when I tested it the allied engineer could place the dynamite using one action spot while the axis engineer would go to a different action spot because they were unlinked but point to the same toi I think. We could use different tois one for each action but I am not sure it worths the resource expense.

CK-Chaos

Re: breakout_et_b2 navigation
 

BTW I still have not confirmed that the engineers act the same way re:the 5 second bug if the opposite team defuses. This may just be because the planting engineers switch to fight mode and don't invoke their self-preservation behavior.

The defuse action to the locked up situation (defuse your own team's dyno in the last 5 seconds, get your team spamming no valid goals or equivalent then add engrs to the defusing team (respawn at 1sec)) looks like they also believe dynamite is planted and will go to the actions and wait. Now if I plant another dyno at one of the locked up actions the defusing engineer will defuse and that resets the lockup and the planting team goes back to plant.

Now I have not tested defuse at de-linked actions, but the going to the wrong defuse point I have observed in linked cases. This was a problem I found in 2hide and caha_tavern. The defusing engrs go to one of the actions and if they don't see the dynamite they just stay there. Now in each map I was linking in defuse only actions to cover human plants out of sequence or placement, and I found that is a problem in other ways, so I should go back and check if the poor defuse search behavior is also related. (And no, defuse only actions don't work. alas).

Re: breakout_et_b2 navigation
 

Hi Tom, regarding the opposite team defuse I have seen it happening. Seems to me the team is not a factor for the defuse action but of course only Mal could tell for sure.

It's just harder to replicate it with bots as they need to defuse the last 5 seconds and with 3 linked actions is quite hard to emulate. Using straight gameplay at least.

With the test map I did where I also have the cvops alt roam issue, I ended up setting a single action for the dynamite plant and it works reliably. I changed the other previously linked actions to do something else.

CK-Chaos

Just a quick note FYI
 

The map is a convert from a RTCW map and that might explain why it contains the file scripts/breakout.shader. However 2Bit also used the same filename for his shader in Breakout_371 (and earlier versions). Consequently breakout_et_b2.pk3 and breakout_371.pk3 should not both be in \etmain at the same time unless you like playing 2Bits map with it looking like he never finished shading it. However merging the 2 shaders seems to create a workaround.

------------

The shader z_breakout_fix1.zip workaround is now tested and available on my filefront page.