Checking when a unit is near or in a feature.

[Forboding Angel]

Oh ok, yeah that works

[Forboding Angel]

Have there been any recent advances?

[knorke]

not really, sorry. no time and inclination
maybe beginning of next week.

[Forboding Angel]

Haha, no worries, I'm just excited is all

[knorke]

Now updates cover on feature created/destroyed.
Also now each unit only hides when provided_cover >= needed_cover.
Noticed that units decloak when firing which is fine by me.
While playing around it actually looked quite cool when you drive by some bushes and suddendly tanks shot at you.

Also hidden units can not be seen no matter how close you come to them, even if you bump into them.
Might be possible to controlle in the unitdef, mincloakDistance or sensors maybe.
Decided to also put this in Spring Tanks for the lolz and it now works there like I imagined.
There are some things to watch out for though:
At first I wanted all "vegetation" features to provide cover but then I found some maps with very small cactus and whatnot.
So for my game, I will only have these bushes provide cover.
They are all named ad0_bushes_xl_number so I instead of editing all the files by hand I made a featuredef_post like:

Code: Select all

for name, fd in pairs(FeatureDefs) do	
	if (string.find(name, "ad0_bushes")) then
		if (not fd.customParams) then fd.customParams = {} end		
		fd.blocking = false
		if (not fd.customParams.provide_cover) then
			fd.customParams.provide_cover = 1
		end	
	end
end

I'll only place them in clusters, no single bushes because that looks a bit strange when they hide a big tank etc.
And all units will require the same amount of cover, otherwise imo gets too confusing. Of course you can set it up however you want.

For evo:
Did not yet test with units that can cloak by themself. Do you have cloaked units in evo?
Esp. other gadgets like "decloak on damage" might interfere but not tested. In that case might change to using SetUnitLosState instead of cloak.

[Forboding Angel]

Oh gawd *arcing ropes of JIZM*!

Dude, this is fucking win. You might be interested to see how I implemented it.:
https://code.google.com/p/evolutionrts/ ... tail?r=131


Only request I have left is that the visuals of the cells be sped up.

[Epicock]

Just spawn a stealth/cloaky field magic thing like in CA without the effect and that applies to all teams.

on each tree i mean. People spam cloaky fields in CA and it doesnt seem to lag.



oh yeah also i mean zero-k not ca.

[knorke]

Magic you say?

Placing an invisible jammer/cloaker unit (I guess that is what you mean?) would actually be more complicated and less flexible. Such jammer would cloak all units around and would not allow ie infantry to hide in high grass while a tank next to them is not hidden.
One advantage might be that the engine does the "is unit hidden" looping which might be a little faster.

But, on a 16x16 map how many jammers does it take to jam the whole map if a jammer could jam in a diameter of 100?

6000 or something, not viable.
Probally more as jammers range is circular and for seamless cover.the circles would have to overlap.

Only request I have left is that the visuals of the cells be sped up.

Well, it was not meant to be used by players at all.
With it enabled I get 10 fps which is obviously unplayable but ok for testing. For now I would just disable it.
But later I guess I could make it like in the fog of war widget. It would suffer from the same problems though, like clipping ugly on cliffs.
I think better would be to put the cover table (or maybe just the getcover function) in this cross gadget thing so other gadgets/widgets can read it. Then you could for example use it in your tooltip widget or something.
Not completly sure how it would work but so that you can do something like:
c = getcover (mouseX, mouseZ)
if c == 0 then tooltip "no cover"
if c == 1 then tooltip "light cover"
if c == 2 then tooltip "medium cover"
if c > 3 then tooltip "cant see shit in these bushes"

[Epicock]

medium cover?
light cover?


So basically you partially cloak a unit.... so it its slightly transparant.... and you can only shoot part of it... wait wut?

[Forboding Angel]

Dude, seriously... You have no idea what is going on here, so please stop posting until you know what you are talking about. Reading the whole thread should suffice.

THEN, go and download Evo (since you're a zk fan you probably are using zklobby... you can get it through that (you need at least rev 131 test)), I dunno if it's in springtanks yet (the publicly available version).

ZK's cloaking fields are completely different from this.

@knorke, no don't change it, the 5 level system is a good one. I had to learn how to use it but once I figured it out it was simple.

Well unless I'm mistaken, you're talking about taking a flat plane and draping it over 3d terrain. Tbh I don't see why it would be a problem, however there is a LOT of merit to exposing the field to other gadgets. I'm sure there are multiple possible uses for it, similar to easymetal and mex spot finder algos.

Edit: BTW knorke, you may or may not find this useful for springtanks (prolly not, but I'll post it anyway).

This is what I use in 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
                if (not fd.customparams) then 
                 fd.customparams = {}
                end
                if (not fd.customparams.provide_cover) then
         fd.customparams.provide_cover = 1
                  Spring.Echo("Feature["..name.."] is providing cover!")
                end   
        end
end

[Forboding Angel]

ok got it to pop and error, but the gadget kept on working. Error was sporadic.

I believe it was caused by my ammobox feature that is spawned when a unit dies, and is destroyed when an engineer gets near it (destroyed and turned into resource income or a drone depending on what gets near it).

Moreover, ammoboxes should be ignored by this gadget and I forgot to account for them, so the new function in featuredefs post looks like this:

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" 
	)
	and (not fd["name"] or string.lower(fd["name"]) ~= "ammobox")
	) then
		fd["blocking"] = false
		if (not fd.customparams) then 
		 fd.customparams = {}
		end
		if (not fd.customparams.provide_cover) then
         fd.customparams.provide_cover = 1
--		  Spring.Echo("Feature["..name.."] is providing cover!")
		end   
	end
end

Thanks to Car Repairer for helping me debug.

At no point did the gadget stop functioning. It simply spat those errors at times.

The only features on the map were spring trees, and the ammoboxes.

[knorke]

Thats why it said "for testing only" in the file comment.
No idea whats causing that though.
You uploaded tp_cover.lua again, did you make any changes in it?
For some reason notepad is being stupid and marking the whole file as different

I believe it was caused by my ammobox feature that is spawned when a unit dies, and is destroyed when an engineer gets near it (destroyed and turned into resource income or a drone depending on what gets near it).

possible but cant see how it would cause an error.
I tried destroying units in/outside cover, creating/destroying features during fights and all that but such error never happend. I also have something that spawns a unit on destroyed features (like your ammobox/drone gadget) but no problem with it.
If you suspect it might be the ammobox gadget then maybe try out how to reproduce the error.
Maybe it just needs more if nil checks thrown in everywhere

Unlikely to be related but what is with that:
[f=0000000] [DESYNC WARNING] path-checksum d161a951 for player 3 ([NOD]Vancer2) does not match local checksum adfe06b1
[f=0000000] [DESYNC WARNING] path-checksum d161a951 for player 2 ([1uP]CarRepairer) does not match local checksum adfe06b1

Also all the "Loaded gadget:" messages are twice?

[Forboding Angel]

yeah their map paths were screwed up for some reason (or mine possibly).

According to JK,

Code: Select all

function getcover (x,z)
	local tx, tz = tcoord (x,z)
	return cover[tx][tz] or 0
end

Needs to be clamped.

[09:32:21] <[Evo]Forboding_Angel> can someone help me with a bit of lua logic?
[09:32:26] <[Evo]Forboding_Angel> basically the deal is
[09:32:39] <[Evo]Forboding_Angel> sometimes a value is coming back as nil
[09:32:41] <[Evo]Forboding_Angel> which is fine
[09:32:59] <[Evo]Forboding_Angel> because the things that are returning nil don't matter anyway
[09:33:10] <[Evo]Forboding_Angel> however
[09:33:14] <[Evo]Forboding_Angel> function getcover (x,z)
[09:33:14] <[Evo]Forboding_Angel> local tx, tz = tcoord (x,z)
[09:33:14] <[Evo]Forboding_Angel> return cover[tx][tz] or 0
[09:33:14] <[Evo]Forboding_Angel> end
[09:33:25] <[Evo]Forboding_Angel> ^^ this function is still causing an error report
[09:33:43] <[LCC]jK> tx & tz have to be clamped
[09:33:46] <[Evo]Forboding_Angel> can I sinply add "or nil: to line 3?
[09:34:00] <[Evo]Forboding_Angel> I don't understand what clamed means
[09:34:09] <[Evo]Forboding_Angel> clamped*
[09:34:53] <[LCC]jK> clamp = min(max())
[09:35:20] <[LCC]jK> http://en.wikipedia.org/wiki/Clamping_(graphics)
[09:35:41] <[Evo]Forboding_Angel> so you're saying that essentially a minimum and maximum possible value for them needs to be set
[09:35:48] <[Evo]Forboding_Angel> am I reading that correctly?
[09:35:51] <[LCC]jK> yup
[09:36:23] <[Evo]Forboding_Angel> umm
[09:36:55] <[Evo]Forboding_Angel> any chance you would care to help me with that? I don't entirely understand how to do that and I'm guessing that this little snippet of code is not enough
[09:37:05] <[LCC]jK> there is also a faster way/better way in lua iva metatables, but don't think you would be able to implement that
[09:37:24] <[Evo]Forboding_Angel> function tcoord (x,z)
[09:37:25] <[Evo]Forboding_Angel> tx=math.floor ((x/resolution)+0.5)
[09:37:25] <[Evo]Forboding_Angel> tz=math.floor ((z/resolution)+0.5)
[09:37:25] <[Evo]Forboding_Angel> return tx,tz
[09:37:25] <[Evo]Forboding_Angel> end
[09:37:41] <[LCC]jK> no clamping in there
[09:37:43] <[Evo]Forboding_Angel> ehh nm that snip
[09:37:48] <[LCC]jK> so clamp it
[09:38:07] <[Evo]Forboding_Angel> I don't understand what is happening tho
[09:38:24] <[Evo]Forboding_Angel> is it referring to a section of the map?
[09:38:28] <[Evo]Forboding_Angel> well
[09:38:29] <[Evo]Forboding_Angel> sec
[09:38:36] <[Evo]Forboding_Angel> lemmie pastebin gadget for perspective
[09:38:48] <[LCC]jK> it splits the map into a grid and returning the indices of a square in that grid for any map coord
[09:39:01] <[Evo]Forboding_Angel> http://pastebin.com/T5RMNJcU
[09:39:03] <[Evo]Forboding_Angel> Aha
[09:39:12] <[LCC]jK> still it doesn't handle out of map coords, so you need to clamp it
[09:39:13] <[Evo]Forboding_Angel> so it IS referring to a map area
[09:39:29] <[Evo]Forboding_Angel> ohhh
[09:39:39] <[LCC]jK> hmm clamping might not always the best idea
[09:39:47] <[Evo]Forboding_Angel> I think I know why it's happening... features on the edge of the map
[09:39:58] <[Evo]Forboding_Angel> causing the reported area to be "out of bounds"
[09:40:04] <[LCC]jK> better detect out of map situations and handle them seperate
[09:40:43] <[LCC]jK> not only features, units too
[09:40:45] <[Evo]Forboding_Angel> which just put this out of my ability :-/
[09:40:47] <[Evo]Forboding_Angel> damn
[09:40:56] <[Evo]Forboding_Angel> oh well, I'll wait for knorke
[09:41:08] <[Evo]Forboding_Angel> I was hoping for a simple fix

Also, wrt:

Thats why it said "for testing only" in the file comment.

[f=0000000] Using mod Evolution RTS - test-131

[knorke]

ah yes, out of map coordinates might cause that.
will fix later.

[Forboding Angel]

Ok, good deal. In the meantime I'll try to do more testing and see if i can find anything else.

I did discover that flying aircraft would be affected by it, so in the meantime I just disabled their ability to be covered. It would be neat if aircraft could be covered only when landed, but tbh I don't have the foggiest idea how.

Actually, that's a lie, I dunno if it's possible, but I can find if the aircraft is moving or not in the script, but I dunno if I can set a customparam via script.

I'll check on that one.

[knorke]

It would be neat if aircraft could be covered only when landed

possible, just did not think about it yet.
checking height above ground is probally enough to detect if the aircraft is flying or landed.

[Forboding Angel]

Yar, I'm thinking anything above say 20 or 50 or summat could just be ignored. Of course, it sounds easy to do *rolleyes* regardless of the fact that it's prolly a giant pain in the ass.

[Forboding Angel]

Any news?

[knorke]

fixed the "out of map" error (i think) and otherwise spend rest of the time tweaking bushes

[Forboding Angel]

Pretty much the getting the error out of the way is more or less all I'm concerned with tbh. I've already set up evo to work with the way the gadget currently functions. The other stuff would be nice, but not totally necessary.

I'm wanting to get this in v1.5 asap

Problem is, until I get back home in a week I can't test shit