Will we be able to create own mods for the flowfield?

@redn4x thank you. Finally one getting what i want to do.

@menchfrest thats why i am talking about 3 fields. One for the needs. On for the creators. And one to distribute the workers.

@kvalheim well i want to do such a mod. And for this to happen i need to mod serverstuff even if it wont happen with flowfields.

I actually would be interested in being able to either paint flowfield for units, or being able to directly command units not to enter a specific area. Even if landmines are not in the game, sometimes you want your units to hug rock formations or something, so would be nice to highlight an open field and tell your units to avoid it as if it were a costly steep hill and instead go around it hugging mountains and plateaus on its edge.

Is what I thought about the stream. Any thoughts on that? Besides, that might be kinda like what that guy meant, making a mod to auto-play for a player based partially on flowfield manipulation for one's own partially enabled AI.

BASICALLY, will all this flowfield algorithm generator and the numbers set by the devs for it to calculate cost with, can the modder access the generator or the number cost set, and adjust it to turn it down, turn it up, or change how it acts for certain units or something? The strings that attach it to units and such...

Here's the thread you are looking for, sir: viewtopic.php?f=61&t=44821

You use waypoints, queuing move commands etc. Like how you hug walls in every other RTS

Why are you guys all so withdrawn from innovation??

You cannot effectively hug walls in other games with lots of units because they will spread out and exactly not hug the wall. They will only move next to it.

But this is off topic here. So let's not hijack syox's thread. That's why I posted the link to the actual thread on that topic.

Innovation requires prior knowledge.

Many people are seeing these things for the first time.

I dislike negative nancys myself. Also, I know what I am talking about, I am not stupid about this stuff.

That being said, I am only asking for them to leave the numbers or the calculator within modding ease. You know, make the numbers seeable on each unit or something, or leave a editable file with the numbers and what strength they are calculated to.

Another thing I thought during the flowfield stream, was that whatever he painted was avoided by the bots WAY too extremely. They would go around a mildly green blob by going across the planet before they passed through it which seemed to me to be faster anyway (unless they literally clicked into the shaded area, to which there was no choice but to go into the shaded area in order to get inside the shaded area).

I wouldn't mind having a way to lighten up my unit's flowfield calculations. Them going miles out the way to avoid a mild slope seems harsh.

The very fact you say this shows you don't really understand the flowfields.

Units ALWAYS move towards the lowest value. They avoided cost so extremely because it has a higher value than any others.

It was nothing but a tech demo. The "cost" didn't actually do anything - it never slowed them down, it was simply a fun way of painting down virtual obstacles. In the real game, aside from modding, you wouldn't be able to directly write to the flowfield, so issues like that are non-existent.

causeless, you're the one who doesn't understand FF.

It's not about the lowest point, it's about the lowest path. The one that is cheapest overall.

double-post

Because most people still don't get that constantly "painting" cost ingame to achieve a certain micro-behavior would be (a lot) more effort than good old shift-clicking waypoints and propose the wrong kind of innovation as a result.

No RTS has *ever* enabled players to directly modify underlying pathfinder data-structures, for good reason. And don't think it's a new idea, manipulation of the cost function would just as easily work / be possible without a flowfield-based pathfinder system.

For mods they might of course be exposed to some degree, but that's a different discussion.

This. Think of it as adding up the cost at each point along a path to the goal. You want to go down the path has the lowest total cost from A to B. Going "into the green" would result in a higher total cost, so it doesn't go there unless there is no other way. In the absence of anything else, a unit would walk around the entire planet to avoid a 1 point cost green line. In reality though, squares closer to the goal are cheaper, so at some point it becomes more cost effective to cross that green line than to continue to move further from the goal. The cost of distance is simply tweaked to get the desired avoidance of obstacles vs no-detours ratio.

I think I get what you're saying. Workers go to nearest need based on the need field, they go to the nearest source based on the creator field. I had kinda assumed you included something like this.

The worker field, I had assumed was for crash avoidance, if you meant it was for spreading out the workers, you have an issue.

The worker field you mention would have to avoid the problems I talked about, but the thing is the work involved in making the worker field work, you're actually doing 90%+ of the work to solve the problem the other way, and then extra work to turn it into a flow field.

Dont talk garbage, watch the video again and you will see units do slow down.

Then explain to me how would you achieve a "hug the wall" move with your additional waypoints? You don't.





http://i.imgur.com/K80uFW2.png

Well thats actually what i want to talk about in this thread. See title.

@menchfrest: Well its quite hard to discuss that without actually playing around with the flowfields. But i hope its doable with linearic decreasing cones around the workers.
Maybe also changing the values on these distribution costs the workers generate, is a way to go. But then again we dont know how or even if this is doable, also a fixed based system would be better.

After all its not about creating the perfect logistics system, but something that works and has a organic feel to it(like watching a anthill), and is slightly optimizable by the all infamous MICRO.


EDIT:
@thelambaster good point.

Actually, they did clarify that, they were directly editing cost values without any impact to unit motion.

I think it's perfectly fine of an idea to expose a modding API for using flow fields, as they do have a lot of application beyond pure pathing/can be used to easily apply special pathing behaviors that are desired. Not sure why there's backlash :S

It finds the lowest path, by following the stream of close lowest points.

They appear to slow down, because when they need to suddenly turn (as they do around these cost areas with a sharp fall-off), they rapidly decelerate to try and turn to the correct direction.

If he painted down some cost with a low fall-off, they'd appear to take a path that has them stay further away from the cost, and turn smoothly and have less sudden velocity and acceleration changes.

There's no actual mechanic in the cost field slowing units down.

And in what kind isn't that a slow down? Nah i admit thats different then what we talked about.

You would obviously need to assign more than one intermediate goal.

You are also making some assumptions in your example, namely that

1: you can manage to add exactly the right amount of cost on the fly to overcome a group's tendency to spread out laterally, no matter the number and type of units of which the group is composed
2: groups won't bifurcate anyway, since (depending on their size and composition) the dynamic cost added by units in front can make crossing the horizontal region near the start and staying to the left of your cost-ridge more attractive to units bringing up the rear

It could work, but you would have to use a broad brush, fast strokes and lots of red paint.