DarkAngel

24 minutes ago, Bond_Villian said:

Is that the one that causes units to be facing the wrong direction when they 'jump to end' ?

no

3 minutes ago, ben said:

 

I did some testing in editor to answer my question;  it appears that the latest created routes always take precidence.

 

So; conditioned routes are evaluated in order of "youngest" to "oldest".

this can go out the window if you paste them.

6 minutes ago, Ssnake said:

Create routes from the spawning unit and apply a "jump to end, if..." condition with randomization if you want the units to appear in different places (IF they appear). Careful, though. the more layers of randomization you add, the bigger tha chance that you will miss a branch later in the design process. You should have a clear idea first, then create the randomization for one prototype unit, and finally copy the initial routes to all other units so that they all jump to a similar location on spawn, rather than being a complete chaos. This is why you need numbered random variables that stay the same for the duration of the scenario, so you have coordinated random behavior.

 

We'll post a youtube tutorial to cover this topic in the coming weeks.

Nils, please look at bug 7598

5 hours ago, ben said:

 

By the way... Is there any way to know in what order the conditional routes will be evaluated?  Is it based on order of creation?

This is why the best way is to only have 1 conditioned and 1 non conditioned route.

Here is another option:-

From a waypoint have 2 routes. One is just a short (say 10m route) which ends in a no tactic waypoint.

Short route Logic:- 0<= Random Variable New <90

Longer route no logic.

From the end of the short route 2 routes:-

route 1 logic:- 0<= Random Variable NEW < 50

route 2 No logic.

23 hours ago, Stevo said:

If you are just about to launch you are doing it wrong. The Launch carat ( ^ ) has to be on the target when you launch.

Just looking at the picture i can tell you a lot of that data is erroneous.

1 hour ago, stormrider_sp said:

Now to be even more practical, I invite you to check the Suwalki gap map. I don't want to sound rude, but it's horrible. And I can't blame the author. Mainly because despite all the evidence, all the sources are wrong and are not DTM: they are all DSM, which means that you're importing a data thinking that the height of buildings and forests and trees and water wells and everything above the ground was removed from the data only to discover that it was not and a virtually flat area is now filled with bumps and lumps exactly where buildings and forest area. The right procedure should be to process this data using a mask to remove the height from the forests and building effectively converting it from DSM to DTM, but once the map is imported, not by me, the damage is done and I wouldn't dare asking the person to waste his time doing my job, again.

 

Hmmm... wonder who that could be.. 

I made that map knowing full well that it was DSM data but it is better than any of the other public data sources. The options are 90m srtm which is too low res. SRTM 30 which is incredibly noisy especially in low lying areas and where there is sand or exposed water. So for me the best data of the bunch currently available for free is JAXA.

Now you can start crowing about LIDAR data. Believe me I have looked at a lot of this data and it is SHIT. It is just as noisy as the JAXA or SRTM 30... In some ways worse as the point spacing is much closer together so you get high frequency noise. Then of course you have all the erroneous data from solid objects, buildings, parked cars.

Then your next problem with a lidar based map is vector data. Sure there is a nice free source in OSM which I use a lot but it is WAY too inaccurate to use with a LIDAR based map.

This is already in bugzilla

investigating

Now I did notice that if you plot a direct route from the bridge layer across the river using Navmesh rather than a discreet route then it also seeks to avoid the river. A case could be made (as an extended feature or an enhancement) that a bridge layer given a direct breach route which crosses a river might have a special rule. This would require a fair amount of thought though:-

1. Does the bridge layer have a bridge on board
2. is the bridge long enough to cross the water body
3. is there only one feature to cross.

Currently it is using the "one size fits all" system.

A discreet route of course could not know this as you could be sending anything into it.

This wouldn't work for the mission editor as the graphic is only created in runtime.

Well the system doesn't know what type of unit you are sending into a discreet breach route. You could be sending a miclic or an AEVinto it, in which case you would not want the system to turn off the Navmesh following behaviour and sending them to their deaths in a river. This decision has to be with the mission creator. 

Ok I am guessing the route in question is the one near 3/A. This route was plotted with navmesh on which is why the route is avoiding the water. (With "Hold alt to plot navmesh route" off / unticked ) if you try and plot a route between WP 6 and 7 the route will avoid the water. If you instead hold alt (to plot a non navmesh route) between wp 6 and 7 then the unit lays a bridge just fine.

What Nils is saying is about subsequent units During runtime if plotting a navmesh route after the bridge is laid will find the route across. This will not work in the mission editor though as the laid bridge is not present while plotting the routes. In this case you have to use a NON-Navmesh to get them across the bridge which will be there.

if it is off and you hold alt to plot a route it will be a non navmesh route

if you click on that menu item it will be turned on or off.. Same as it has been since the navmesh was introduced.

Well it works for me. If there is a tick on that item then i have to hold Alt to create a navmesh route. If there is no tick then I don't have to hold alt to plot a navmesh route.

Yes that item in the menu is also a toggle

No it is immediate and it is saved

7 minutes ago, Gibsonm said:

 

Yes but that means every time I want to create one with a Navmesh I need to hold down the ALT key?

No, it's a toggle and the setting is saved. 

yes it is saved

The option for "Hold Alt for navmesh route" is under options when in the map view (F5)

i have nothing to do with the documentation so can't help you there. Just relaying the information i do have.

it's a feature. Graphics are saved in a different file now allowing them to be loaded in even if the scenario has changed. Unlike a pln file.