breakout_et_b2 navigation

[enigma1]

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

[TomTom]

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;

game_manager
{
    spawn
    {        
        create
        {
            classname "misc_mg42"
            targetname "testgun"
            accuracy "25"
            harc "45"
            origin "3485 -2205 1007"
            angle "80"
            spawnflags 2  //tripod=0? or NOTRIPOD=2
            //target   ??? 
            scriptname "testgun"
        }
...

        create
        {
            classname "func_timer"
            random "20"
            wait "90"
                origin "2885 -5525 344"
            spawnflags "1"    
            targetname "tomtest"
            target "mg42_testgun2"
        }
        create
        {
            classname "target_script_trigger"
            origin "0 0 400"
            targetname "mg42_testgun2"
            scriptname "mg42_testgun"
            target "mg42_testgun"
        }
...
    }
}
...
mg42_testgun
{

    spawn
    {
        print "mg42_testgun spawn"
    }

    trigger mg42_testgun
    {
        //print "mg42_testgun trigger mg42_testgun"
        repairmg42 testgun
    }

    death
    {
        print "mg42_testgun death"
    }
}

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

[enigma1]

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:

//the fake toi
faketoi1
{
     spawn
     {
 
     }

     death
     {

     }

     trigger remove
     {
           remove
     }
}

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

[TomTom]

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.

[enigma1]

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.

[TomTom]

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.

[TomTom]

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

[enigma1]

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

[TomTom]

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.

[enigma1]

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