Movespeed modification on Strategic Map

Lately i tend to throw out a lot of stuff here, i hope you dont mind...
This feature is also based partly on the regions-scripts.

The main idea is: Currently there are only 2 modifiers on overland map regarding speed/terrain penalitys. Traveling during night and through forest.
Now the idea is to make this way more advanced and take actual regions into account.
For example:
plains in snake land are easier terrain than plains in Ashenborn (Ashenborn is supposed to be a wild and rough land).
So moving on Plains in Ashenborn should get a speed penality (lets say 10% less speed).

Moving in snow is always harder, so snow terrain gets also penality.
But steppe is mostly a flat terrain without any obstacles, perfect for riders -> so Jatu steppes give +10% speed

So far this would benefit everyone. But we can take this even further:
Lets say everyone gets speed penality in plains-Ashenborn beside the Ashenborn faction. This would simulate that they know the terrain very well and can move faster.

Also: ever thought that roads in m&b are basicly useless? not anymore. With that system traveling on road will give us 20% speed bonus.

Numbers are just made up, this needs tweaking of course.

Now to the technical side of things.
I wrote the script and tested. Now with all the checks running (mainly the region checks) for every party on the map several times per second this slows down the game hugely.
Instead i thought: ok, lets only take bigger partys into account: for example only Kingdom Partys.
Based on that the game runs fine without lags so far (always depends on the amount of partys to be tested of course)

Its only an idea currently so i am looking forward to your thoughts and critics.

I like it

I think this is a great idea, and if the system can handle the checks for Faction-bonuses in their homelands more the better! If done right this could become a massive feature for the mod.

And I don't think anyone minds you making posts here; you do your own scripting after all!

ohh I like this idea as well

Sounds good I hope this is doable

One idea to make the thing more efficient would involve preemptively computing a few things. You can reduce the number of regions that you need to compare to each party by chopping up the world map into a regular grid and then storing a reference to the list of regions that are in each square of the grid. A fine enough grid should get the number of comparisons down to zero in most cases, one or two at the worst, at the expense of having to cache all that info somewhere. We can use python to automate how that gets done, but it'd add a bunch of useless resources to one of the text files.

Restricting the regions to convex polygons would be helpful, in which case the the fewer sides, fewer constraints. In general, I'm finding that the way to go is to store the equations that go with each side and compare them with the point (at least, when the point is likely to be outside the region), and then we should put the sides in an order facing the interior of the map (or grid) so that the algorithm would have the greatest chance of bottoming out early. I haven't thought on it, but we might also get off with fewer computations by using rectangles orthogonal to the coordinate axes, but those aren't very expressive.

Finally, checking whether or not a point is in a circle is really quite easy. While for a polygon you have to check a whole set of constraints, a circle amounts to (x - a)^2 + (y - b)^2 <= radius^2, which is damn easy to calculate. I think that ellipses are about the same, but I'll have to check on that.

ok lets get technical, to be honest i am not sure if i really understood the concepts you are talking about completely, but i will try to show how the current algorithm works:
(Always keep in mind, i am more artist than coder, and my math class is several years ago =P)

The base is the point/triangle-collision detection. I choosed this over rectangles (which are defintly easier to compute, cause it enables me to layout a better fitting mask. Also i didnt used circles (which would be really easy to setup a algorithm cause i could use the already existing code for checking the distance to a party) cause they either would overlap or have spaces between them and as far as i know extracting a root is really expensive in terms of computation.

Instead i used the following grid setup:

Spoiler:

You see i covered the whole map with 22 triangles.

The algorithm to check for the collision can be found here:
https://prophesyofpendor.forumotion.net/t870-triangle-point-collision-detection-algorithm


To check for regions i did the following algorithm:
try_begin
check region1
if test fails
check region2
etc...
check region22
try_end

So basicly i drop out of the test as soon as i find the matching triangle (best case 1 check, worst case 22 checks)
based on this test i know now which region i have and can pass this as variable

now the speed_multiplier script works the following way:

- it will get called automatically everytime the games needs to check the skill modifier (this is a hardcoded behaviour)
- currently i check for the type of party and if its not a kingdom_hero_party i drop out (to save computation time)
- now i gather information : i run once the above region algorithm for that party
- based on that i change the modifier

thats it basicly

The main problem is that the game calls this speed_multiplier script several times per second for each party on the map that needs the skill modifier (its not documented if only walkable partys call this or also stationary ones, could be tested tough)
This means that in the worst case scenario every party checks 22times the collision with the triangles (assuming all partys gather in the last triangle) per second.


Now i wanted to avoid to get this too complicated, and i am really not sure about adding another grid above this - but i am of course open to ideas.
As far as i see it: the region test is the real bottleneck (with 22 checks in the worst case).
And this grid you mentionend could of course help to minimize this. But to be honest, i have no clue how to set it up and if its really needed.

I think its pretty optimized for now (its just way too many calls when i use it for every party)

The thing is: as soon as i use this filter (only allowing kingdom_hero_partys for example) this runs very smooth.
And for the main stuff thats all we need.

Edit:
Now i was thinking more about the grid, its actually a neat idea... a very simple aproach would be to just use a 2x2 grid
(no extra data needed, i can hardcode this into the scripts) which would turn down the number of calls for the collision detection from 22 to 10 in the worst case. Not bad, guess i will try this.

heres a possibly tough addition to this idea:a weather factor? possible? feasible?

Akuthia wrote:

heres a possibly tough addition to this idea:a weather factor? possible? feasible?

Hehe, to be honest i have already thought about this one, and really would like to see something like this implemented.

In M&B weather is only defined globally, taking this into account is totally do-able. (and doesnt need any further computations).
Weather in m&b is defined by 2 variables. Cloud and Haze amount. Thats all. Now linking these 2 to an slightly increase (for good weather) or decrease (for bad weather) of the speed is totally simple and done in 2-3 lines of code.

(But i am a great fan of a more advanced weather simulation - but for the sake of simplicity the above method is the way to go, If i should have a mind-flash (is this called this way?) i would try to script a simple region-based weather simulation instead.

My only problem with region based weather is the sudden changes between sunshine in Melitine and a snow storm in Santara, you need to find a way of fading between them

That said, there should be fog in the Snake Cult area (greenish colour if possible), imagine the might of the Cult thundering at you, and you can't see them until they hit your lines. Terrifying.

Mordred wrote:

My only problem with region based weather is the sudden changes between sunshine in Melitine and a snow storm in Santara, you need to find a way of fading between them

That said, there should be fog in the Snake Cult area (greenish colour if possible), imagine the might of the Cult thundering at you, and you can't see them until they hit your lines. Terrifying.

Sounds like a typical foggy day in any mount and blade game

Mordred wrote:

My only problem with region based weather is the sudden changes between sunshine in Melitine and a snow storm in Santara, you need to find a way of fading between them

Thats the main problem while designing such a system =) Maybe i have a good idea how to solve it, .... later =P

Quote :

That said, there should be fog in the Snake Cult area (greenish colour if possible)

This certainly inspires me: and it should be possible to do this (regardless of a region based weather system)
I will look into my fog-scripts i have from Scaedumar (its a simple script overwriting native-fog). We can define the color there, so linking this to the regions is relative easy (we will still face some limitations, like a abrupt change in fog color while fighting one battle in ashenborn and the next some meters into snake terrain the fog is green) -> but overall totally do-able.

We would need special skyboxes to fit this atmosphere, cause else it could look strange. Needs tests.

Yeah I have a feeling we will have to dedicate some time to making the Snake Cult faction properly, perhaps do the sky boxes, art and lore all in one lump so that we're all focused on the end result.

This is only a reminder for myself:

How to fade fog color to not have abrupt changes at the border to ashenborn and melitines:
After we checked that we are in Snake Region, we take the distance to their last city at the outer border to determine the "greenishness" of the fog. This way we can fade this a bit better -> the deeper we are into snake land the more green becomes the fog.

Also: A quick idea how to implement a weather system and fade it:

- each region have its own weather variables (cloud/haze)
- we have a trigger to update weather situation lets say every 2 hours
- new weather = old weather +- random amount
- after we randomized each cell we smooth it (new weather cell a = (new weather cell a + cell b + cell d) / 3
to avoid to hard changes

This is a first idea ...
If we make 2 scripts (the first randomizing the weather, the second smoothing it) we could also influence this per events:
lets say we want to have a storm arize -> we plant really bad weather into one of the cells, and smoothing it after...
In the the next steps this will either slowly go down (or spread over the regions, thats random dynamical of course)