Working on script system ATM.
Theres a LOT to do yet, and will have to transfer a lot of the funky stuff I made that would let the nodes themselves hold this info, to the script system, which in the end will be SO much better for everyone.
Heres an ex using BEACH:
Say, when any of the walls blow, you want some diff things to happen:
1. You want the allied snipers to become venoms.
2. You want more LTs, since you don't need engs anymore.
3. You want paths opened between the nodes that were on either side of the wall to become connected.
4. You want some axis to become flamers.
5. You want path nodes previously restricted to the allies to become open.
Heres what you'd do (so far, this may change) in order from list above:
Code:
if (ACTION 3) //boolean logic, "if "action 3" == 1 (completed), do this"
{
allies_SwitchFromWeap(sniper, venom)
allies_SwitchToClass(LT)
node_connect(23, 24, true) //the "TRUE" means its a 2 way connection
axis_SwitchToWeap(flame)
openNodeGrpToTeam(1, ALLIES)
}
Now some explanation.
There is a new keyword in the .bot files. This keyword tells the game if this bot is open to changing its weapon and/or class. If the bot isn't open to changing its stats, it will NEVER respond to a change class/weap command (just like many humans never change their class). However, if the bot IS open, then any cmd to change weap or class will be done by them. You wouldn't want ALL bots on the server to be open to switching, just a few - thus its important to pick which bots you want to play with.
Path nodes can have a "group" number, which is an easy way to group together certain nodes. On beach, all nodes on the axis side of the wall, before any of the walls blow, would be group 1. Any node from group 1 will be off limits to the allies, until at least one of the walls blow.
Comments/ideas/suggestions are welcome.
NOTE: a lot of this is still subject to change, as I find out what works best, and what you guys would like to see.