An couple ideas for the action/script system
 

Hey Mal, i just had a couple ideas batting around for the scripting and action system that maybe you could use.

The first is class switching for Engineers upon completion of all dyno objectives. Of course it would be script activated sort of like how you got random weapon switching for the soldiers. I think this would be something that may be added because usually after all the dyno objectives are complete there's no real need for Engineers and they could becom LT's or Medic's or even select random classes.

The second is an idea i had batting around for Tram and Mover support such as Elevators. I've tossed around a few ideas before but now that i see how Fritzbot works with the script system and the pathing system i got a better idea about how this could be done.

Okay, first there'd have to be a wait action (possibly even a node flag) where once the bots reach this location they'll wait there for the time given in the script, say something like...

Action 5
{
botWaitState 30
}

Which tells the bot to ait at action 5 for 30 seconds. After that time it moves to another wait Action places on the tram itself (Waypointers would have to determine time lengths and such). This could also be script defined like so....

Action 5
{
botWaitState 30
movetoAction 6
}

The movetoAction would be like the "if_fda_owner_axis" type variables which would tell the bot that after 30 seconds, move to action 6, the bot would then move to Action 6 and wait there (which would be on the tram itself, and then the process repeats). Seeing as the bots already have enviromental support you wouldn't really have to add button support, but you may have to. This type of action could be used in other ways too, like setting bots to camp at certain locations for a given period of time or what not.

Maybe for Movers that require button activation you could tell the bots to move to a node first before proceeding. I can[t think of way how that would work, maybe having like a "MovetoNodeFirst" variable or something. For a bot to move back onto regualr pathing after using a wait action just set the Wait State command without a move to action variable. After the bot waits the time given if it doesn't sense that action nearby (or if one isn't defined in the script that he should move to) it'll cancel the wait state and the bot will continue onto the nearest node.

I don't know if that would work or not but i'd be easy as heck to put in waypoints and could work with most kinds of movers. Just some ideas, i don't know if they'll be any helpful or whatnot.

Denny

Re: An couple ideas for the action/script system
 

I think one of the issues with movers is that the bot needs to be able to recognize if it is there or not.

Re: An couple ideas for the action/script system
 

Not really, because the bot goes by the nodes & actions. The Mover runs on either a specific time frame or by activation. If the bots waits the given amount of time before moving to the next specified action or node (which is the time it takes for the mover to reach it's destination or near the bot) then it shouldn't need to know unless you totally made the script mover awareness part of their AI code. Using the method i explained above all the bot sees is wait states so that's what he'll do. He don't really need to know that he's on a mover.

The only trouble here is, he'd be sort of defenseless in a way. Now if he seen another bot i'd assume he'd shoot at him but usually when on a tram people toss airstrike cans and such off the things and use them for some sort of attack/defense procedures.

Think of it in this way, Unreal Tournament has lifts, these are script movers. The Bots wait for the lift to come down, they get on it and wait till it reaches it's destination, then get off. Now granted sometimes they get caught in the shafts but that happens i mean UT is a pretty old game. I don't know if that was a good comparison but you get my drift.

The only way the bot would need to know if it's a mover or not is if it was part of his awareness code or if by some chance he coud be in danger like being smashed or flung off of it because it's moving to fast, or if the movers require jumping sequences (the jumping kinds of movers would probably be pretty impossible to waypoint anyway).

Re: An couple ideas for the action/script system
 

Actually that may not work now that i think about it, because what if a bot gets there while the tram is mid flight, then it could result in alot of wasted time.

But what you could is have the wait actions and possibly use the linked action system to help the bot sense when the action is available or not.

I don't know, damnit! It sounded like a really good idea. :(

Re: An couple ideas for the action/script system
 

Its a good idea, but like you said - a lot of wasted time is lost if the tram is out in mid flight.

I'll be honest guys - I REALLY don't want to support tram right now (if ever).

Its never been a popular map online or with me, and I have SO many things I need to work on ATM. My plate is full - I wasn't joking when I said I had over 30 items on my TODO list. :D


Your idea for buttons is good, and similiar to what I had thought of doing for Fritz. However, for the time being, I have disabled most of the useless movers on the default maps (check out BASE and ASSAULT for examples), that were adding nothing to the gameplay.

Re: An couple ideas for the action/script system
 

Fair enough, i figured i'd throw it out there though. The Engineer class switching thing wouldn't be a bad idea in a release later down the line if your looking for stuff to add. I can only think of a couple maps with script movers that would take advantage of tram support anyway (mp_tram and mp_theriver are a couple anyway)

So if you want to add support for it or if not either way it don't matter. :D