bug: if i only select to see enemy antinukes(default), rings dont show. When i select allys + enemys, both rings show.

Thanks for reporting. I just tried it but I was not able to reproduce. Which mod was it and was it version 3.1 of the widget?

its ba 5.8 and 3.1 but just rememberd i saw this when watching rep. So ingame might work correctly.

EDIT: i confirm this is working ok and i use this widget every game.

This widget is broken in the SVN version of Spring, I tested with 4933.

harsh :<

will this be fixed by the next update? Also any word on this working on xta ? I tryed it out and time to time i see things not working properly :< Which is a shame as this could be a VERY good tool for our community !

Please keep up the work,
Giz

Thanks to you for input and bug report.
I tried to fix it for svn version, it should work now. And the best is: Even XTA seems to work with svn version I dont know why, it seems something has been fixed. I adjusted the damage threshold for XTA and it is worth a test now

BTW, Look at the first page of this thread for changelog...

Thats good to know, that will come packed with xta v9.2 disabled by default of course. It will still be there though for those who like those features.

Thanks for the fix

Nice one

Hi!

After rewriting the Armor.txt for my mod this widget doesn't work for me anymore. When a turret gets built it shuts down and says:


I just found out that it miracly works for some single things like the Annihilator or Pitbull. So what do I have to take care of / change on the predefined presets?

I suppose it's hardcoded to expect certain armor names.

Well in that case I'd really like to have a config file where you put in the unitname of each unit for the specific categories and maybe also write down their range so there won't be such issues with automatically detecting the right classes and settings...

If you could upload that widget somewhere I will take a look at it. Since I totally relied on UF, I dont have a clean version of it at the moment
(Maybe you even have that LuaPack that I made too?)

EDIT:
I looked at the version included in CA, I think its quite hard to make this truly generic (I dont even know if it is possible at all). The best will be to add your mod to the supported mod list and do even more hard coded stuff :D

I attached the widget I use to this posting. It should be a "clean" version i.e. it doesn't have those modifications that CA has...

Edit:
Well as the error report says it seems to crash on this line:


And when looking at that code in general - it really isn't possible to replace that class sorting by looking at dps and at-air-capabilities by something prewritten where you just put in the unitnames? I mean you pretty much have everything you need in there but instead of those "complex" measurings you do you'd just give him a list of how to sort each unit. This also would make some things easier as with a complete third tech level you might get problems with that dps measuring (or it would result in a lot of work to readjust all the damage groups and values just to have that auto-algorithm recognize your units the right way). So if you can think of a way to make me just type in the unitnames into to the specific category that would be awesome (and also makes this widget much more usable for other mods)...

Thanks for uploading, nice to have it back :)

Your idea isnt bad at all and I already thought about something like this but who would want to create such a unit list for the normal TA mods with its hundreds of units? So it would probably be best if you could use both methods. So mod designers should have the choice to make such a list and give it to the widget which can use the list to determine unit type (ground/air/nuke).

Yeah, I am getting some ideas in this moment. The widget could choose which method to use depending on the mod name. All supported mods so far would use the standard method while you could add your "mod-tag" in the supported mod list along with a filename. So the widget would load your unit list when it detects your mod and use a list-based method to determine unit type instead of the actual method.

Problem is I am short on time at the moment. But I will put it on my todo list and try to implement that.

Well on the one side if you went ahead and do another Armor.txt you'll also take the effort to do this for this widget...

Besides you don't need such a list of all the units as this is only about the static defenses and that are only few in comparison. That way and with taking BA for example, the Arm T1 entries would look like this:

So you see it wouldn't be THAT much work...

And well if it isn't too much work it would be really cool if you could have some influence on that markers for nukes and so on. So when writing that list you kinda make your own "category" and the categorie's name then gets printed on the marker. That way you would get a very flexible system for non-TA mods and mods which don't have nukes only as superweapon...

But that really just would be the cherry on the cake...

Ok, i tried to hack it in. You can test it if you want. All you have to do is to go to the DetectMod-function and insert a case for your mod. I made an example for your mod assuming you will call it "KROGTA" :D

Then fill the file "gui_defenseRange_units.lua".

I hope I did include enough comments to get it fillled correctly. It was quite a quick hack so please tell me if bugs occur (I am sure they will) or if you need help to get your mod supported.

EDIT:
Damn, you may want to set the line "local debug = true" to false to not see all the debug messages.

BTW, why Juno was removed from the "nuke list"? Doesn't it belongs there, along with the emp missile? Also maybe you could add the Deflector Shield to the "anti-nuke list" (even if it's easy to see when on).

AWESOME!

I just tried it for some T1 turrets (plus a custom marker tag) and it works like a charm. Now I just have to figure out which line gets read for the mod detection as it didn't work at first try and so I changed all the modinfo entries to my mod-shortname...

Thanks a lot!

EDIT:
Well it seems that the modname detection is a bit unfortunate as I had to give the same name to the "name" and "version" tag to make it work. Would be nice if it would read the shortname tag (-> reference )...

Nice to hear that

I will try to take over the mod detection from the CA-version. I think they fixed something for the new mod shortnames.