Widget Philosophy

In making of my 2 widgets, and planning of a few more, I came across... well, let's just call it an ethical issue.
I know the game engine accepts custom widgets and this is hard to control but I would like to ask if there is some sort of unspoken "do not go here" zone for widget creation.
A point beyond which widgets are not meant to go. So to speak.

Saktoth said:
"Zero-K is all about open development. If you can make a widget that plays the game better than a player, go ahead. If it breaks the game, its the game that needs fixing. "

Ok, so I know what Saktoth thinks then.

But how about this?

I am going through LuaSyncRead and looking at the functions. If some of them work the way I think they do, I can detect incoming projectiles.

With some calculation mirroring the engine's projectile movement code, I can make constructors drop a HLT in the way between them and the projectile then cancel it 1 frame later...
nanowalling widget

Or how about this.

If I ever end up being able to target empty space (currently does not work), I could make turrets/units fire back to the earliest known spot a sniper shot came from if it is within los.
Give it to snipers and...
countersnipers widget


Can you continue to support these kind of widgets?
I don't mind having a go at them, but the nano-walling widget idea seems to push the boundaries of cheesiness to me.

nanowalling widget:
if you manage to make this work, it could be prevented by making projectiles pass through nanoframes until they are 10% complete.
Though looking how cons have to turn and unfold and all that I am not sure it would even work so good for indiviual projectiles.

targeting empty space:
i think that got forbidden for this very reason. someone had already made a widget that makes the commander dgun fighter planes.

Well, currently, position of ground doesn't work.

I just thought of another reason why empty space should not work. You can make HLTs overshoot their max range that way. >.>

Most Op thing I can imgaine in BA control-fps raketeer t2(rocket bot) then shot rockets through all map. In fps you can do that, but it is not very accurate but stilll after few shots you can hit windmills :)

Ok, the point is moot on the nano-wall widget.

Spring.GetProjectilesInRectangle()
doesn't work.

when you try to use that, you get this error:
attempt to call field 'GetProjectilesInRectangle' (a nil value))

If you try to localize the widget, it's just nil. (and not a function, trying to call it as a function will generate an upvalue error)

So nope, it was too much to hope for, I can't detect projectiles.

Ahhh! Knorke found our secret forums.

Like Google Frog said, it has been long on the table to find a way to prevent nano-blocking. If you make a widget it will probably speed development on a fix. So unfortunately it would ultimately be useless.

Although I would probably go use it in BA then. :D

Well, like I said, I can't do it. Detecting projectiles doesn't work.

It kinda sucks. Nanowalling widget isn't quite as interesting as a countersniping widget. And I'm sure that one would be more useful.

Any idea where I can find Spring.GetProjectilesInRectangle() in the Spring code? Maybe I can fix it. =P

isint something like countersniping already here?

I mean before my eyes my sniper was shot which was in front of HLT.

The philosophy of widget is sharing. If you made a nano-wall widget and not share it: then it is called cheating! Please share this 'cheating' widget in public places k?

Of course, I intend to give away the widgets I write. Good thigns are meant to be shared after all.


The AA widget can be said to be using too much CPU though. And it works much better when you have a good internet connection. (if you use hold fire, your ping must be <300ms or it functions worse than not using it)

Unfortunately, I can't solve those problems. I have already tried to optimize the code, writing a two-way reference array so I don't have to check the list all the time.
Thing is, detecting if targets are in range is going to be slow no matter what I do. I also never studied computer science formally so my estimates on how well my algorithms work is not accurate.


That doesn't mean I shouldn't write it. I'll write the widget and problems can be dealt with as they arise.

What can be automated, should be.