Checking when a unit is near or in a feature.

[smoth]

I want to write some code to check when a unit is inside of a nonblocking feature. When the unit is in the nonblocking feature not firing and still I want to set it to stealth with a detection range of 500.

I can probably figure out this no problem but my question is what is a cheap-ish way to do this? I don't think I want to do a check each gameframe for all units and seeing if they are in proximity to said features. So I find myself thinking is there a fast way to do it?

[bobthedinosaur]

awesome.

[SpliFF]

You can certainly optimise this to make it pretty efficient. I won't write the code but I can give you some tips on a good implementation as psuedocode.

Code: Select all

-- do this occasionally, because features don't change very often
for x in 1 to mapSizeX:
   for y in 1 to mapSizeY:
       if featuresInGrid(x,y) > 0:
           cover[x][y] = true

-- do this more frequently
for x in cover.keys():
   for y in cover[x].keys():
      for unit in getUnitsInRect(x-1,y-1,x,y):
          if (now - unit.lastShot) > 1sec:
              unit.stealthRange = 500

-- unit script
onFireWeapon(unitID):
   units[unitID].lastShot = now 
   units[unitID].stealthRange = 0

I think the biggest problem you'll have is that stealth range is probably (i don't know) a unitDef thing and may not be settable on a per-unit basis without some sort of on-offable jammer weapon on every unit.

[bobthedinosaur]

do you have to use stealth or jamming? can radar be blocked via lua?

[Niobium]

It really depends on the number of these features, and the number of the units that can hide, you'd also be able to speed it up a lot if the features are indestructible.

Also, stealth/cloaking are both possible through lua.

[knorke]

thats similiar how i would do it too but for
cover[x][y]
i would use a lower resolution ie 1/10 of mapsizeX, would probally be accurate enough.

[knorke]

green = no cover (no features in this cell)
red = cover (even the smallest feature or geo vent triggers this)

spawn units with /give and it will put a marker on them telling if the unit is in cover or not.

the cells are actually squares and not octagones but how do you draw lines or rectangles in spring lua?!
well, the drawing is just for demo anyway.

local resolution = 100
can be changed. too small and drawing the cells will kill fps. setcover and getcover should not get slower, just need more memory.
also no error checking blabla.

[bobthedinosaur]

why wouldn't monitoring a specific unit type's proximity to certain areas with feature in them be more effective?

that is pretty cool knorke, but seems like over kill.

[smoth]

because you would be checking constantly every unit to feature. This way you just check unit location then if location is in zone.

[bobthedinosaur]

can a zone be done in a preload, and modified if new features are added?

also not all features or all units should be affected. Gundams/ tall units cant hide behind car rubble/ small features, so how do you differentiate heights? would categorizing features and units into height classes be faster than doing on the ball height checks?

[smoth]

can a zone be done in a preload, and modified if new features are added?

Not for the gundam maps. They have placement done an game start. I think knorke added something to update for features added/removed but I don't remember.

also not all features or all units should be affected. Gundams/ tall units cant hide behind car rubble/ small features, so how do you differentiate heights? would categorizing features and units into height classes be faster than doing on the ball height checks?

The zone code exists as a pre-check, once you establish something is in cover you can then add further constraints.

[knorke]

this stupid laptop crashed, short version:
-getting a value from array is faster than looping through all features all the time
-you could update cover array as needed. ie when features get destroyed
-instead of cover being just true or false it could be from 0% to 100% cover. you could define the cover percent based on number, size, type etc of features in a cell. different units could have different cover_needed ie 25% for a scout, 50% for a tank, 80% for a tank.

[knorke]

some for anyone who wants to make this a real working gadget, it might go like this:

local cover= {}
Initialize()
build the cover array
(the stuff that is in Initilize in my widget)

GameFrame()
every n-th frame:
loop through all units
x,z=getunitposition (i)
isCover = getcover (x,z) --this function is in my widget
if isCover then
Spring.SetUnitCloak (unit, true ,3)
else
Spring.SetUnitCloak (unit, false ,3)
end

http://springrts.com/wiki/Lua_SyncedCtrl#Unit_Handling
the 3 means no energy used for cloaking

[knorke]

since nobody cba to make a somewhat working demo:
http://www.youtube.com/watch?v=7A0tTHNpDgs
b = draw this cell thing.
the inner circle shows much cover this cell provides.
(so you could have big units require more cover etc)
the drawing is only for testing, uses no display lists and so lags like hell.
without the drawing i noticed no fps lose.

Then opend S44 to see if it has a feature_def thing i could use for further testing and noticed it has a game_visibleCover.lua
So yeah, how many wheels do we need to invent.

[Forboding Angel]

Well unlike this, 1944's isn't dynamic.

Couple of issues so far:

screen00314.jpg

(1.95 MiB) Downloaded 2 times

^^ it isn't updating when a feature is destroyed (I'm guessing probably not when a feature is created either)


It doesn't seem to count features that the units can walk through as cover zones.

screen00315.jpg

(629 KiB) Downloaded 2 times

In Evo's featuredefs post:

Code: Select all

for name, fd in pairs(FeatureDefs) do
	if(tonumber(fd["footprintz"]) < 2 or tonumber(fd["footprintx"]) < 2 
	or string.lower(fd["category"]) == "vegitation" or string.lower(fd["category"]) == "vegetation") then
		fd["blocking"] = false
	end
end

Oh and turning on debug lags like holy hell like you said, but meh, it's just a debug mode, I'd comment it out anyway once I put it into use.

This is uber cool so far

Edit: god these forums suck dick. Posting thumbs from imagebam.

[knorke]

It doesn't seem to count features that the units can walk through as cover zones.

nah, thats not it. See the video or engines trees. Actually in the video all features were drive through for easier testing.
There is maybe just a hole in the cover grid at the units position.
If not, post screenshot with debug mode on.

It does not update on creation/destruction of features because I did not add that yet

At the moment even the smallest bush can hide the biggest mech.
I am thinking of something like this:
custom parameter in featureDef:
provided_cover = 5,

custom parameter in unitDef:
needed_cover = 5,

Then it would add all the provided_cover of features per cell and compare to the units needed cover. (Actually it is almost like that already.)

Those parameters could either be set by hand or via featurepost/unitpost based on footprint,height,radius,name,...
If a unit has no needed_cover, it will not be able to hide at all. (ie aircraft)
There will probally be TONS of special cases (ie aircraft on ground should hide) and I do not feel like going through all of them, instead this will be more like closeenough.jpg

[Forboding Angel]

the picture of the comm was with debug mode on.

And yeah I agree with your assessment. Should provide a nice balance.

[knorke]

oh, thats strange.
Did other features provide cover when that happend?
If yes, I have really not idea how it could happen.
If no, then maybe just the gadget crashed. (in that case, infolog)
Also on /luarules reload it recalculates the cover.

[Forboding Angel]

Well that's just the thing... It didn't crash and nothing provided cover. It was as if it didn't realize that the features were there.

I was assuming that maybe you had added a contingency for non-blocking features or something (even though after 2 scouring of the code I couldn't find anything of the sort).

Oh also, could you add a thing where features by name could be excluded from providing cover?

[knorke]

Oh also, could you add a thing where features by name could be excluded from providing cover?

yea, possible.
would best be done in featuredef_post as:

Code: Select all

loop through features
 if featurename contains "blub" then  feature.customparams.provided_cover = 0