oops

Is there any chance at all of this ever working with a non TA mod?

Why shouldn't this work in a non-TA mod? The requests I made and that were integrated by very_bad_soldier make this widget totally customizable. Just make an entry for your mod so that the auto-detection doesn't run and put all your units (that shall have a range effect) into the unit list...

Yes, Krogoth's idea about unit list files is a great way to support any mod. Because you only have to list static defenses it should really not be too hard to write these files for any mod. And I think in general it is the better way to categorize the units. I will probably change BA and CA also to use this method and write the unit files for those mods.

Any progress on the modname detection so far?

To be frankly, I didnt get what exactly is the problem


The mod detection depends on Game.modName (and Game.modShortName as added by the CA guys). So if this tag is set it should work correctly. This is the code:



Did I miss anything?

The problem is that the detection doesn't work as it should. It scans the name=xxx and version=xxx line and nothing else. So in order to have Defense Range working you have to give the exact same terms to both...

So with that said you maybe can imagine the problems caused by that. Apart from me not knowing if you can use a name with space character in the detection script this is bad as both tags will be showed when hosting. So if you would put "Maximum Annihilation" (as I said I didn't try if it's possible to use a space character but here it's just an example) in for both tags your mod then will be callled "Maximum Annihilation Maximum Annihilation"...

Sorry, I never made a mod, and I really cant get the problem.
The widget does not know about name/version lines. It just reads the variable Game.modName/modShortName and compares the first characters to hard coded strings. AFAIK it works well with BA, CA, XTA.
Maybe you could send me your mod so I can debug which string can be found in Game.modName/modShortName in your case?

Hmmm - well as a matter of fact it doesn't work with all the mods you listed. I just replaced the widget coming with CA by your new version and it immediately stopped working spitting out the error message again and shutting down. So if you tried to copy the detection script CA uses you must have missed something...

Well, i see, I thought the whole time you want a complete new detection method. I didnt get that the actual one just isnt working anymore in that version.
I will have a look soon...

EDIT:
Try this one. It includes the missing shortname detection, I had it already merged in on my local version...

Working wonderful now!

Before finally releasing this remember to set the debugging to false...

I upped a new version with some fixes and the static unit list can be used now by mods... Maybe BA and others might want to update their included version?

A working example can also be found in Maximum Annihilation (though still using version 3.5)...

Concerning the new version 3.6 I have some problems as I cannot make it work. It deactivates at startup and when you reactivate it and build something with a range effect it crashes again. So I activated the debug mode and here you have the notes from the infolog:



So you can see that if it wants to look up the unit file (here the Arm Com and LLT) it crashes. All I did was to add a

To the widget again (and this seems to work as the log tells) and I renamed the gui_defenserange_units.lua into gui_defenserange_units.inc ...

EDIT:
BTW - didn't you forget to pack the button images into the zip?

EDIT2:
Ah - I now see why it didn't work. You replaced the per mod "useUnitFile = true" handle with a global one. Works now...

Argh Yeah, i messed it up as always...
Thanks for the info!


Ok, so all ok now? I will do a new zip then with the images included

EDIT:
About the global "useUnitFile" var. I thought it would make more sense to make it global since there can only be one unit file which again makes only sense when bundled with a mod. What do you think?

Well I haven't run a full scale test yet but while building some turrets testwise it all seemed to work...

Making the "useUnitFile" var global or not doesn't really make a difference. I found the local method a bit more intuitive as you have to make changes at those lines anyway what makes setting up the widget a tiny bit more easy. In the old version there also was an example you just had to change some letters on and it's done. The "new" method has the disadvantage that you have to figure out two positions where you have to change something and without that example it's a bit harder to get to know what actually to do and where...

No big disadvantge though so you can keep it this way now. Just make that readme.txt introduction a bit more clear. First go ahead and remove that very same introduction from the actual widget. Then go ahead and write into the readme.txt that you have to switch on the useUnitFile var at the very beginning of the file and then give a clue as to where to add those mod detection lines. Either give a line-number you can scroll down to or give a complete example so you can copy a part of this and then use the search function to jump to the right position in the file. Currently you really have no idea where to add the mod detection and reading through half the widget might not be everyones' taste...

Thanks for the tips, but in fact it is meant even easier: All you have to do if you want to include it with your mod using the static unit file is two things:
1. Create/Edit the file gui_defenseRange_units.inc to include all your units you want to draw ranges for.
2. Change the line "local useUnitFile = false" to true.

All other mod detection functions are not used if you are using the unit file. They will be totally skipped and the unit detection solely depends on the unit file then. At least it is meant this way
In other words: You dont have to change the function DetectMod anymore to include your mod. Sorry for confusion...
Bug reports are very welcome.

EDIT:
I missed one important point:
If you are using this widget as a none mod-included one you must not place the unitFile in your widget directory! I think it would overwrite the unitFile included in the mod you are playing.

Yes. Player Widgets overwrite game Widgets. I'm almost tempted to just write this as a Gadget, tbh, so that people can't screw with it, except to turn it off via a UI command.

Added one little new feature to see blast radius.

i would like to be able to push a button (like l for los) that displays how much damege per second is dealt by the units/buildings that can attack that place, it should be displayed in colors, like green = not alot purple = alot

Precision combombs FTW!