View Single Post
Re: darji2 waypoints
ET Waypointing team member
TomTom's Avatar
Status: Offline
Posts: 742
Join Date: Jun 2006
Default Re: darji2 waypoints - 25-04-2008

I think the point is that Mal's aiscript commands just link directly to a trigger_objective_info, func_explosive, team_CTF_blueflag, team_CTF_redflag or team_WOLF_checkpoint. Only the toi can link to any of the other 4 or to those not listed like func_construct. I don't know if anybody has tried the latter 3 except for fake steals as priority-bot-attractors (see supplydepot).

Most of script info comes from the original splashdamage doc and forum and from chrukers site. Sometimes you can find some info in the W:ET code but much of what you need may be deeper still in RTCW/Q3 engine code.

When I said re-use I meant like what I did with eagles_2way_b3. I had weird things happening when I got close to the apparent toi limit. Then I figured on how to reuse 2 existing tois. I changed a constructible mgnest into a prebuilt one so I could reuse the toi for the tram cars. and I reused an mgtower in the second half of the map for a single event expire. In your case it isn't the toi limit since the map has very few (one). But the total number of entities is the issue. So one thought, try reusing some of the existing func_explosives if you can (OOPS skip that idea none have scriptnames, and with no tois you can't use event expires hmm...).

IMO offhand all that changing roams to steals or vice versa does is change the priority of the initial steal. FritzBot behavior carrying, seeing a carrier or seeing a dropped steal-able object is pretty much preprogrammed. I saw that in my goldendunk test loop. I suppose in a dual-objective maps using roams might slightly increase the chance of the opposing team attacking the carrier if only one team is carrying but I don't think it is generally needed. The real problem is the delivers not being available, how to make the carriers not look like noobs straying too far from the deliver point. What might be interesting would be trying to make a pseudo-random behavior of both fake deliveries and no delivery point. The pseudo-random point might just be a complex logic on a fake action and the fake delivery say would be turned on when the door closes but turned off when the fake-action changes (or when the door opens). Multiple fake deliveries would be nice too but multiple real deliveries did not seem to work well in v1rocket. The bots seem to always chose the same delivery at the route to deliver start point. So using multiple fake deliveries might need scripting.

Anyway I will try to find time this weekend to check out your latest waypoints and see how the entities workout.
Reply With Quote