August 17 2017 12:36:58
· Home
· Articles
· Downloads
· Discussion Forum
· Web Links
· News Categories
· Contact Me
· Photo Gallery
· Search
· Gameservers
Users Online
· Guests Online: 5

· Members Online: 0

· Total Members: 1,053
· Newest Member: gianlu
Teamspeak 3
Last Seen Users
· Brchi00:10:36
· Paolo00:27:31
· TimmEr01:12:54
· 420Ninjutsu02:28:01
· OndraG04:36:27
· Homi04:38:59
· DLoCo107:32:32
· SGT PEPPER09:15:39
· dim12:59:41
· VictorMyson13:07:55
· sonic13:45:06
· VCG john16:38:57
· Hoods19:36:45
· apfelbaum23:40:36
· The ACE 1 day

View Thread: Intruder's mapping (how to)
Vietcong.Info » Vietcong General Discussion » Maps & Mapping
Who is here? 1 Guest
Current Rating: (Total: 7 ratings)  
 Print Thread
Intruder's mapping (how to)
How to create "clever" bots:

I won't pretend to have THE knowledge on "how to create clever bots", but if you follow my advises, you should obtain rather good results. And "all this" without to use special scripts... Wink
The creation of clever bots is rather "tricky", mainly because a lot of factors will act on a bot's behaviour... Those factors are: the scripts, the waypoints (and their linking), the environement and the inter-action between the bots. It's only by optimizing ALL those aspects to the maximum that you will create the bots you are searching for! Be sure that if you only rely on your scripts, you will fail in your...mission! lol Wink

Note: The next informations are ONLY based on my own experiments and observations, with the help of the SDK, written by Shigor!

The scripts:

Let's say that the scripts will set the "character" of your bot. It's by mean of your script that you will create an attacking or defencive bot, careful or not... It's important to give a specific "mood" to your map by giving your bots the right behaviour. If they have to defend a VC base, don't give them too much "attacking power" for example...

Usually, I'm setting 3 kinds of scripts for 3 kinds of bots (those "informations" will be stored in the .inc files). A "covering one", a "normal one" and an "attacking one", but you can create more type of bots of course...
- The "covering bot" will usually stay more at his place, and will provide "covering fire" for the other bots... That bot will be equiped most of the time with the machine guns. I advise you to increase the shooting precision of such bots.
- The "normal bot" will have neutral skills, able to act as an attacker or a defender. He will probably be the main bot of your map. I advise you to set a normal shooting precision of such bots.
- The "attacker bot" will be the most "daring" of your bots, not fearing the death and able to put you in big troubles (give him more "running skills",lol)! I advise you to decrease the shooting precision of such bots (he will run more often and so, should be less precise).

Note: It's important to NOT give a bot too much skills in a specific behaviour otherwise he will become...predictable! A "covering bot" must still be able to "jump on you" if he saw you were behind a wall for example!

Here are examples of the possibilities you can add to your .inc file, in the: SC_P_Ai_GetProps(info->pl_id, &props); section.
Note that I've just copied those informations from another source (based on the SDK) I lost the trace. I may update those informations myself in the future...

//props.max_vis_distance = 120 // maximum visual distance the AI can see, if not specified, AI uses maximum visual distance specified for the level.
//props.watchfulness_zerodist = 2 // how good is AI at recognizing the enemy at zero distance.
//props.watchfulness_maxdistance = 1 // how good is AI at recognizing the enemy at maximum distance.
//props.boldness = 1 // this is used to determine how bold is the AI when in cover and under fire. 0.5 is very cautious player, 2 is medium, 4 is high. 10 is almost suicidal, the AI will not give a damn if someone is shooting at him.
//props.coveramount = 0.5 // how far the AI will run for cover compare to the distance to the closest enemy, default is 0.5.
//props.hear_imprecision = 1 // imprecision of the AI’s hearing. 0 absolute hearing, 1 average, 5 very bad.
//props.hear_distance_mult = 1 // hear distance multiplier – 0.5 is half, 2 is two times better.
//props.hear_distance_max = 1000 // maximum hearing distance.
//props.grenade_timing_imprecision = 2.5 // this is maximum time (will be randomized) between impact of the grenade and its explosion.
//props.grenade_throw_imprecision = 1 // imprecision of the grenade throwing. 0 perfect, 1 average, 2 quite bad.
//props.grenade_sure_time = 10 // how long the AI will wait until it’s sure the situation demands a grenade.
//props.forget_enemy_mult = 1 // how fast will the AI forget the enemies it has no more contact? 1 is default, 0.5 means two times slower, 2 mean two times faster.
//disable_peace_crouch = 0 //BOOL // this disables AI crouching in the peace mode.
//props.peace_fakeenemy_run = 1 // this is used to set the movement type under the fake enemy situation. 1 means always run, 0 always walk, 0.5 use run/walk 1:1.
//props.peace_fakeenemy_phase = 0.5 // same as previous, only for the stand/crouch.
//props.shoot_while_hidding = 0.3 // if enabled the AI will shoot even when moving to the hide out.
//props.aimtime_max = 0.7 // maximum time for AI to take an aim, default 0.7 seconds
//props.aimtime_canshoot = 0.1 // minimum time for AI to take an aim, default 0.1 seconds.
//props.aimtime_rotmult = 0.5 // multiplier of the rotation speed when aiming, default 0.5 seconds.
//props.wounded_start_perc = 0.5 // value of the current hp/max hp when the AI aiming starts to be worse
//props.wounded_aimtime_mult_max = 2 // multiplier for the maximum aim time when hit points of the AI is zero.
//props.wounded_shoot_imprec_plus = 0.5 // multiplier for the maximum aim imprecision when hit points of the AI is zero.

The waypoints:

- If the script will be the "brain" of your bot, the waypoints will be his "feet", or the roads! It's thanks to the waypoints that the bot will move. He won't exactly follow the waypoints but their positions on the map are VERY important for "a good move". For example, you can fix a "moving bug" (bot that can't pass a log by jumping all the time against it) by just moving the position of a waypoint a little bit "left or right", or changing its linking!

- Also, you're not obliged to entirely cover your map with waypoints. Pterodon's maps are, but don't forget those maps have been mainly used for the solo campaign, or for the "quick fights" mode. Your "AI" mates should be able to follow you anywhere on the map!
For the coop mode, I advise you to place your waypoints (and link them together) only in areas where you want to have fights. It will also help to keep your bots in those specific areas by "closing the path" and leaving empty places...

- The waypoint will act on a bot like a magnet also. If the bot "feels" a "hide out" place is in his "surrounds" (it can be set in the script), he will be directed to it to find...cover!

- You can also "obliged" a bot to go in certain directions "only one time", by linking the waypoints by pressing the [shift] key at the same time. It will be a "one way" linking. Depending of the direction the bot will "randomly" chose, he can go in completely different areas!
In this example (1), you can see how to avoid that a bot tries to go back a "hide out" waypoint on the hill once he went down of it. If you don't set a "one way link" and if the hill is too high, then, the bot may try to climb the hill by jumping continiously at the same place!

The environement:

- Give your bots "covers" to go hide behind! Each time you will place an object on your map, the Editor will (re)calculate the collisions; and those will be detected and used by the bots. It's important to test those covers like if you were going to use them for yourself. If a bot is continiously shooting into a rock (or a log or whatever), place it a little more into the ground or decrease its "Z" axe of few %, to "clear" the sight of the bot...

- Also, don't forget to correctly place your waypoints depending of the covers. The position of a "hide out" waypoint may completely change the "cleverness" of your bot because he will then use that cover for the best!

The inter-action between the bots:

- Bots from inside the SAME group will communicate together. I still haven't determined what was the "speaking distance" but as long as 2 bots are close enough, they will exchange informations about you, like your position. It partly explains why, sometimes, a bot is able to nade you even if he hasn't saw you personaly. A "bot's mate" probably told him where you were! lol
Note: It's a false idea to believe that a bot will only nade you because you nade him before. In fact, a bot will nade you if he knows you are "there" but can't shoot at you "the normal way" (with a gun). It seems that a bot is also able to see from where the "US nades" are coming from, and so, nade you back!

- If you spread 2 bots of the same group too much, they will stop to communicate and won't be able to set "tactics" anymore... It's very important to THINK where you will put your bots on the map, to make them act like you want!
You can also have a kind of "random" bots' behaviour by spreading your vc group cleverly on the map. For example, if you kill the "central bot" of a group of 7 bots, spread on a line on a map, you will also "kill" the communication between the other bots... You may have now created 2 vc groups of 3 bots each!

- If you set your scripts correctly, an "attacking bot" is able to move if the "covering bot" succeeds to force you to stay in cover, and so, unable to shoot on the bots. It explains on some of my maps (like VC_Storm_II) why you can be "surpassed" by the bots the more you will lose mates. The "attacking bots" won't be under fire anymore (or less) and will dare to advance because their "covering bots" will maintain you under fire, unable to reply! The next time you will "pop up" your head, you may find 5 or 6 bots in your sight! lol

- Bots are also sensible to guns' sound, and each gun has a "hearing distance" (same as the human one?). If you shoot with the M60 for example, you will activate more bots "inside the area" because its "sound range" is wider, compared to a M16 or a Thompson. Your first shots will act as a trigger...

You have to understand that it's the addition of all those "features" that will make your bot "clever" because he will be able to use them depending of the situation. Those informations will "feed" your bot with "intelligence" (scripts, waypoints, surroundings, AI mates...).
The more you will give your bots "possibilities", the more they will surprise you by creating their own "artificial tactics", to mislead you! Smile

I also advise you to have a look on my "How to correctly name and set your vc scripts" thread.

Under Construction (this post may still be updated in the future)!

Edited by Intruder on 14-06-2017 21:36
  x 6  x 1
How to optimize your map:

The optimization of a map is almost never made by mappers but I really advise you to apply it to your scene, even if it's a boring task to do that can also be very tricky to set!
The better will be the fps of your map, the more she will be played, even for those with a very basic pc!

I would say there is 3 ways to optimize a map:
- By linking objects to dummies.
- By using the "clipping option" of an object.
- By using the "clipping option" of an object LINKED to a "clipping dummy".

The Dummies:

The dummies can be used for more "things" but usually, we are using them to optimize the map, to have "better" fps and to help the Ptero Engine to be more efficient.

This is what is written in the the Editor's help file:
Dummy is an auxiliary object used for scene optimization, scripts and other purposes.
When an object is linked to a dummy near it, the object tree search is faster, thus the game itself performs better. A dummy has a variable called "clip distance" which determines the distance from which the dummy and its children are not drawn anymore.

It's not really that the fps will be "better" but let's say that if a map has around 25 fps in the scene... With an optimization, the scene will still be smooth by moving the mouse. But without an optimization, with the same 25 fps, you will feel "stutters" (like a lag) in the scene!

So, the "main idea" is to put some dummies above the map (like +5 meters), seperated from each others by around 20 meters, to create "a grid" (it's up to you to "feel" the distance and the place)... Now, select all the objects in the surrounds of a dummy and click on the "link tool (P)" (11th icon above the toolbar). Now, click on the dummy and all the selected objects will be linked to it (1)... Repeat the operation as much as possible... If you made a wrong "click" and linked objects to the wrong "dummy", do the same but use the "unlink" tool instead (12th icon) and all your objects will be "unlinked"!

Clipping of an object:

If you can "clip" objects in the scene (we must NOT see those clippings, when we aim for example!!!) then, you will gain the fps... Because an object not drawn in the scene won't be "calculated" by the game's Engine! In this example at NuiPek (the view is from under the map), you can see that despite I gave the objects their own "clipping distance" inside the TOC bunker, I linked them to a dummy (2), having its own "clipping distance" (3)... The objects aren't not only drawn but also optimized for the game's engine "search"!!!
Usually, we are using those "clippings" with objects inside huts, houses, caves... Because of the shorter distances in such places, those objects would be real "fps eaters" if you let them at their full "view"!

Clipping of an object linked to a dummy:

In this last example, I'm showing you how to cleverly use a dummy in certain circumstances... In the first picture, all the selected objects (red frame) are linked to the dummy at the extreme right (green frame) (4). If you're wondering why I made such an "unusual" linking, the explanation will be in the 2 next pictures!
The PoTlongKarai (NVABase) map is very tricky to optimize because the scene view distance is rather big (above the 100 meters) and the "direct view" on some objects can be completely different depending of the place we are looking at... That's why it's very important to "analize" the map to find the best "compromizes". So, in the trench (at the respawn), the view on the trees and the bushes at the end of it is "direct" and at "full distance". However, once we quit the trench, it's not really a problem anymore because those objects are closer of the players. The "trick" was to link those objects to a dummy "outside" of a normal position and set to a distance of 100 meters (in this case). But because, in the trench, we are still "inside" of the 100 meters range of that dummy, the clipping can't be seen by the players at that place...
In the next picture you can see how despite the clippings of the objects are set to the maximum, they WILL "clip" once we have passed the wall to the next part of the temple, because they have been linked to the dummy set "outside" of the map (5)! Because of the presence of the wall, all those objects weren't visible anymore and so, had to be "clipped" to gain fps! If I hadn't used that dummy, it was impossible to make the objects "clip" differently depending of the area we were moving on (6). The objects were affecting all the areas, even if we weren't seeing them anymore...

Note that the same "trick" is used for all the objetcs in each area "behind" the wall, and the biggest difficulty was to find WHERE to place those "special dummies" for the best optimization!
It's complicate to explain but I hope the pictures will help you to understand what was my goal...

I'm rather pleased to have you explained "this" because all that looong and booooring work CAN'T be seen by the players when they play BUT it had to be done! It explains you also why it takes me soo much time to update an original map to a VC_ or FA_ level because all my "editions" are full of those "unseen tricks"! lol

Under Construction (this post may still be updated in the future)!

Edited by Intruder on 05-10-2013 09:10
  x 3
How to correctly name and write your modes:

It may be just a detail but to help the players and the understanding of your "mode", I really advise you to follow the "naming process" Pterodon chosed from the start...
For example, the CTF mode we all know is for Capture The Flag, the RW mode is for Real War...and our dear Coop mode is for Co-operation. Note that in this last case, it has no real sense to call a mode just "C", that's why we have added the "oop" letters to the first one (and it's shorter)! lol

However, we have seen many different "unlogical" Coop names, like COOP, CooP, or whatever...
So, if we follow the original "naming process" created by Pterodon, a COOP mode would mean something like this, Co-operation Of Our Partners (COOP)... But if that Coop mode is globaly like the one we all know, it's a "wrong naming"!

So, be very careful when you create a new mode (or not) by respecting some "rules" to be sure it means "something", like Don Turtuma made it very well (just an example) by naming his new King Of The Hill mode... KOTH! Wink

Under Construction (this post may still be updated in the future)!

Edited by Intruder on 06-10-2013 07:17
  x 1  x 2  x 1  x 1
How to enable the players' flashlight for your nightmaps:

To enable the flashlight for your maps, you just need to add small scripts in your coop.c file.
Search the line(s) in your script and add or edit:


if (SC_P_IsReady(SC_PC_Get()))


Next, go further in your script and add this:

}// void SRV_CheckUpdate(void)

extern void SC_PC_EnableFlashLight(BOOL enable);

int ScriptMain(s_SC_NET_info *info)

Now, it should work "in game" by pressing the L key by default ! Wink

Under Construction (this post may still be updated in the future)!

Edited by Intruder on 12-04-2016 19:29
  x 1  x 1
How to correctly name and set your vc scripts:

As I've already said, I'm not a scripter and my knowledge is mainly based on trials, errors and comparisons... However, with the time, I think to have succeeded to find the best way to correctly set the vc scripts to avoid errors. I've read many times that if we uncorrectly set those vc scripts, it may create troubles and crashes!
So, I'm explaining you my way to set them correctly, by avoiding mistakes you could do. And the only thing I'm pretty sure is, your vc scripts will be stable!

The naming:

- To add a vc bot, we need to add a new "player" to our scene, and the editor will use that name as default (Player, Player#1, Player#2,...). However, I strongly advise to change that name with informations written "inside" the scripts we will use. It should be a lot easier to select the script we need to change during our future tweakings.

For example, we can name our scripts like this:


- Now, let's have a closer look on that naming process:


vc01, vc02, vc03, vc04,... The number of bots our map will contain, simply. Don't forget we can't exceed the maximum of 64 "players" (vc bots + real players) or the game will crash!

01, 02, 03, 04, 05. The ID_GROUP of our vc bot. The default number used in the level.c file is 5.

00, 01, 02, 03, 04,... The ID_MEMBER of our vc bot inside its own group.

A, B, C,... These letters will show what kind of .inc file we may use for our bot.
For example we can set 3 different .inc files to have different bot's behaviour in our map. A for, B for and C for

AK47, SKSS, DEGTA, PPS41,... This information will simply show you what kind of gun we assigned to the vc bot.

N, to indicate if we assigned (gre)nades (or not) to the vc bot.

And if we open the first script: vc01_01_00_A_AK47_N.c , this is what we will see:

#define ID_GROUP 1
#define ID_MEMBER 0

#define PKNIFE 0
#define PPISTOL 8
#define PWEAPON1 2
#define PWEAPON2 0
#define PWEAPONSLOT1 50
#define INIFILENAME "ini\\players\\net_vc_pajama2.ini"

#include ""

With all those informations, we can directly know what's inside our vc script, without to have to open them one by one.

The setting:

- Let's imagine we decide to add 30 vc bots on our map, in 5 different groups... All the vc inside the same group will act independently from the other groups but those vc will exchange "informations" (like your position) between themselves.
So, without to have a look inside all the scripts, here is the list of the scripts we will have:






- To end, we need to modify the initgroup.MaxPlayers in our level.c script:


//VC Groups - for COOP mode
initgroup.SideId = SC_P_SIDE_VC; //generic Vietcong
initgroup.GroupId = 0;
initgroup.MaxPlayers = 64; // nemenit !!! Erik.

initgroup.GroupId = 1;
initgroup.MaxPlayers = 5;

initgroup.GroupId = 2;
initgroup.MaxPlayers = 4;

initgroup.GroupId = 3;
initgroup.MaxPlayers = 8;

initgroup.GroupId = 4;
initgroup.MaxPlayers = 6;

initgroup.GroupId = 5;
initgroup.MaxPlayers = 7;

gphase = 1;
}// gphase switch


If you respect those simple "rules", you should have efficient bots and a stable map for fun actions! Wink

I also advise you to have a look on my "How to create "clever" bots" thread.

Under Construction (this post may still be updated in the future)!

Edited by Intruder on 10-07-2017 06:17
  x 4
Jump to Forum:
Locked Thread
Locked Thread
Locked Thread!
Similar Threads
Thread Forum Replies Last Post
Minecraftstyle Mapping Maps & Mapping 13 09-12-2015 10:01
Snow mapping Vietcong Tech Talk 33 10-02-2014 11:55
Advanced Mapping Maps & Mapping 6 23-09-2012 21:14
Mapping (Tutorials and Tips) Maps & Mapping 1 02-11-2011 01:44


Forgotten your password?
Request a new one here.
Render time: 0.26 seconds - 64 Queries 1,722,779 unique visits