Difference between revisions of "Map scripting"

From WolfWiki
Jump to: navigation, search
([http://bani.anime.net/banimod/forums/profile.php?mode=viewprofile&u=5869 WhooSaaa]´s health ammo cab fix)
(Example 2: Removing an entity by origin)
 
Line 515: Line 515:
  
 
Origins of existing entities can be found by opening the .bsp file in a text editor, as described above in Example 1.
 
Origins of existing entities can be found by opening the .bsp file in a text editor, as described above in Example 1.
 +
 +
This example, when added into the start of oasis.script, will remove the team door above the Old City Wall.
 +
<pre>
 +
//...
 +
game_manager
 +
{
 +
spawn
 +
{
 +
delete
 +
{
 +
origin "5092 6991 -179"
 +
}
 +
//...
 +
</pre>
 +
 +
In the .bsp the entity spawning section has some entities which do not have a origin key. These entities have a model "*12" or some other number (the meaning of this is described in the section above). In this case, the entity origin appears to be at the world origin, so these entities cannot be removed by means of delete{origin"..."}. Most of the time these entities will have scriptnames defined, if not it is uncertain how to handle removing them by mapscript.
  
 
==Unresolved issues==
 
==Unresolved issues==

Latest revision as of 13:44, 17 June 2009

General information

In ETPro version 3 the ETPro team has improved and changed the scripting system to a quite big extent. This article presents some of the new ETPro map scripting features.

Some things cannot be done by scripting. These include:

  • making a part of terrain mineable/unmineable.

mapscript related cvars

  • b_mapscriptdirectory is an etpro cvar which specifies what directory too look for the map script. As always, the game looks under fs_game first, so you should not include etpro or etmain in the value of b_mapscriptdirectory. If not specified, the default is maps/. ETPro includes bug fix only scripts in etpro/maps and modified scripts in etpro/etpromapscripts
  • g_scriptname is an etmain cvar which specifies the filename of the script to be used. It is reset every time a map is loaded. The default is to use mapname.script or mapname_lms.script.
  • g_scriptdebug 1 outputs verbose information about the script in the server console.

Scripting Examples by duke'ku

Here I'll show a few examples of the new scripting allowed in ETPro, and attempt to explain what exactly it's doing. First off, I'll start with a simple example, where a model (in this case, a dinghy) is inserted into the map.

create
{
   scriptname "dinghy1"
   origin "2650 600 100"
   classname "misc_gamemodel"
   modelscale 1
   contents 1
   mins "-90 -90 -25"
   maxs "90 90 25"
   clipmask 1
      model "models/mapobjects/dinghy_sd/dinghy.md3"   
}

This isn't exactly the cleanest example of scripting (mainly due to my lackluster job of clipping the model off,) but what it produces is this: http://games.theteamkillers.net/rtcw/dinghy/2004-01-14-234844-battery.jpg

Now, to break down how it works. The create{ } command will place an entity into the map, at the spot specified by the "origin" key. The scriptname specifies the name that the entity will have in the map, and it is what seperates it from other entities in the map (which can cause quite a few problems).

create
{
   scriptname "dinghy1"
   origin "2650 600 100"
}

The code above will do nothing, it creates an entity (not even of a specified type, it will do nothing) and places into the map at 2650,600,100. To find your position on a map to place an entity (you'll need to find an origin for almost every entity), use the command "/viewpos".

create
{
   scriptname "dinghy1"
   origin "2650 600 100"
   classname "misc_gamemodel"
}

Now, the code has advanced a bit further and the entity now has a specified type, misc_gamemodel. A misc_gamemodel is a model placed into the map during load (compared to a misc_model, which are permanently static objects that get compiled into the map at compile). Misc_gamemodels can be used for almost anything, from walls (although this would be a terrible way of making a map) to moving tanks (all of the vehicles, construction boxes, command posts, etc. in game are all misc_gamemodels), but in this script it's just used for placing a model (provided with the ET mapping tools, available at http://www.qeradiant.com).

create
{
   scriptname "dinghy1"
   origin "2650 600 100"
   classname "misc_gamemodel"
   modelscale 1
   contents 1
}

Now, the model has a defined scale, 1. A scale of .5 would cause it to be half of the size of the model in the file that will be referenced, and a scale of 2 would cause it to be twice the size. Most flags that are used on an entity can be found in the entities.def file that is provided with the mapping tools.

create
{
   scriptname "dinghy1"
   origin "2650 600 100"
   classname "misc_gamemodel"
   modelscale 1
   contents 1
   mins "-90 -90 -25"
   maxs "90 90 25"
   clipmask 1
   model "models/mapobjects/dinghy_sd/dinghy.md3"   
}

Now, for the clipping. The contents flag specifies the type of surfaceflag that the entity will be. Surfaceflags that are defined in the ET source (found in src/game/surfaceflags.h, if you're interested) are listed here. The mins and maxs specify how far out from the origin of the model (in each direction) the clipping will extend to. The coordinates on this model aren't accurate, but they get the job done.

This was a very basic example of scripting, and now I'll be listing some more advanced examples of scripting.

Example 1: Battery's Back Door and Dynamite

//bani
create
{
   scriptName "backdoor"
   classname "func_explosive"
   targetname "backdoor"
   origin "4608 -4594 1024"
   mins "-63 -10 0"
   maxs "63 10 128"
   spawnflags 1   // AXIS_OBJECTIVE(1)
   eflags 65536   // EF_FAKEBMODEL
   svflags 1   // SVF_NOCLIENT
}

//bani
create
{
   scriptName "backdoor_obj"
   classname "trigger_objective_info"
   targetname "backdoor_obj"
   target "backdoor"
   origin "4608 -4601 1024"
   mins "-95 -85 0"
   maxs "95 85 128"
   spawnflags 17   // AXIS_OBJECTIVE(1) | CUSTOMIMAGE
   track "the Back Door"
   shortname "Back Door"
   customaxisimage "gfx/limbo/cm_radar_maindoor"
}

//bani - bug fixes
create
{
   scriptName "bugfix1"
   classname "func_fakebrush"
   origin "3632 -4313 881"
   contents 65536  // CONTENTS_PLAYERCLIP
   mins "-40 -1 -20"
   maxs "40 1 10"
}

Example 2: Fueldump and Spawning at the Command Post

create
{
   scriptName "fueldumphq_obj"
   classname "team_WOLF_objective"
   targetname "fueldumphq_obj"
   origin "-10853 -2036 6"   // z = CC_FILTER_ALLIES(2) | CC_FILTER_SPAWNS(4)
   spawnflags 2   // TEAM_ALLIES(2)
}

create
{
   scriptName "fueldumphq_spawn1"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "11072 -2448 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{
   scriptName "fueldumphq_spawn2"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "-10995 -2448 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{
   scriptName "fueldumphq_spawn3"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "-10918 -2448 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{
   scriptName "fueldumphq_spawn4"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "-10841 -2448 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{
   scriptName "fueldumphq_spawn5"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "11072 -2288 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{
   scriptName "fueldumphq_spawn6"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "-10995 -2288 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{      
   scriptName "fueldumphq_spawn7"      
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "-10918 -2288 512"
   spawnflags 2   // TEAM_ALLIES
}

create
{
   scriptName "fueldumphq_spawn8"
   classname "team_CTF_bluespawn"
   targetname "fueldumphq_spawn"
   origin "-10841 -2288 512"
   spawnflags 2   // TEAM_ALLIES
}

Hopefully you'll be able to understand what each of those flags are doing. If you can't figure it out, see if you can figure it out from the entities.def file (from [1], this is not the original ET entities.def file but everything in it should work - it contains new things that weren't included with the stock def), or come and bug the ETPro team (|Rain|, [av]bani, zinx, fretn, s2ikkyo) on irc.freenode.net, #etpro.

Contents Flags

  • SOLID 1
  • LIGHTGRID 4•
  • LAVA 8
  • SLIME 16
  • WATER 32
  • FOG 64
  • MISSILECLIP 128
  • ITEM 256
  • MOVER 16384
  • AREAPORTAL 32768•
  • PLAYERCLIP 65536
  • MONSTERCLIP 131072°
  • TELEPORTER 262144
  • JUMPPAD 524288
  • CLUSTERPORTAL 1048576•
  • DONOTENTER 2097152°
  • DONOTENTER_LARGE 4194304°
  • ORIGIN 16777216
  • BODY 33554432•
  • CORPSE 67108864•
  • DETAIL 134217728•
  • STRUCTURAL 268435456•
  • TRANSLUCENT 536870912
  • TRIGGER 1073741824
  • NODROP 2147483648

Not all of these surfaceflags will work, but the ones you will want to use should work. If you've tested something and it doesn't work properly, send an email to dukeku AT theteamkillers DOT net and I'll fix it here.

° These, as far as I know, are bot only commands - they will have no effect on other players.
• These are flags that should not be used in a script, they're either reserved for strict-in game usage that doesn't relate to something that you would do in a script such as this, or are reserved for entities that are compiled into the map and have absolutely no use in game.

Originally posted in the ETPro forums by duke'ku.

Scripting Examples by Rain

Additionally, players may modify keys on existing entities with the set command.

Example 1: Oasis Axis Garrison spawn marker fix

Here are a couple of examples from the oasis map script (etpro/maps/oasis.script):

axis_garrison_wobj
{
        spawn
        {
                set
                {
                        origin "7089 4852 -415"
                }
        }
}

This changes the position of the spawn marker for the Axis garrison to (7089, 4852, -415). (This was done to correct player spawn location after setautospawn usage was fixed.)

Example 2: Oasis caves water fix

Here's another example:

water_tunnel
{
        spawn
        {
                // rain - these are put into the world as CONTENTS_SOLID,
                // which is a Bad Thing if WolfReviveBBox gets called
                // while we're in the water
                wait 100
                set
                {
                        contents 32 // CONTENTS_WATER
                        clipmask 32 // CONTENTS_WATER
                }
        }
        [...]

As described by the comments, this fixes the problem that sometimes caused players to be pushed around uncontrollably while underwater in the tunnel.

Both create and set recognize some keys that can't normally be used while mapping. Normally, most of these are computed automatically (often at map compile time); however, there are some cases when the compiled value is unusable, and there are some cases where you might want to set these values when spawning a new entity.

Additional supported keys

The additional keys supported are:

KeyDescription
minsA point describing the location of the lower corner of the bounding box. (ent->r.mins)
maxsA point describing the location of the upper corner of the bounding box. (ent->r.maxs)
contentsContents flags - description above (ent->r.contents)
svflagsServer flags (ent->r.svFlags)
clipmaskBrush content types to collide with. (ent->clipmask)
count2entity-specific (ent->count2)
eflagsEntity flags (ent->s.eFlags)
pos_trTypePosition trajectory type (ent->s.pos.trType)
pos_trDeltaPosition trajectory delta Δ (ent->s.pos.trType)
apos_trTypeAngle trajectory type (ent->s.apos.trType)
pos_trDeltaAngle trajectory delta Δ (ent->s.apos.trType)
classname_nospawnChanges the class name, but doesn't re-spawn the entity. (ent->classname)
customaxisimageCustom command map image for the Axis team
customalliesimage
customalliedimage
Custom command map image for the Allied team
allowteamsTeams allowed to use an entity (ent->allowteams)

(You may wish to refer to the ET SDK for additional information.)

The func_fakebrush entity

Finally, ET Pro offers the func_fakebrush entity (also available by ORing EF_FAKEBMODEL (65536 or 0x10000) to eFlags), which allows the limited ability to spawn brush entities. The fake model must be a hexahedron, defined by mins and maxs, and will not work for all brush entity types.

Originally posted in the ETPro forums by Rain.

Scripting Examples by SiliconSlick

Example 1: Additional Axis spawn in the trainyard tower on Railgun

SiliconSlick made a diff for the Railgun map script to provide the axis with an additional spawn point in the trainyard tower.

--- railgun.script.etpro.orig   Wed Mar 31 20:01:18 2004
+++ railgun.script      Mon Aug 23 10:11:08 2004
@@ -6,6 +6,83 @@
 {
        spawn
        {
+               // SS - new spawns for Axis
+               create
+               {
+                       targetname "axistowermarker"
+                       scriptname "axistowermarker"
+                       spawnflags 3
+                       description "Axis Tower"
+                       origin "2050 5100 625"
+                       classname "team_WOLF_objective"
+               }
+
+               create
+               {
+                       classname "team_CTF_redspawn"
+                       scriptname "redspawn_00"
+                       spawnflags 3
+                       origin "2000 5175 625"
+                       angle "-45"
+                       mins "-30 -30 -30"
+                       maxs "30 30 30"
+               }
+
+               create
+               {
+                       classname "team_CTF_redspawn"
+                       scriptname "redspawn_00"
+                       spawnflags 3
+                       origin "2000 5175 360"
+                       angle "-45"
+                       mins "-30 -30 -30"
+                       maxs "30 30 30"
+               }
+
+               create
+               {
+                       classname "team_CTF_redspawn"
+                       scriptname "redspawn_00"
+                       spawnflags 3
+                       origin "2100 5175 625"
+                       angle "-135"
+                       mins "-30 -30 -30"
+                       maxs "30 30 30"
+               }
+
+               create
+               {
+                       classname "team_CTF_redspawn"
+                       scriptname "redspawn_00"
+                       spawnflags 3
+                       origin "2100 5050 625"
+                       angle "135"
+                       mins "-30 -30 -30"
+                       maxs "30 30 30"
+               }
+
+               create
+               {
+                       classname "team_CTF_redspawn"
+                       scriptname "redspawn_00"
+                       spawnflags 3
+                       origin "2100 5050 360"
+                       angle "135"
+                       mins "-30 -30 -30"
+                       maxs "30 30 30"
+               }
+
+               create
+               {
+                       classname "team_CTF_redspawn"
+                       scriptname "redspawn_00"
+                       spawnflags 3
+                       origin "2000 5050 625"
+                       angle "45"
+                       mins "-30 -30 -30"
+                       maxs "30 30 30"
+               }
+
                //bani - bug fixes
                create
                { 

Example 2: Depot Yard capture for Axis when Tug loaded on Railgun

This is another diff that makes it so that when the first tug gets loaded with ammo, the Depot Yard spawn point gets captured permanently for the axis.

--- railgun.script.etpro.orig   Wed Mar 31 20:01:18 2004
+++ railgun.script      Mon Aug 23 10:11:08 2004 
@@ -3088,6 +3165,8 @@
                                                                                                                                                             
                wm_set_main_objective   2 0
                wm_set_main_objective   2 1
+
+               trigger depotflag axis_capture_forgood  // SS - depot now permanently axis
        }
 }
                                                                                                                                                             
@@ -6022,18 +6101,35 @@
                wait 200
                setstate capturespawn invisible
                accum 0 set 0
+               accum 1 set 0  // SS - nobody had flag last
        }
                                                                                                                                                             
        trigger axis_capture
        {
                trigger game_manager depotflagred
                trigger depotflag setaxis
+               accum 1 set 2  // SS - axis had flag last
+       }
+
+
+       // SS - give depot yard to axis permanently
+       trigger axis_capture_forgood
+       {
+               trigger game_manager depotflagred
+               trigger depotflag setaxis
+
+               alertentity depotspawn  // wake it up
+               setstate depotflag invisible  // remove flag
+               accum 1 abort_if_less_than 2  // should be done if allies or nobody had it
+               alertentity depotspawn  // switch to axis
+               wm_announce "Axis have permanently captured the Depot Yard!"
        }
 
        trigger allied_capture
        {
                trigger game_manager depotflagblue
                trigger depotflag setallies
+               accum 1 set 1  // SS - allied had flag last
        }
 
        trigger setaxis 

Originally posted in the ETPro forums and the ND80 forums by SiliconSlick.

Scripting Examples by DerSaidin

Example 1: Spawning an entity which uses brushwork from the bsp

This example shows how existing entity brushwork from the bsp can be used for a new entity. In this example, the assult ramp on battery is reproduced to make a ramp up to the MG nest, so players don't need to trickjump. (script for the purpose of example only)

First, you need to find out what the brushwork you want has been called. To do this, open the bsp in notepad (or a similar editor). Most of the bsp file is not readable, however the entities are still quite readable (other than line breaks, depending on your editor).

An extract from the battery.bsp (starting line 12377, col 890):

{
"model" "*1"
"targetname" "beachplanks_lms"
"scriptname" "beachplanks_lms"
"classname" "func_static"
}

This is the entity which is the assult ramp. You can see that the brushwork associated with this entity is referenced by the key/value "model" "*1". I believe the "*1" is the name allocated to that brushwork during the compile. This will be used to set the brushwork for the new entity.

The relevant script in the battery.script.

game_manager
{
	spawn
	{
		//...
		//dersaidin ramp to MG nest
		create
		{
			scriptName "dsrampspawn"
			classname "script_mover"
			origin "-800 -5400 230" 
			model "*1"	
			spawnflags 2	// SOLID
		}
		//...
	}
	//...
}
//...
//dersaidin - new ramp spawned
dsrampspawn
{
	spawn
	{
		wait 50
		faceangles 0 90 0 1
		//rotate the entity correctly
	}
}

Note, this brushwork from the bsp has its origin at the origin of the map, any transforms on the new entity should take this into account. The faceangles in this new entity's scriptblock is rotating about the origin of the new brushwork, not the visible faces.

Also, there can be vis issues with the new entity (it may go invisible to players). I believe this is due to the origin of the brushwork being in an odd location.

Example 2: Removing an entity by origin

This method of removing entities can be usefull if you wish to replace or remove entities which do not have a script name defined. If the entity does have a script name, then an easier way to remove it is to use the command "remove" in the spawn script block of the entity's script block.

The script for removing entities by their origin is similar to the script to create new entities. Deletes should go in the game_manager's spawn block to remove entities from the map.

game_manager
{
	spawn
	{
		//...
		delete
		{
			origin "-864 -1966 318"	
		}
		//...
	}
	//...
}
//...

Origins of existing entities can be found by opening the .bsp file in a text editor, as described above in Example 1.

This example, when added into the start of oasis.script, will remove the team door above the Old City Wall.

//...
game_manager
{
	spawn
	{
		delete
		{
			origin "5092 6991 -179"
		}
		//...

In the .bsp the entity spawning section has some entities which do not have a origin key. These entities have a model "*12" or some other number (the meaning of this is described in the section above). In this case, the entity origin appears to be at the world origin, so these entities cannot be removed by means of delete{origin"..."}. Most of the time these entities will have scriptnames defined, if not it is uncertain how to handle removing them by mapscript.

Unresolved issues

Ragnar_40k's destroyable team door on Radar

I played around with the ETPro scripts and tried to make the axis team door next to the main gate satchable. As first step I simply copied over the code for the battery backdoor and only changed the origin-key. When I start the map I can throw a satchel next to the team door and get 7.5XP when I blast it. But I get no message and the teamdoor doesnt disapper. It seems that the trigger "death" for "backdoor_obj" isn't called. Can you say what is wrong?

game_manager
{
   spawn
   {
      create
      {
         scriptName "backdoor"
         classname "func_explosive"
         targetname "backdoor"
         origin "-1518 16 1406"
         mins "-63 -10 0"
         maxs "63 10 128"
         spawnflags 1   // AXIS_OBJECTIVE(1)
         eflags 65536   // EF_FAKEBMODEL
         svflags 1   // SVF_NOCLIENT
      }

      create
      {
         scriptName "backdoor_obj"
         classname "trigger_objective_info"
         targetname "backdoor_obj"
         target "backdoor"
         origin "-1518 16 1406"
         mins "-95 -85 0"
         maxs "95 85 128"
         spawnflags 17   // AXIS_OBJECTIVE(1) | CUSTOMIMAGE
         track "the Back Door"
         shortname "Back Door"
         customaxisimage "gfx/limbo/cm_radar_maindoor"
      }
               .
               .
               .
}
backdoor
{
   spawn
   {
      wait 50
      constructible_class 2
   }
}

backdoor_obj
{
   death
   {
      wm_announce "Allied team has destroyed the Axis Team Door!"
      trigger teamonlydoor1 hide

   }
}

teamonlydoor1
{
   trigger hide
   {
      remove
      // setstate teamonlydoor1 invisible
   }
}

The trigger backdoor_obj->death isn't called (I don't see the text from the wm_announce) . But the func_explosive "backdoor" I created is deystroyed (I get the XP for it).

Originally posted in the ETPro forums by Ragnar_40k.

Possible Solution 1

Try placing the death{} block in the "backdoor" (func_explosive) script block instead. --WeblionX 13:35, 14 February 2007 (PST)

MoB Seany's Health and Ammo Cabinets

Ok, now I want to get it to show up on the command map I already have

game_manager
{
spawn
            {
create
      {
        targetname "ammo"
        scriptname "ammo"
        origin "-1373 -1100 192"
        classname "misc_cabinet_supply"
        angle "270"
        mins "-45 -45 -25"
        maxs "45 45 25"
        ammototal "100"
        modelscale "1"
        contents "1"
        clipmask "1"
        model "models/mapobjects/supplystands/stand_ammo.md3"
      }
create
      {
        target "ammo"
        ammototal "40"
        ammorate "1"
        origin "-1373 -1100 192"
        classname "trigger_ammo"
        targetname "ammoarea"
        scriptname "ammoarea"
        modelscale "1"
        contents "1"
        mins "-45 -45 -25"
        maxs "45 45 25"
        clipmask "1"
        }
create
      {
        targetname "health"
        scriptname "health"
        origin "-1488 -1175 192"
        classname "misc_cabinet_health"
        angle "360"
        mins "-45 -45 -25"
        maxs "45 45 25"
        modelscale "1"
        contents "1"
        clipmask "1"
        model "models/mapobjects/supplystands/stand_ammo.md3"
      }
create
      {
        target "health"
        scriptname "healtharea"
        targetname "healtharea"
        classname "trigger_heal"
        origin "-1488 -1175 192"
        healtotal "400"
        healrate "10"
        modelscale "1"
        contents "1"
        mins "-45 -45-25"
        maxs "45 45 25"
        clipmask "1"
      }
create
      {
        classname "trigger_objective_info"
        target "help_marker_toi"
        scriptname "ammo_info_toi"
        track "Health and Ammo Cabinets"
        targetname "ammo_info_toi"
        shortname "Health and Ammo Cabinets"
        spawnflags "is_healthammocabinet"
        customimage "gfx/limbo/cm_healthammo"
        origin "-1352 -1179 256"
        modelscale "1"
        contents "1"
        mins "-45 -45-25"
        maxs "45 45 25"
        clipmask "1"
   
      }
create
      {
        classname "misc_commandmap_marker"
        scriptname "help_marker_toi"
        targetname "help_marker_toi"
        contents "1"
        clipmask "1"
        origin "-1488 -1175 192"
      }
                 }
}

Its works and has a "You are near Health and Ammo" message, but what do I need to do to get it to show up ont he command map? I did have script_mover parts as well before I removed them:

create
      {
     targetname "ammo_clip"
     scriptname "ammo_clip"
     classname "script_mover"
     spawnflags "2"
      }
create
      {
     targetname "health_clip"
     scriptname "health_clip"
     classname "script_mover"
         spawnflags "2"
                           }

But, no matter what properties i removed, it still said a model was required for script_mover. Is a script_mover class really that important? And if so, what do I need to do to fix it? If not, then what must be done for it to show up on the command map? Thanks.

Originally posted in the ETPro forums by MoB Seany.

Possible Solution 1

Try using a misc_commandmap_marker targeted by the TOI. --WeblionX 13:35, 14 February 2007 (PST)


WhooSaaa´s health ammo cab fix

Hi seany Think i fixed it. Spend some time doing this, and they show up on commandmap. Did make some changes in script though.

game_manager
{
	spawn
	{
        
        create
		{
		classname "misc_cabinet_supply"
		origin "2400 -2688 5316"
		mins "0 0 0"
		maxs "90 90 50"
		angle "90"
		scriptname "main_ammocabinet"
		targetname "main_ammocabinet"
		}
		
	create
		{
		classname "misc_cabinet_health"
		origin "2480 -2688 5316"
		mins "0 0 0"
		maxs "90 90 50"
		angle "90"
		scriptname "main_healthcabinet"
		targetname "main_healthcabinet"
		}
		
	create
		{
		classname "trigger_ammo"
		origin "2400 -2688 5316"
		mins "-20 0 0"
		maxs "90 90 50"
		ammototal "20"
		scriptname "main_trigger_ammo"
		targetname "main_trigger_ammo"
		target "main_ammocabinet"
		}
		
	create
		{
		classname "trigger_heal"
		origin "2480 -2688 5316"
		mins "-20 0 0"
		maxs "90 90 50"
		healtotal "400"
		scriptname "main_trigger_heal"
		targetname "main_trigger_heal"
		target "main_healthcabinet"
		}
		
	create
		{
		classname "misc_commandmap_marker"
		origin "2440 -2688 5316"
		scriptname "main_hacabinet_cm_marker"
		targetname "main_hacabinet_cm_marker"
		}
		
	create
		{
		classname "trigger_objective_info"
		customimage "gfx/limbo/cm_healthammo"
		infoAllied "Health and Ammo cabinets"
		infoAxis "Health and Ammo cabinets"
		origin "2480 -2688 5316"
		mins "0 0 0"
		maxs "110 110 100"
		scriptname "main_hacabinet_toi"
		shortname "Health and Ammo Cabinets"
		spawnflags "35"
		target "main_hacabinet_cm_marker"
		targetname "main_hacabinet_toi"
		track "the Health and Ammo Cabinets"
		}

Problem might be that ya forgot spawnflag setting in TOI. Greets WhooSaaa