#momo# 10 Posted October 20, 2012 Hello all I experience some strange behaviour of the ai when driving on the roads of my map, like the ai trying to leave the road, then get back on it, then leave it again, etc. It is not like they ignore the roads completly, but something is definitly strange. Now, I had something like a small accident that leads me to the question of this thread. When I first installed the bi-tools, I used an outdated version. So I installed the outdated version, then I used Mikeros Arma2P, and later I installed the new bi-tools, and then I started to work on my map. This week I had to re-run Arma2P. After this, all my roads in Visitor disappeared. I figured out it was because Arma2P was replacing the ca\roads2 that bi-tools installed with the one Arma2P extracs out of my Arma2 directory. So i re-installed the bi-tools and everything worked again. Out of curiosity: Does anyone know what the difference between the ca\roads2 of the bi-tools and the ca\roads2 of Arma2P is? May this be the cause of ai using my roads in a strange way? With which road set do you work, the pre-installed by bi-tools or the one Arma2P extracs? If I knew that rebuidling all my roads (about 40 roads, lot of work even with export-road) would fix the ai-issues, I would take the time, but I dont have the motivation to do all this work just out of a guess. Share this post Link to post Share on other sites
bushlurker 46 Posted October 20, 2012 Hmmm... AI "path-following" can be affected by a few different things.... "Base Texture Layer" size for one... "Ground Cell size" is another... are you doing anything "non-standard" or unusual with those parameters??? The roads models do have to be handled slightly differently - Arma2P knows that, and - should - take account of it during it's processing..... Basically..... Special "unbinarized MLOD" road models - with snap points built in - are required for the Visitor internal "Road tool" to work... Since the standard "game" road models are "binarized ODOL" models - they're no good! - So BI provide appropriate unbinarized MLOD models - installed along with the Tools themselves, so we can use the road tool.... BUT - to save space in the Tools install probably - these special MLOD models are - just the models themselves - no textures! SO - effectively, you need the MLOD MODELS from the Tools install, but the TEXTURES from the Unpacked Roads2 .pbo! ArmA2P knows this, so the usual procedure is to install the Tools Suite first, then follow up with Arma2P... During it's run, it - should - move your precious MLOD road models to a safe place - unpack and install the Roads2.pbo to get you all the textures - then drop your required special models back into place... Normally this works OK - though since I'm a Compulsive Backer-upper I usually save a copy of the CA\Roads2 folder before running Arma2P - just in case something odd happens and I want to replace those MLOD models without having to reinstall the Tools over again to get them..... B Share this post Link to post Share on other sites
jakerod 254 Posted October 20, 2012 Hmmm...AI "path-following" can be affected by a few different things.... "Base Texture Layer" size for one... This occurred on my St. Adam terrain. It sounds exactly the same as your problem too. All I did was increase the size another level and it worked perfectly. Share this post Link to post Share on other sites
#momo# 10 Posted October 21, 2012 I will try to play with base texture layer size then, its 20m on 20m now, ground cell size is ten metres on ten. I did had it on 40*40 once, but then, I had bridges that looked destroyed out of a distance. Seems in my case, Arma2P was overwriting the ca\roads2... Share this post Link to post Share on other sites
jakerod 254 Posted October 21, 2012 I will try to play with base texture layer size then, its 20m on 20m now, ground cell size is ten metres on ten. I did had it on 40*40 once, but then, I had bridges that looked destroyed out of a distance.Seems in my case, Arma2P was overwriting the ca\roads2... Probably not the base texture layer size although it may help to play with it I guess. I've used 20m x 20m before with a 10 meter grid and it worked fine. When I had my problem with it it was on a very small map with a fairly high res terrain grid. So I think you might be safe there but if you still can't get it it might still be worth trying. Share this post Link to post Share on other sites
bushlurker 46 Posted October 21, 2012 The Main Thing to remember with "Base Texture Layer" is that it MUST be bigger than your cell size! Otherwise you WILL get all sorts of weirdnesses.... You'll find the values you're offered are actually "tied" to your Heightmap Ground Cell Size... ie: if you have a 10m cell, the values on offer will be 10m, 20m, 40m, etc... if you have a 4m groundcell they'll be 4m, 8m, 16m, etc.... Ideally, you want to use a value that is "Two Steps Beyond" - that's what the engine "prefers"... so - with a 10m groundcell you'd use "40x40m", with a 4m one you'd preferentially use "16x16m"... However - (added complication alert!)... These values are also "tied" to "Satellite & Mask layer size".....! The engines "ideal preferred size" for these is 1 pixel per meter..... if your Sat & Mask layer is Higher-Res.... like the CWR2 terrains, for example - you'll find that the Base Texture Layer value that is "Two Steps Beyond" produces an (Invalid) warning!!! That's OK - we can "stretch" the rules - a little... you'll be perfectly OK with ;)B Share this post Link to post Share on other sites
mondkalb 1087 Posted October 24, 2012 Please be aware that the cost tiles used for pathplanning are generated generously around the geometry lod. Take the classic "tip of the iceberg" rock usage. Just a tiny portion of the rock is visible while the majority of the rock object remains submerged. Here an example on Takistan: Left the rock submerged with just a tiny portion visible, on the right the view from above with visualized cost values per tile. White being the most desireable, black being the least. http://i49.tinypic.com/2ldbode.png (1262 kB) This is an easily overlooked problem causing massive troubles for the AI. Share this post Link to post Share on other sites
lecholas 2 Posted October 24, 2012 Interesting, would the cost values be different, if the rock was reversed upside down (ie. if the wider part of it was hight above the ground, and the diameter of the rock's intersection with the surface was the same)? Such a situation is very ofthe for tree models (or buildings with balconies etc.) I think - narrow geometry lod near the ground and much wider above the ground. So in other words, it seems that the cost values are generated not around the geometry lod but inside the volume of geometry lod's bounding box... Share this post Link to post Share on other sites
bushlurker 46 Posted October 24, 2012 I wonder how a road passing under a bridge would visualise? I've had AI be very suspicious of "flyover" arrangements like that.... B Share this post Link to post Share on other sites
mondkalb 1087 Posted October 25, 2012 Not every tile inside the volume/bounding box automatically turns into a very costly tile, it depends on the the geometry lod's position and distance to the surface. Roads are very special cases, as they represent desireable road-nets that the AI in vehicles will prefer to use. The equivalent for AI soldiers would be the path-way lod of an object. (invisible path objects) Share this post Link to post Share on other sites
Robster 11 Posted October 25, 2012 Hi Mondy ;) I noticed this problem on a couple of spots in FATA roads sometime ago... and it can be fairly fixed by moving a rock a bit But, I'm not sure about serpent's road built as showing in RL sat pic, beacuse AI can't handle heavy turnings and usually chooses the most direct way to go across... and this map was specially designed to warn drivers about to not to try too many off-road trips nor trying to take shortcuts anytime, as we were used to see in the past... Share this post Link to post Share on other sites
