Mexes which claim a percentage of a polygon| cloud, not a radius.

Mexes which claim a percentage of a polygon| cloud, not a radius.

Discuss Lua based Spring scripts (LuaUI widgets, mission scripts, gaia scripts, mod-rules scripts, scripted keybindings, etc...)

Moderator: Moderators

Post Reply
User avatar
NeonStorm
Posts: 173
Joined: 23 May 2012, 18:36

Mexes which claim a percentage of a polygon| cloud, not a radius.

Post by NeonStorm » 08 Sep 2015, 13:39

I have played a map, I think it was "Desert dunes" where you could place T1 mex about anywhere, but no T2 mex.
((Result was that upgrading reclaimed without building T2 and stopped the constructor from working))

In these cloud-metal maps, I waste so much time babysitting mex placement, that it isn't fun to play anymore, but I got an idea.

I got the idea while reading "detecting metal spots", viewtopic.php?f=23&t=26030.
SinbadEV wrote:Obviously I'm not anything like a map lua coder but... couldn't you include both (or more) algorithms... make some kind of cursory analysis of the metal map (including extractor radius... one would assume a tiny extractor radius implies a ota style metal placement strategy) and then run the appropriate algorithm?

edit: Categories of metal placement
Core Prime (whole map is metal)
TotalA (metal spots smaller then the extractor radius)
Clouds (metal spots larger then the extractor radius or spread out and diffuse metal)
Jerk (metal map intentionally designed to screw up metal placement algorithms)
Perhaps the problem is not the algorithms but that there is zero tolerance of how to place a mex correct to get most out.

My idea:
  • scan the map for clouds. Create a polygon for each cloud.
  • A mex occupies a percentage of the whole cloud independent on the position inside the cloud.
  • Bigger clouds may require more mexes to be fully occupied.
And then I thought about how to fix maps where one cloud covers the whole map:
  • also create sub-polygons for denser areas (similar to the high-map-view).
  • Mexes could have a higher priority in one polygon, the closer it is in the hierarchy tree.
  • Loops around an inner polygon can get split into territories which split on branches and prioritize the closest mex.
Obviously there are flaws in my initial thoughts that the first mex could generate 1000m/s or that 1 mex could be placed 1/2 in one 1/2 in another polygon and for which it should register.
I would give each mex a maximum extraction value to fix the first issue
, and Split a mex into sub-mexes occupying 1x1 square each to address the second mentioned issue.


I am interested into feedback before I spend more thoughts on this.
It is a very easy algorithm based on Run-Length-Compression of lines and connection of parts overlapping similar parts in adjacent rows based on start/end positions.

The more difficult question is how it would affect balance on these maps and that is a question I currently fail to find an answer for.
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7008
Joined: 16 Nov 2004, 13:08

Re: Mexes which claim a percentage of a polygon| cloud, not a radius.

Post by zwzsg » 09 Sep 2015, 20:16

NeonStorm wrote:
It is a very easy algorithm [...]

The more difficult question is how it would affect balance on these maps and that is a question I currently fail to find an answer for.
Then try and see!

Experimental method best method.
0 x

Post Reply

Return to “Lua Scripts”