Defense Range v6.12

[very_bad_soldier]

That is the old-styled unit file. Since 4.0 it looks a bit different, should be included in the jobjol-zip.
Now it looks like this:

Code: Select all

unitList["cordoomsday"] = { markerText = nil, weapons = { 1,1,1 } }		
unitList["armamd"] = { markerText = "AntiNook" }
unitList["armhlt"] = { markerText = "An HLT!", weapons = { 1 } }

This was done to support multiple weapons on one unit.

[REVENGE]

Ok, looks like it might be working. However, the widget crashes on the following error:

Code: Select all

Error in UnitEnteredLos(): [string "LuaUI/Widgets/gui_defenserange.lua"]:892: attempt to perform arithmetic on local 'damage' (a nil value)

[very_bad_soldier]

Do the following:
1. Go to the function "DetectMod" and enter your mod's shortname as another AND-clause to the if-statement (Line 304 in 4.11). This will prevent your mod from being treated like BA.
2. Go to the function "getModAirTag" (Line 658 in 4.11). Add another elseif-statement with your mod's name and enter the name of the armorType for air units.

This will look something like this:

Code: Select all

function getModAirTag()
	local tag = "vtol"
	if ( curModID == "XTA" ) then
		tag = "group_landair"
	elseif ( curModID == "CA" ) then
		tag = "planes"
	elseif ( curModID == "EVO) then
		tag = "evoair"
	end
	return tag		
end

3. Go to the function "getModGroundTag" (Line 668 in 4.11) and do the same. This time enter the tag for ground units.

Hm, in this moment looking at the code I am surprised that it even works Try it, but I think I have here some things to change to make it work properly.

4 would be: Go to "DetectWeapon" and have a look if this will work with your mod. If not, you have to put a if-statement in for your mod and do a custom method to detect the weapons type (Ground/Air/Both/Nuke). Do it just like CA did.

[REVENGE]

Sounds good, gonna implement this soon.

[very_bad_soldier]

I did some work on it, maybe its worth a try.

Go to line 82 and take a look how the configuration of other mods is done and adapt it to your mod.
Then proceed to the function DetectWeapon and have a look if you can use the standard detection method (line 718). If not, add another elseif-statement for your mod and implement a detection method for your mod (just like CA did).

[Hoi]

(line 718)

lawl

[REVENGE]

Alright, I only have 1 unit that I want to get working here.

Can you make an update so that I can completely define everything manually in the inc file, and force the widget to only use that inc file?

[very_bad_soldier]

Should already work this way, just set useUnitFile and unitFileOnly in line 20 to true.

btw: Hoi what is so funny about line 718? Found a hidden joke there?

[Hoi]

when you said line 718 I thought wtf, more than 718 lines.........

[[Krogoth86]]

Well it seems I always run into a wall when updating your widget. So far I've recreated the unitlist, activated the mod detection and created a clone of the BA tags for that strange armor stuff. It crashes when building something on the list though:

[ 340] Loading: LuaUI/Widgets/gui_defenserange.lua
[ 340] <DefenseRange> Using unit file instead of generic method!
[ 340] <DefenseRange> Generic Mode. ModName: Maximum Annihilation V1.2 Alpha 1 Detected Mod: MA
[ 646] false
[ 646] Error in UnitCreated(): [string "LuaUI/Widgets/gui_defenserange.lua"]:913: attempt to perform arithmetic on local 'damage' (a nil value)
[ 646] Removed widget: Defense Range v4.13

Can you give any instructions on what actually happens in those armor and weapondetect definitions and what actually gets defined there? I think the problem has to be in that part...

[very_bad_soldier]

I think your problem has something to do with the DPS calculation. The widget wants to calculate the DPS the weapon does against a certain armor type. Therefore it needs to know the name of the armor type for air and for ground units.

Did you update the armorTag variables for your mod?
armorTags["BA"] = {}
armorTags["BA"]["ground"] = "else"
armorTags["BA"]["air"] = "vtol"

If the widget detects a air-firing weapon it looks in the weapon definition damage table for how much damage the weapon does against "vtol" (in BA's case). If your damage table has no item tagged "vtol" then the widget wont be able to fetch the damage value.

If you absolutely cant get it to work you can send me the files and I will take a look.

[[Krogoth86]]

Well I now changed those armor tags but still it doesn't work. I attached the widget and the list if you want to have a look at it...

Why did you introduce that armor stuff anyway? It only makes sense if you luckily have your armors designed in a way that there pretty much is just one type of armor - it totally fails for any other game with multiple armor types...

[very_bad_soldier]

grml... I wont lose many words about this: My knowledge of internal mod structures is very limited (cause I made exactly 0 mods) but I still dont think it totally fails. If you have a better solution in mind you should think about it to the end. There are probably more pitfalls than you can imagine right now.
So I dont say the current solution is perfect, if you have a better idea which you think is a complete and generic solution, let me know about it or just hack it in.

To your problem: Your armor classes are case-sensitive, changing your definitions like this made it work (tested against MA10):

Code: Select all

armorTags["MA"]["ground"] = "tanks"
armorTags["MA"]["air"] = "vtols"

[[Krogoth86]]

To your problem: Your armor classes are case-sensitive, changing your definitions like this made it work (tested against MA10):

Indeed that did the trick. The funny thing is that I actually thought it might be case-sensitive to what I wrote in the armor.txt where I wrote it in upper case letters...

Thanks!

My knowledge of internal mod structures is very limited (cause I made exactly 0 mods) but I still dont think it totally fails.

I didn't want to sound rude about that but it's just that this extension doesn't make that much sense to me. Imo there is no real need for colors depending on the dps. I mean on the one side it's technically about impossible to do that as this measurement just uses one armor type and so even for BA it won't always be correct while for games with an extensive use of armors it's a complete waste - you might even want to turn that part off entirely in that case to just have circles for the range. The other side is that it imo isn't really needed either. I mean when you get a circle, you'll also know the unit which caused it and so you know the damage it does (especially in games like BA where stronger weapons usually are combined with longer ranges)...

I also don't know a way to do it better and I think it's not even possible: Imagine you'd have done a solution of any kind that would visualise even the dps differences of certain armor types. This would be a total information overkill and even if you would have learned how to read the rather complex info your widget would give your advantage because of that would be - well I'd say there would no advantage at all because as I said you already know about the dps you'll be confronted with if you are no noob. A noob would be totally overstrained with a strange color / symbol / whatever system for dps for each armor type and would just go WTF! ...

That's why I think that dps measurement is near to useless and makes mod developers struggle with case sensivity...

[very_bad_soldier]

I didn't want to sound rude about that but it's just that this extension doesn't make that much sense to me. Imo there is no real need for colors depending on the dps. I mean on the one side it's technically about impossible to do that as this measurement just uses one armor type and so even for BA it won't always be correct while for games with an extensive use of armors it's a complete waste - you might even want to turn that part off entirely in that case to just have circles for the range. The other side is that it imo isn't really needed either.

No problem. Ok sure, the color is not correct for all units, but its still true for most units. I think this is sufficient since you do not get absolute DPS values anyway. The colors just give rough and relative estimations for damage. They just say "I DO A LOT OF DAMAGE" or "i do only little damage", not more. So this will be even true for special armor classes unless the damage modificators are real strong.
And addionally: I really like the colors. Its a nice way to add additional information to the circles IMO.

I mean when you get a circle, you'll also know the unit which caused it and so you know the damage it does (especially in games like BA where stronger weapons usually are combined with longer ranges)...

Frankly, in heavy battles when there are lots of turrets and lots of circles I would have real problems to identify the most dangerous ones.
Using the colors you instantly know that the yellow rings are the ones you should better avoid.

But the most important part: If you drop the armor class stuff you would also lose abitlity to "detect" weapon types by DPS. All mods would have to use static unit list.
I know this is probably very arguable if it would maybe better to switch totally to unit lists since these "detection system" is highly unstable (it gets quickly broken if mod gets changed). But as you said, I dont see a real advantage in changing all the stuff at the moment but I still agree that it is far from perfect.
If there are mods who have real problems with it or if me or someone else have a great idea how to do it better I am surely open for a rewrite...

[[Krogoth86]]

No problem. Ok sure, the color is not correct for all units, but its still true for most units. I think this is sufficient since you do not get absolute DPS values anyway. The colors just give rough and relative estimations for damage. They just say "I DO A LOT OF DAMAGE" or "i do only little damage", not more. So this will be even true for special armor classes unless the damage modificators are real strong.
And addionally: I really like the colors. Its a nice way to add additional information to the circles IMO.

Well the question is of how much use that is, how easy it's to "read" and where you can apply it. Imo it has no real advantage for all these points. The main advantage of your widget is the fantastic ability to see ranges and handle your units in a more efficent way (although this of course takes away a bit of what makes the difference between a experienced player who has learned about ranges and a not so good player who has not). Having colors for dps now is no big advantage for this as you still have to look up from which buildings those circles may be spawned and so you don't really safe lots of time or provide some precious info...

At the same time this adds up to something you mentioned yourself: There are going to be lots of circles. But how should I distinguish now between circles of anti-ground and AA stuff? I can't at all and so there's little use of paying attention to the circle colors as I won't know Jack about which circles are going to affect which units. That might be changed by either using certain colors for each type (like dark red to bright red for ground stuff and dark green to light green stuff for air stuff) or using like a dotted line or something to distinguish between the types (although I think that won't be possible without lots of hacks to get at least the illusion of having a circle with an interrupted line)...

Finally there is that point about this solution being of no use for games with "real" armor types. Let's face it - most TA mods actually don't use "armors" at all but define something like that to apply extra damage to certain units. That's why this method doesn't totally fail for them although it of course even for them isn't always correct. That totally changes for something like NOTA where you actually have at least some kinds of real armor types where weapons are designed with specific weaknesses / advantages against certain types which just can't be shown in simple circles (and also shouldn't be shown as it would be visual and info overkill)...

Oh and btw a short question: Do you also mind things like burst tags for weapons? I for example wondered why especially some AA things have pretty much the same color for their circles although there is quite a dps gap (although I don't know if it's just too small in order to make a noticeable difference in color)...

[very_bad_soldier]

At the same time this adds up to something you mentioned yourself: There are going to be lots of circles. But how should I distinguish now between circles of anti-ground and AA stuff? I can't at all and so there's little use of paying attention to the circle colors as I won't know Jack about which circles are going to affect which units. That might be changed by either using certain colors for each type (like dark red to bright red for ground stuff and dark green to light green stuff for air stuff)

...hm this is already the way its done. Ground weapons cycle from red to yellow while air stuff from green to blue. I guess I didnt mention this anywhere
But you can still enable/disable certain groups if there are too many circles.

Finally there is that point about this solution being of no use for games with "real" armor types. Let's face it - most TA mods actually don't use "armors" at all but define something like that to apply extra damage to certain units. That's why this method doesn't totally fail for them although it of course even for them isn't always correct. That totally changes for something like NOTA where you actually have at least some kinds of real armor types where weapons are designed with specific weaknesses / advantages against certain types which just can't be shown in simple circles (and also shouldn't be shown as it would be visual and info overkill)...

Agreed, really different armor types will break it. The point is the grouping to ground,air and nuke. For such mods you would have to either make a more complex grouping or make a totally different approach.

Oh and btw a short question: Do you also mind things like burst tags for weapons? I for example wondered why especially some AA things have pretty much the same color for their circles although there is quite a dps gap (although I don't know if it's just too small in order to make a noticeable difference in color)...

Hm, no. Never heard of it. DPS is calculated as simple as (damage/reloadTime). But sounds interesting, maybe you could tell me more about it (or maybe just a link to more infos).

[[Krogoth86]]

Hm, no. Never heard of it. DPS is calculated as simple as (damage/reloadTime). But sounds interesting, maybe you could tell me more about it (or maybe just a link to more infos).

Well giving a weapon a burst means you want to create a weapon that fires for multiple times and then needs to reload to fire the same amount of projectiles again...

As an example have a look at BA'S DRAGON'S MAW. The flamethrower weapon will fire 12 fire projectiles per burst and then reloads to fire those 12 projectiles again...

When looking at the weapon definition you'll find a value for burst and one for burstrate. The burst value defines how many times the weapon actually fires per firing sequence. The burstrate defines how much time there is going to be between each single shot. For the Dragon's Maw that's a very tiny value of 0.01 as it's supposed to look like a stream of fire (which you now know consist of several single fire "projectiles"). You'll also see that modinfo does calculate the right dps value of 428.57...

You can get that result for yourself:
25 ( default damage per projectile) * 12 (number of projectiles per burst) / 0.7 (reload time)
= 25 * 12 / 0.7
= 428,57

[Evil4Zerggin]

There's a few caveats: A burst weapon's maximum fire rate is one shot per frame. Therefore, a burstrate of 0.03 and 0.01 are exactly the same in practice. Furthermore, a new burst cannot start until the old burst has finished. So if your weapon has a reloadTime of 0.1s, a burstrate of 0.03, and a burst of 10, it will end up firing only a single shot each frame (although I believe the first shot of a burst can be fired on the same frame as the last shot of the previous burst, so you will get nine frames of one shot each, a frame with two shots, eight frames of one shot each, a frame with two shots, eight frames of one shot each, and so on).

There's also the projectiles tag, which spawns multiple projectiles per shots. So if you have burst 10 and projectiles 3, that's 30 projectiles per "pull of the trigger".

Finally there's also scripted reload delays, but you have no way of seeing those, so that's not really a concern.

[very_bad_soldier]

Great explanations, big thanks for it! It will surely find its way into the next version