Re: Checking when a unit is near or in a feature.
Posted: 15 May 2011, 23:54
Oh ok, yeah that works 
Spring RTS Engine
Open Source Realtime Strategy Game Engine
https://springrts.com/phpbb/
Checking when a unit is near or in a feature.
Page 2 of 2
Re: Checking when a unit is near or in a feature.
Posted: 19 May 2011, 04:55
Have there been any recent advances?
Re: Checking when a unit is near or in a feature.
Posted: 19 May 2011, 18:52
not really, sorry. no time and inclination 
maybe beginning of next week.
maybe beginning of next week.
Re: Checking when a unit is near or in a feature.
Posted: 20 May 2011, 12:15
Haha, no worries, I'm just excited is all
Re: Checking when a unit is near or in a feature.
Posted: 23 May 2011, 18:55
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:
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.
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
endAnd 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.
Re: Checking when a unit is near or in a feature.
Posted: 24 May 2011, 03:33
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.
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.
Re: Checking when a unit is near or in a feature.
Posted: 24 May 2011, 17:58
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.
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.
Re: Checking when a unit is near or in a feature.
Posted: 24 May 2011, 18:44
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.
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"
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.
Well, it was not meant to be used by players at all.Only request I have left is that the visuals of the cells be sped up.
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"
Re: Checking when a unit is near or in a feature.
Posted: 24 May 2011, 18:58
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?
light cover?
So basically you partially cloak a unit.... so it its slightly transparant.... and you can only shoot part of it... wait wut?
Re: Checking when a unit is near or in a feature.
Posted: 24 May 2011, 22:45
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:
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
Re: Checking when a unit is near or in a feature.
Posted: 25 May 2011, 04:50
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:
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.
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
endAt 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.
Re: Checking when a unit is near or in a feature.
Posted: 25 May 2011, 18:58
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 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?
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
possible but cant see how it would cause an error.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).
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?
Re: Checking when a unit is near or in a feature.
Posted: 25 May 2011, 19:07
yeah their map paths were screwed up for some reason (or mine possibly).
According to JK,
Needs to be clamped.
According to JK,
Code: Select all
function getcover (x,z)
local tx, tz = tcoord (x,z)
return cover[tx][tz] or 0
endAlso, wrt:[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
knorke wrote:Thats why it said "for testing only" in the file comment.
infolog wrote:[f=0000000] Using mod Evolution RTS - test-131
Re: Checking when a unit is near or in a feature.
Posted: 25 May 2011, 19:18
ah yes, out of map coordinates might cause that.
will fix later.
will fix later.
Re: Checking when a unit is near or in a feature.
Posted: 25 May 2011, 19:43
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.
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.
Re: Checking when a unit is near or in a feature.
Posted: 25 May 2011, 20:07
possible, just did not think about it yet.It would be neat if aircraft could be covered only when landed
checking height above ground is probally enough to detect if the aircraft is flying or landed.
Re: Checking when a unit is near or in a feature.
Posted: 26 May 2011, 17:08
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.
Re: Checking when a unit is near or in a feature.
Posted: 30 May 2011, 22:58
Any news?
Re: Checking when a unit is near or in a feature.
Posted: 31 May 2011, 00:52
fixed the "out of map" error (i think) and otherwise spend rest of the time tweaking bushes
Re: Checking when a unit is near or in a feature.
Posted: 31 May 2011, 08:34
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
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