Multiwidget in LUA for units management

[Ionic]

Multipurpose widget in Spring/LUA written by me (aka subionic) to teach players scriptwriting in spring. Tested with spring v0.91 and few following versions. Installation: copy to lua/widget directory.

[knorke]

It looks like there is some interessting code inside...in these 4600 lines?!
It might be more clearly as several widgets? I looked at it and I am sure there is some cool stuff but it was just too much...Think widgets with too many functions quickly get choatic, especially if there is so much different things happening in the callin functions.

[smoth]

What am I looking at? There is next to no commenting. If you expect people to learn from it, you have to add comments explaining what each piece is for. Also when you have code this long, somewhere along the way, you went terribly wrong. You need to break different functional pieces out into their own files so the file is readable. Doing too much in 1 BIG piece wall of code is a recipe for a disaster, and makes the code next to unreadable.

[jamerlan]

I was trolled by this widget. People said that it's awesome! and it helps to play a lot!

But it is not :-D It fucked my game start totally

[Ionic]

This widget was primarily developed for me to help me in battles when I was AFK for a moment. However I want to share it because I think that its content may be for some script's developers interesting. The code is definitely NOT for beginners or Sunday players. It touches many things present in Spring API (therefore it may be interesting for coders). Shorts list of features:
- legion mode - units attack are in rectangle formations with defined width and depth
- carpet bombing - bombers bombs square region in formation as above.
- fighters auto attach - 3 fighters in special zone attack 1 bomber if it appear on radar.
- crawling bomb auto guidance - it finds nearest enemy and crawls to it
- autoatack - for given vector units will attack enemy with the best weapon available and retreat if damaged to safe zone
- metal collection and repair - builders and rez units will reclaim metal and repair unit in specifier places where recently some battles occurred.
- snipers auto cloaking
It has some very primitive path finding algorithm and own low resolution maps of resources/friends/enemies updated on the base of events.
No documentation is planned.

[Jools]

No documentation is planned.

I like that attitude!

[gajop]

The code is definitely NOT for beginners or Sunday players. It touches many things present in Spring API (therefore it may be interesting for coders).

You do realize people complaining about its readability are pretty much _the_ experts when it comes to Spring's Lua? :)
Not complaining, any contribution is welcomed, but you may want to improve the code, for your sake as well.

[PicassoCT]

No documentation is planned.

Documentation never is planned. It grows like a fungi, and you -the dev only take notice of it , when the deadly spores of unknowledging noobs and there playin-goons knock at your door, yelling at you for updating, because you break there worripple wacks.

[Ionic]

Oh, guys – the expert is man that reads just the code and does not need docs
Particularly, that it is only Lua instead of magic on pointers and references in C++

I would like to point you to the fact that I have forwarded code that was developed by me in 2011. I do not have free time now and in foreseeable future to write doc. Excuse me possible inconveniences :)

[Silentwings]

Oh, guys – the expert is man that reads just the code and does not need docs.

Bollocks. You have written 4678 lines of code in a single text file, supposedly performing many different and disconnected functions, with barely any indication of what it was meant to do. It's good that you did something - but there is absolutely no chance that anyone will read it.

[smoth]

Oh, guys – the expert is man that reads just the code and does not need docs

Intelligent users read the manual. You are putting out code.. some basic documentation would not have hurt it. I am not sure an "expert" would spend his time efficiently, and not spend hours reading code with an unknown purpose because doing so would result in years of wasted life if said expert spent his time reading all code people plonk out there.

Particularly, that it is only Lua instead of magic on pointers and references in C++

IRRELEPHANT!

I would like to point you to the fact that I have forwarded code that was developed by me in 2011. I do not have free time now and in foreseeable future to write doc. Excuse me possible inconveniences :)

Fair enough. This is a legitimate reason, you have been hacking away at this thing for years and never saw fit to document it as the code was clear to you. I can see this as a legitimate explanation saving all the bullshit. The code is presented AS IS and that is fine and fair! Thanks for the code!

[Ionic]

I disagree with the presumption that the source code is not readable as it is. It is indeed a bit of work but actually high level languages have been developed to be readable as natural language (and to replace machine language). If the code is not obfuscated then with selfexplanable names for methods and variables it is quite well readable (at least for me).
Funny, but some patent guys often allege that the code is not readable for professionals to exclude it from prior arts :)

[smoth]

There is no presumption the file does too many things at one time

When we say unreadable we mean it 4kloc... That is bad enough in one file but then there is the fact that all his vars and functions are mixed. Without proper documentation such code results in the reader spending way more time doing dective work than he should!

Sure we can READ the code anyone doing machine code can read it if they have written those instruction sets long enough!

It isn't about anyone excluding it it is about it being a mess. Of course given your attitude that undocumented code that does several thins at one time is ok clearly illustrates that you would generate such a file. As a professional you want the code to be well documented and clean so that the client doesn't have to spend hours interpreting what your code is for!

[MetalSucker]

Let me get this straight ...

This allows such things as to auto support units close to the center of the map with a formation of air units that is as wide as a percentage of the size of the map while ignoring certain types of units, and moving in a spiral....

while automatically separating units that can/should/should not patrol from the current group from the rest ...

... all this while a dgun calculates metal/energy costs for optimal attack (didn't follow the math here on the 1st pass, sorry)

... and redefining the way units should retreat so they get hit less based on where the last attacks came from ...


but ...
Does it also need a human player or can it play on its own?

I actually find it educational.

[Ionic]

Approximately, it does things as you wrote but beside that it can do much more:
- you can set retreat point, gather point and attack vector to manage units on battlefield
- manages retreat of damaged units to retreat point
- crawling bombs find enemies on their own
- you can form squared formations from land and air units and direct them to attack place from given direction
- it handles com dgun attack on the base of “enemy metal density”
- it collects metal and resurrect units in different modes on battlefield (from hot spots and neighborhood)
- you can choose if the unit would be automated or handled manually by setting repeat flag to off/on (and setting maneuver flag to roaming and fire flag to auto attack)
- automatically redirects bombers and ground unit to given by attack vector battlefield
- supports fighters screen (by setting maneuver flag to middle state)
- handles EMP to attack only non-frozen units

At the end of the script there is a procedure that handles script functions. The are keycodes required to know to use the widget.
The widget is event driven to reduce overhead. But square patrolling is required because it triggers cyclic events – without it widget loses direct control on unit until some event would happen.

Thread moved to: http://springrts.com/phpbb/viewtopic.php?f=23&t=31997
There are also new versions of widget. Sorry, for this inconvenience made by my mistake.