widget area select?

[aeonios]

I'm currently working on a rewrite/fork of the old central-build-AI widget, and one of the features that I want to add is an area-select tool for bulk removing jobs. Getting the proper key press events is trivial, but I have no idea how to present the user with an area select (preferably circle), get the params from the select, or abort if the user cancels.

Are there any API functions that can do this, and if so how do they work?

[Silentwings]

There is an interface for adding custom commands to the GUI, which can then be caught and implemented in lua; I guess this is what you are looking for. But it's not that well documented - find a working example of one and get what you can out of that. http://imolarpg.dyndns.org/trac/balates ... e_move.lua is a bit complicated (+ its a gadget but I think all that you need is also accessible to widgets) but is the best starting point I can think of atm.

[aeonios]

Hmm, I think I see how that works. That would make this really, really easy as long as unsynced code can actually add new commands to units.

[Silentwings]

Now that I think of it, I've never tried to do it via a widget, I guess you'll find out...

[jamerlan]

I am not sure that I understand both of you :-D But I want to!

>>Getting the proper key press events is trivial, but I have no idea how to present the user with an area select (preferably circle), get the params from the select, or abort if the user cancels.

take a look at this: viewtopic.php?f=23&t=19476

there was a widget with custom selection area. Probably you can find it and understand how to do circle selections?

[jamerlan]

I found (probably old and outdated version) this widget here: https://github.com/pakolainen/Player_wi ... select.lua

[aeonios]

Well, I double checked and Spring.InsertUnitCmdDesc() is synced only, which makes sense. Adding a command to a unit could potentially change gameplay significantly.

I am not sure that I understand both of you :-D But I want to!

>>Getting the proper key press events is trivial, but I have no idea how to present the user with an area select (preferably circle), get the params from the select, or abort if the user cancels.

take a look at this: viewtopic.php?f=23&t=19476

there was a widget with custom selection area. Probably you can find it and understand how to do circle selections?

I found (probably old and outdated version) this widget here: https://github.com/pakolainen/Player_wi ... select.lua

Ouch. Technically that should work, but it would require converting all the jobs in the queue into screen space, and only gives a screen-space selection and not a world-space selection. That'd be pretty complicated and also less than ideal.

EDIT: I thought up a hacky way to do this. I could just piggy-back on the reclaim (or other area select) command, by adding an extra options.key modifier to it that isn't used already, eg control or alt.

[Jools]

It can be done by widget only. Refer to zk/xta area guard commands.

[Silentwings]

piggy-back on the reclaim (or other area select) command, by adding an extra options.key modifier

This is generally a bad idea, because games might already have implemented variations of the true commands through modifiers (idk if any do), or might even block the true command from occurring in some/all situations, in which case your widget would never see it happen.

It looks like what you want to do can only be "cleanly" implemented in a gadget, and that to do this with a widget you'll have to write your own UI for it, in which case what jamerlan suggested might be handy.

[aeonios]

Meh, that solution is really low quality, would be inconsistent with the rest of the interface, and would clutter up the code that I've struggled so hard to keep maintainable. The original was ~1300 LOC, and it's sitting at ~900 LOC right now after I heavily cleaned and rewrote major parts of it. It does a lot of AI-like things, has a bunch of added features over the original and is so complicated and obscure in general that hardly anyone else would even touch it.

I haven't implemented that yet, but I'll probably look into ZK's area-mex gadget to see if I can't find anything usable. I suspect that it uses a synced custom command like that other widget did though. Assuming that someone wants to port it to another game, which is fine, then they'll have to come up with a solution that works for that game. I'll at least leave notes about that.

The other solution would be to make a feature request for an unsynced API for producing 'virtual commands' to get selections from the user.

EDIT: Well I decided to look through other unsynced widgets to see if I couldn't find anything related. What I did find was a glDrawGroundCircle function that's fairly close to what I'm looking for. It would probably be easier just to translate the mouse coords into world-space coords and then use the distance between the start and current mouse pos to get the radius for the ground circle. The loop-selection widget was intended for selecting units in screen space, which is probably why they did it the other way around. The area command hack is at least useful for testing out the functionality though.

[Silentwings]

You could talk to the devs of whichever game you are wanting this in, and offer to write a gadget. Otherwise, I guess gl.DrawGroundCircle is a good solution in LuaUI, it just won't fully match the look of the other commands.

[aeonios]

The only problem I've had with that so far is that it doesn't allow me to change the cursor to show the user that the selection is active. None of the eco-related effects in zk are particularly complicated, and could easily be reproduced in unsynced code. The distinctiveness of the ground circle appearance helps to differentiate it from other commands though, which I see as being a good thing. I managed to implement fully correct shift behavior as well, so that it functions like any other command.

[troycheek]

I'm currently working on a rewrite/fork of the old central-build-AI widget, and one of the features that I want to add is an area-select tool for bulk removing jobs.

Old? (checks forums) I guess 2009 is pretty old now. It seems like just yesterday.

Central Build AI was my first and only major Lua project, and I was mostly learning as I went. Cancelling jobs is something I always meant to improve. I also meant to add some basic pathfinding to make sure that a builder added to a job could actually reach the job site. I also intended for the widget to note when builders were damaged and assign other builders in the group to repair, if you're taking feature requests. Oh, and adding combat units to the group who would be dispatched to back up builders that were damaged.

Good luck with your rewrite. If you need any insight on what the original code was supposed to be doing, just let me know.

[aeonios]

Old? (checks forums) I guess 2009 is pretty old now. It seems like just yesterday. Central Build AI was my first and only major Lua project, and I was mostly learning as I went.

Wow, I never expected to see you around here. This was the first project I'd ever done in lua also, and for that matter the first piece of software that I've ever written that actually does useful things. Luckily lua isn't that hard to pick up, and the code was commented well enough for me to follow what it did more or less.

Cancelling jobs is something I always meant to improve. I also meant to add some basic pathfinding to make sure that a builder added to a job could actually reach the job site.

Luckily someone before me added code for path checking. After cleaning it up and adapting it to the new assignment loop it seems to be working fine, too. I ended up removing auto-remove for jobs in enemy territory and related stuff, since that always worked really badly and I couldn't find a real solution to that that wouldn't cause other, possibly worse problems. That was one reason I ended up making an area select.

I also intended for the widget to note when builders were damaged and assign other builders in the group to repair, if you're taking feature requests. Oh, and adding combat units to the group who would be dispatched to back up builders that were damaged.

Auto-repair-damaged-workers is kind of problematic, since that can cause them to abandon their build jobs which may include porc for killing off the offending enemy units. At one point ZK was doing this automatically and caused me all kinds of headaches. I could possibly even add auto-repair for all damaged units but at the very least I would have to reduce the priority of repair jobs, and it might still cause workers to suicide into expansions that are lost causes should they not have any other work to do. That's something to test I guess.

Auto-calling combat units is something that a proper AI would do. I do intend to work on an AI as well, but I'm not trying to do everything for the player.

Good luck with your rewrite. If you need any insight on what the original code was supposed to be doing, just let me know.

Thanks! I think I got everything figured out well enough, although it certainly wasn't easy.