Map Analyser Tool - Page 2

And G

Germany491 Posts

July 28 2013 22:52 GMT

#21

Attempting to analyze some maps of mine with this tool, nothing happens when I drop the files into the map analyzer window, and a few seconds later the program crashes. The maps are standard melee maps, nothing unusual. Any idea what might cause this?

-NegativeZero-

United States2142 Posts

July 28 2013 23:00 GMT

#22

On July 29 2013 07:52 And G wrote:
Attempting to analyze some maps of mine with this tool, nothing happens when I drop the files into the map analyzer window, and a few seconds later the program crashes. The maps are standard melee maps, nothing unusual. Any idea what might cause this?

I've noticed this happens when I try to load very old WoL maps - the map file format has probably changed a little bit since then. Other than that I haven't had any problems.

And G

Germany491 Posts

July 28 2013 23:28 GMT

#23

Ah yes, those are WoL maps. There's no working WoL map analyzer though, right? So what do I do?

-NegativeZero-

United States2142 Posts

July 28 2013 23:34 GMT

#24

update your maps?

And G

Germany491 Posts

July 29 2013 16:11 GMT

#25

Well I can't do that without HotS since I can't select HotS dependencies. Or am I missing something here?

meatpudding

Australia520 Posts

July 30 2013 01:01 GMT

#26

Looks like you are stuck for now. Trying to patch stuff up for another release and maybe load both WoL and HotS maps.

meatpudding

Australia520 Posts

August 05 2013 06:16 GMT

#27

Just made a new version. sc2mapanalyser_a5.zip

This version might be less stable that the previous one.

I've changed the entire rendering system from what it was before. Before I was using DirectX libraries but now I am back to using OpenGL with Freetype, libng and zlib. What that means is that making a port to any operating system should be easy now. A consequence of that is that major parts have been rewritten and maybe new bugs will start showing up.

One feature that I am excited to add is the "Siege Map." This layer will highlight all squares that can be hit from 13 range over unpathable terrain. This should finally answer the question of whether my minerals can be sieged from the third. Another use for this is for generating blink maps at 8 range, which shows where blink stalkers are likely to be a threat.

I found these results really interesting so let me know what you think.

+ Show Spoiler [Siege & Blink Maps] +

Akilon

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Bel'Shir

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

DW

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Korhal

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Neo Planet S

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Newkirk

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Red City

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Star Station

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Whirlwind

+ Show Spoiler [blink] +

+ Show Spoiler [siege] +

Some different attempts at getting blink map right: http://imgur.com/a/Mkbu2

eTcetRa

Australia822 Posts

August 05 2013 06:26 GMT

#28

Really cool work. Haven't had a chance to use it myself yet but I will have to soon enough!

And G

Germany491 Posts

August 06 2013 02:52 GMT

#29

Any chance you might add WoL compatibility? Also, since you already have siege and base layers, how about adding an overcharge layer for nexus range?

meatpudding

Australia520 Posts

August 06 2013 03:11 GMT

#30

On August 05 2013 15:26 eTcetRa wrote:
Really cool work. Haven't had a chance to use it myself yet but I will have to soon enough!

Cool, looking forward to it.

On August 06 2013 11:52 And G wrote:
Any chance you might add WoL compatibility? Also, since you already have siege and base layers, how about adding an overcharge layer for nexus range?

Yes there is a chance I will do both of those things. Liberty Mod maps are working for me at the moment, maybe the recent editor patch did something? Anyway if you could send the map that breaks I can take a look it should be an easy fix.

With the nexus range, the problem I am having is that I can't find the perfect base location for every mineral layout. Once I figure that algorithm out then i can add in analysis for mineral patches and geysers, as well as Overcharge range. (The "base location" at the moment is the average of the resource positions, which is close but not quite the actual base location)

And G

Germany491 Posts

August 06 2013 04:18 GMT

#31

Actually, I just figured out what the problem with my WoL maps is: the analyser crashes whenever the map has a custom preview image set. However, now that I can load my maps I noticed that the diagonal debris isn't recognized as a destructible blocker. Normal debris/rocks and diagonal rocks work fine, it's just the diagonal debris.

I've been able to replicate both issues on different maps. If you can't, I'll send you a map with both issues.

For the base algorithm, couldn't you just take all valid nexus locations with a distance <8 to the calculated average of the resource positions, then for each of those calculate the total distance to all mineral patches / geyers, and return the nexus location with the minimum total distance? This might lead to issues on weird maps like Koprulu, but for standard mineral layouts it should work perfectly.

meatpudding

Australia520 Posts

August 06 2013 04:47 GMT

#32

Cool glad you sorted it out. Soon I will add error reporting which will help with that kind of thing.

With the debris, I am aware there are lots of missing things. Some debris was always missing and all new HotS elements aren't added. Check footprints.txt because that is where it is all defined. You can try to add it in yourself. The error reporting will be able to show the names of missing items at least. I'm not sure how DimFish gathered the original footprints, seems like it was a mainly manual process. Unfortunately there are some missing items.

This the code I was using to calc the nexus. If you check Semmo's thread you can see that it's pretty lucky if it works at all.
+ Show Spoiler +


      // find best loc
      float minD = 0.f;
      for (list<point>::iterator i = locs.begin(); i != locs.end(); ++i)
      {
        float D = 0.f;
        const list<Resource*>& baseResources = base->resources;
        for (list<Resource*>::const_iterator j = baseResources.begin(); j != baseResources.end(); ++j)
        {
          //if ((*j)->type == MINERALS)
          {
            int dx = (*j)->loc.mtx - (*i).mtx - 2;
            int dy = (*j)->loc.mty - (*i).mty - 2;
            float d = sqrt((float)(dx * dx + dy * dy));
            D += d;
          }
        }
        if (minD == 0.f || D < minD)
        {
          minD = D;
          base->loc_custom = *i;
        }
      }

And G

Germany491 Posts

August 06 2013 06:39 GMT

#33

Cool, I didn't realise the footprints were externalised. Your code looks like the algorithm I suggested, however judging from the map positions it seems there's no validation whether a base can actually exist at that location. Without seeing the rest of the code I can't say what would be the best way to do this, but maybe you can place a base footprint at that location and check whether it overlaps with any nobuildmain footprints? Otherwise, since base footprints are squares and resource footprints are essentially two overlapping rectangles, you could do something like this:

+ Show Spoiler +

// find best loc
float minD = 0.f;
for (list<point>::iterator i = locs.begin(); i != locs.end(); ++i)
{
	float D = 0.f;
	const list<Resource*>& baseResources = base->resources;
	for (list<Resource*>::const_iterator j = baseResources.begin(); j != baseResources.end(); ++j)
	{
		if((*j)->type == MINERALS) float dx = abs((*j)->loc.mtx - 0.5 - (*i).mtx);
		else float dx = abs((*j)->loc.mtx - (*i).mtx);
		float dy = abs((*j)->loc.mty - (*i).mty);
		
		// check for footprint overlap
		if(((*j)->type == MINERALS && (dx >= 6.5 || dy >= 6.0 || (dx >= 5.5 && dy >= 5.0))) || ((*j)->type == GAS && (dx >= 7.0 || dy >= 7.0 || (dx >= 6.0 && dy >= 6.0))))
		{
			D += sqrt(dx * dx + dy * dy) - 3.0;	// add distance minus base and minerals sizes
			if((*j)->type == GAS) D -= 1.0;		// subtract difference of gas/minerals sizes
		}
		else
		{
			D += 1000.0;	// ugly but will work
		}
	}
	if (minD == 0.f || D < minD)
	{
		minD = D;
		base->loc_custom = *i;
	}
}

I changed dx to be calculated from half a grid field to the left for minerals as that seems to be the centre of the footprint. Also I removed the -2 in the x/y distance calculation which I assume was supposed to account for the size of bases, but a) the actual in-game collision box for bases is a circle and not a rectangle, and b) since you didn't calculate the modulus it effectively moved your results 2 grid fields to the bottom and right, so it didn't work anyway. There's also no point in subtracting a fixed value from distance results if all you're going to do is finding the minimum of the sums of those distances, but since you may want to expand the code in the future I subtracted the base/minerals/gas sizes where it makes the most sense. The code now assumes minerals have a circular 1x1 collision box that's in the middle of the 2x1 footprint, but I think that's a reasonable approximation.

You should probably double-check the footprints values, but if coordinates are implemented the way I think they are they should be correct. Obviously I can't compile, so it may or may not work as intended. :-)

meatpudding

Australia520 Posts

August 06 2013 13:15 GMT

#34

Well there it is just to see what it looks like.

+ Show Spoiler +

And G

Germany491 Posts

August 06 2013 14:04 GMT

#35

Well it sure looks like the base locations are correct now.

Sinistro

Brazil684 Posts

August 12 2013 14:44 GMT

#36

Nice feature, really nice feature indeed. Keep it up with the work. Since you said that it should be easy to port I will try to compile it in my linux station and see what happens.

edit: just to ask, the Akilon map that you're using, isn't the Akilon wastes one right? it doesn't looks like the Ladder Akilon Wastes.

The_Templar

your Country52798 Posts

August 12 2013 14:54 GMT

#37

On August 12 2013 23:44 Sinistro wrote:
Nice feature, really nice feature indeed. Keep it up with the work. Since you said that it should be easy to port I will try to compile it in my linux station and see what happens.

edit: just to ask, the Akilon map that you're using, isn't the Akilon wastes one right? it doesn't looks like the Ladder Akilon Wastes.

Looks like star station

meatpudding

Australia520 Posts

August 12 2013 15:31 GMT

#38

Yep

Fixed the images in the OP and added the correct link for version6. Added the photon overcharge images too.

And G

Germany491 Posts

August 12 2013 15:55 GMT

#39

For the next version, could you change the colours used to display height? It's hard to see the difference between mid and low ground with openness activated.

Speaking of openness, how is average openness calculated? It looks like it's just the average distance to the nearest non-pathable square for every pathable square on the map, is that correct?

ShadesofGraylin

United States32 Posts

August 12 2013 17:15 GMT

#40

I'm glad this tool got revived.

I found the source code for Dimfish's old version here on github. Is the source for your updated software available somewhere? I maintain the sc2reader library and am interested in exposing an API for map information. It seems that your software would be a good reference for map file formats and interpretation.

Thanks.

Prev 1 2 3 4 5 6 7 Next All

Please or register to reply.

Map Analyser Tool - Page 2

Completed

Ongoing

Upcoming