Fox-1

Just noticed I never replied to this... Thanks for all the info. The AI/Human trick with the trigger area is new for me and may be very useful for other projects. As for the the map in the subject, I stopped with that. The scripting became so messy I couldn't understand anything of it anymore when looking at it after a few weeks passed by. I'm now trying to solve issues with opening and closing "gates", which doesn't seem to be that easy as the AI isn't aware of any blocking structures that are placed or removed once the game is running.

The active in: flags in the script properties works fine. Also instead of attackmove you could make an object list, adding every structure (you could import one of the game's library maps. They have all the object lists added) and then have the unit/team attack the object list.

 

Tell me, what is it you're trying to achieve? Plus if you upload the map, I can take a look at it.

 

"Active in:"...  If it works for you, I really wonder why it doesn't work when I try it myself.  It seems to be just a matter of clicking modes 'on' or 'off'.  How hard can that be?  (well, too hard as it seems).

 

"Object List"...  I figured out that could possibly work but I think this only works for units where I only use teams.

 

 

 

What I'm trying to do is probably harder to explain than to script :-)

 

 

The basic idea is:

 

player 1: starts on the left (human or CPU)

player 2: starts on the right (human or CPU)

'creeps' player: starts in the middle (CPU)

 

In the middle is a kind of fort with 'creeps'.  It has some defensive objects and units which are static (as in: placed on the map when designing).  Besides of that there are 2 spots in the fort where units will spawn.  These units are not built by the 'creeps' AI but are pre-configured teams.  Each team is duplicated so they can independently focus on player 1, player 2, or both.

 

The actions of player 1 and player 2 decides when 'creep' teams will spawn (and re-spawn).

In the most basic form: if player 1 has 12 or more units in area innerperimeter 1 that can attack, then spawn 'creeps'team 1A if not exist.

 

(There are rules with several different parameters and areas used to calculate which team will spawn and when, but it boils down to above example).

 

All of this works without problems.  The culprit is that these spawn-routines have to be adjusted to the mode a player is playing in.  Like: if the mode is changed from "normal" to "hard", more teams have to be spawned and the time to re-spawn has to be shorter.  There also have to be more defensive structures and units in the fort at the start of the game.

 

 

I'm afraid uploading the map won't be of any help.  Right now the script is a whole bunch of unstructured rules of which many are disabled because I first need to figure out how to properly attack a players base (structures and units) and how to deal with the 'mode' setting.

 

Also need to find out how the release a captured object when a player has been defeated.  As it is now, if a tiberium spike is captured by a CPU opponent, it keeps in his possession even after he is defeated (it's status will not reset to "civilian").  On my map a defeated player doesn't mean a victory for the other one because there are 4 other tasks that also have to be accomplished for a victory.

Attackmove...  this won't do.  It works for attacking enemy units (anything that moves or can fire) but not for destroying structures in a base.  I'm testing this with a team of different air units and the only buildings that will be destroyed are the result of splash damage when attacking units.  When all units are killed the attacking air units are just idling above the enemies base until a new unit rolls out a war factory which will be attacked and killed immediatly.

 

Tried all kind of attack variations (Team Attack Move, Team Attack Hunt, Team Attack Player, etc.) all with the same "no structures" result.

 

The only possibility that worked (as far as I tried) is letting each single unit attack a building, all one by one.  This won't do in the end because that way every single unit needs it's own attack script in where all possible buildings from all factions need to be defined.

 

 

As for testing the hard/easy modes,  I just placed 4 named objects on the map and made 4 seperate scripts that would delete each unit from the "world" 5 seconds after the start of the game .

 

Script1 set to "Active in: none"

Script2 set to "Active in: easy"

Script3 set to "Active in: normal"

Script4 set to "Active in: hard"

 

Depending in what game mode I started the game, it only affected 1 of the 4 units and it was always the same one (forgot which one as I didn't look any further into this as it didn't do the job anyways).

playing it as a custom map or skirmish map?

 

Playing as a custom skirmish map.  Setup is like: player 1 and player 2 (either 2 human players or 1 player and a CPU opponent) with a third "creeps" player.

 

When playing with 1 human player, the custom AI of the third (Creeps) player is based on the difficulty level of the one playing as a CPU player, so if you selected "hard" for your CPU opponent the AI of the 3rd player also has to use the "hard" routines of the script.

 

According to the info in the manual this is what the "properties->Active In:" settings in the scripts are for, which should be obvious but it doesn't seem to work.  OTOH, the manual also writes about a function "[Team – Action] Attack or Hunt: Team attacks an Area:" which doesn't even exist.  It does for "[unit]" but not for [team], making me have to do a total redesign of the creeps AI.

Maybe I wasn't clear enough.

 

I don't need to know it when playing the game, which is obvious anyways as one selected the mode prior to starting the level themself.  I need the difficulty status in WorldBuilder to make scripts that adapt themselves to the selected AI mode.

 

 

Just something to get things like this to work:

 

if Local_Player's_Enemy="hard" then activate script1

  or

if Local_Player's_Enemy<>"easy" then activate script2

 

 

One would think that's what the "active in:" properties are for but these don't seem to make difference in script execution.