How to increase an tree's perimeter

[sethmachine]

Hi,

Consider the picture below, where the green arrow is a tree, the line is the distance between the tree, and the square is some unit.

Now, assuming both the tree and unit are static (they cannot move), I would like to decrease the distance between them by say half. What field in the tree object would I change to increase its "perimeter"?

I know it's not unit scale, and I hope to god it's not the pathing (because there's a limited set of those...).

(Note I am talking about game distance, e.g. distance like UnitIsInRangeOfUnit, etc. Not distance measured visually, but how it is handled internally).

 

[Dr Super Good]

It is the footprint. You can at most reduce a tree to 1*1 (default is 2*2 except some trees which are 1*1).

 

[sethmachine]

Footprint? What field is that? Or is that the pathing field?

I want to increase the perimeter. Wouldn't that mean having a bigger footprint?

 

[Pharaoh_]

Actually, he meant pathing, because those values are pathing blocks 1x1, 2x2, 2x4, etc.
I do not understand what you mean by perimeter. In our common terminology here, we say area of effect or range, as you pointed out through the function. However, what is the 'effect' in this case? What should happen if the distance is decreased?

From the broad description, I would also assume you are asking about pathing. You can create any kind of pathing, they are not as limited as you think. Creating a tga image (PhotoShop, Gimp, Paint (first save it as png and convert it through Warcraft 3 Viewer), Paint.net, etc.) of 3x3 pixels for example and filling it with the color #FF00FF, will generate the unwalkable, unbuildable yet flyable pathing block (which is what trees are using). http://www.hiveworkshop.com/forums/general-mapping-tutorials-278/pathing-everything-about-154558/

 

[Dr Super Good]

Actually, he meant pathing, because those values are pathing blocks 1x1, 2x2, 2x4, etc.

Sorry they changed this to "Footprint" in SC2, I forgot if it was called the same in WC3.

Basically what determines where a unit can move is a sort of "pathing image". It even used to be an image back in the WC3 beta but it was later changed to a special file format. Buildings and destructibles interact with this in real time by creating temporary modifications to it (applying another image over part of it). Doodads also use images to modify it but instead are done at "compile time" (when the map is saved in the editor).

The differences between real time and compile time modifications is important to note as the trigger function that returns if a point is pathable will only factor in the compile time pathability and not real time pathability.

 

[sethmachine]

The application is for increasing the "size" of trees/destuctables, so that way I can place fewer, but they have the overall effect of creating a barrier/zone/wall. This library below is the one I use to get a random reachable loc in some rect, where the loc has to be at least X range away from all destructables inside the rect (so no spawning units between trees, etc.).

Reachable Location Library

library RandomLoc initializer init

globals
	private integer count = 0 //if > 0, then there are destructables in range
endglobals

function getRandomPointOnCircle takes location origin, real diameter returns location
    local real a = GetRandomReal(0, 2* bj_PI) // random angle
    local real x = diameter * Cos(a) // x offset
    local real y = diameter * Sin(a) // y offset
    return Location(x + GetLocationX(origin), y + GetLocationY(origin))
endfunction

private function enum takes nothing returns nothing
	set count = count + 1
endfunction


private function isLocReachable takes location whichLoc, real range returns boolean
	set count = 0
	call EnumDestructablesInCircleBJ(range, whichLoc, function enum)
	if count > 0 then
		return false
	endif
	return true
endfunction
	
	

function getRandomReachableLoc takes location origin, real diameter, real range returns location
	local location randomLoc = getRandomPointOnCircle(origin, diameter)
	loop
		exitwhen isLocReachable(randomLoc, range)
		call RemoveLocation(randomLoc)
		set randomLoc = null
		set randomLoc = getRandomPointOnCircle(origin, diameter)
	endloop
	return randomLoc
endfunction

function getRandomReachableLocInRect takes rect whichRect, real range returns location
	local location randomLoc = GetRandomLocInRect(whichRect)
	local integer i = 0
	loop
		exitwhen isLocReachable(randomLoc, range)
		call RemoveLocation(randomLoc)
		set randomLoc = null
		set randomLoc = GetRandomLocInRect(whichRect)
		set i = i + 1
	endloop
	//call print("found a random loc in: " + I2S(i) + " tries.")
	return randomLoc
endfunction


private function main takes nothing returns boolean
	local location l
	set l = getRandomReachableLocInRect(Rect(-15520, -3904, -1216, 8384), 1000)
	call CreateUnitAtLoc(Player(0), 'hfoo', l, 0)
	call RemoveLocation(l)
	set l = null
    return false
endfunction

private function init takes nothing returns nothing
    local trigger t
	set t = CreateTrigger()
	call TriggerRegisterPlayerChatEvent(t, Player(0), "-loc", true)
	call TriggerAddCondition(t, Condition(function main))
endfunction

endlibrary

This post is not about optimizing the library, or optimizing the placement of trees (e.g. preventing any nooks or crannies).

I just want to increase the "size" of a destructable, so a unit being spawned would have to be further away, so to speak.

So, this would be its area, right? (let's extract away from WC3 implementations for now). I was using the wrong terminology when I said perimeter.

If a tree has a bigger area, it therefore takes up more space, and thus while the distance is the same (e.g. X = 500), the bigger area it has, the harder it is to find a suitable location.

In the limit, as the trees' areas increase, it becomes increasingly unlikely to find a suitable point (all locations must be at least X distance away from all trees in the rect).

So since area is just a real value, what field inside a destructable is "Area." Or whatever makes it "bigger" in reference in the library I put in.

From the posts, it sounds like the pathing field is indeed what determines an object's area.

I am guessing, though, that pathing combines both area and shape? For example, are all WC3 objects really circular? Square? In terms of the "area" they occupy?

Also, how do I make a unit's sizing scale reflect exactly the space it takes up?

 

[Xonok]

Area enumerations only consider the centre of the object. This can be observed when making custom spells with channel. A 300-size area image will appear to hit more units(they turn green) than a 300-size enumeration includes.

 

[sethmachine]

Alright can we stop beating around the bush, though.

What field in destructable will make it bigger with regards to the library I am using? (i.e. see the OP with the pictures).

So since area is just a real value, what field inside a destructable is "Area." Or whatever makes it "bigger" in reference in the library I put in

For example, "usca" (unit scale size) increases the scaling size of a unit and is real valued. Or "upat" is the pathing (texture) for a building. It expects a pathing texture as input.

So, what is the name of the field to change the area of a destructable?

Alright can we stop beating around the bush, though.

What field in destructable will make it bigger with regards to the library I am using? (i.e. see the OP with the pictures).

So since area is just a real value, what field inside a destructable is "Area." Or whatever makes it "bigger" in reference in the library I put in

For example, "usca" (unit scale size) increases the scaling size of a unit and is real valued. Or "upat" is the pathing (texture) for a building. It expects a pathing texture as input.

So, what is the name of the field to change the area of a destructable?

See these images for comparison

In the first picture the tree has its normal area. In the second image I increases the area of the tree, so now square and tree (green triangle) are closer as a result.

What field in destructable corresponds to increasing the area, as shown in the two images.

Thank you ^^

 

[Vinz]

Perhaps Pathing Texture for Destructables/Doodads? Or it maybe the same, Scaling Value.

 

[Xonok]

Read my post. Enumerations don't work like that. You'll have to make your library consider this instead.

 

[PurgeandFire]

Xonok is correct. Destructables are enumerated based on their source coordinates. Unlike units, destructables do not have a collision property (iirc). If they did, that would be the field to change (although, the distance would still remain the same since distances are measured from source coordinates [except for things like IsUnitInRange], but it depends on how your thing is coded). Since they don't, you'll have to resort to something else, e.g. pathing.

 

[sethmachine]

So to summarize it's not possible to increase the area/pathing of a destructable for purposes of the library I shown (i.e. as a tree takes up more space becomes increasingly unlikely to find a suitable location). Nevertheless the library still works.

But essentially what I wanted to do was create a special destructable that was invisible but could have a big area, acting like a "pathing blocker," which would get enumerated and therefore I could make an area "unspawnable" simply by putting down a small number of these (also saving on number of destruables in the map as well).

Still can go with invisible destructable, but its pathing size / collision won't really matter for enumeration purposes if I understand correctly.

 

[WaterKnight]

You could pick with a bigger radius first, then in the enum function check the destructable's type/the range to the source point considering its value, to know if it really should count.

 

[Pharaoh_]

So to summarize it's not possible to increase the area/pathing of a destructable for purposes of the library I shown (i.e. as a tree takes up more space becomes increasingly unlikely to find a suitable location). Nevertheless the library still works.

But essentially what I wanted to do was create a special destructable that was invisible but could have a big area, acting like a "pathing blocker," which would get enumerated and therefore I could make an area "unspawnable" simply by putting down a small number of these (also saving on number of destruables in the map as well).

Still can go with invisible destructable, but its pathing size / collision won't really matter for enumeration purposes if I understand correctly.

Well, as a last resort, if I got it correctly, you could have the main destructible and spawn invisible ones nearby. Store them on the main destructible and adjust your code to also take the sub-destructibles into consideration. You could also create a rect, loop through the locations within it and set them to unwalkable and unbuildable. Register the rect on the destructible and check its width and height, before you make the actual enumeration.
At the same time, if pathing is indeed checked before the map's loading and not real-time, as Dr Super Good said, then there should be a file in the map that creates a pathing image (just like minimap) [not checked, just a speculation]. You can get that with an MPQ Editor and edit it to your needs.