Spring RTS Engine

Posted: **12 Jul 2009, 12:24**

To clarify...

It gets called for all of them, unless one returns true, at which point it stops calling it for other widgets.

... this is true only for some *get callins (KeyPress, AllowCommand, etc), but not those that signify gamestate changes.

Code: Select all

function widgetHandler:UnitDestroyed(unitID, unitDefID, unitTeam)
  for _,w in ipairs(self.UnitDestroyedList) do
    w:UnitDestroyed(unitID, unitDefID, unitTeam)
  end
  return
end

Code: Select all

function gadgetHandler:UnitDestroyed(unitID, unitDefID, unitTeam, attackerID, attackerDefID, attackerTeam)
  for _,g in ipairs(self.UnitDestroyedList) do
    g:UnitDestroyed(unitID, unitDefID, unitTeam, attackerID, attackerDefID, attackerTeam)
  end
  return
end

Posted: **12 Jul 2009, 14:14**

Kloot's right of course.

And here's an example of where it would stop calling it for widgets after one handles:

Code: Select all

function widgetHandler:CommandNotify(id, params, options)
  for _,w in ipairs(self.CommandNotifyList) do
    if (w:CommandNotify(id, params, options)) then
      return true
    end
  end
  return false
end

Posted: **12 Jul 2009, 22:50**

SkyStar wrote:I fixed it by changing its idle check time to suit whatever ping you have at the time by... However if you change the way job assignments are tracked, I think it would be a more optimized fix than these little lines.

Well, I don't know about "optimized" as these few lines fix the problem, whereas re-writing the job tracker is going to require changing big sections of code. If I do the new job tracker right, it won't matter what the ping is, but I haven't even started on that yet.

I've uploaded v0.8 which implements your fix plus a couple other small changes. If this keeps up, I'm going to have to start using smaller version number increments.

Posted: **14 Jul 2009, 22:44**

Central Build AI v0.9:

1) Converted unit list to keyed array (vs indexed).
2) Converted build queue to keyed array.
3) Remove items from build queue only after construction begins, not when assigned.
4) Added internal tracking of job assignments rather than scanning unit's command queue.
5) 3 and 4 should prevent problems in multiplayer games caused by high pings, but I kept the ping code just in case.

Hopefully, this will be the last of the changes for a while. I think I've pretty much duplicated the behavior of the old Central Build Group AI, so I'm ready for a little break.

Possible future improvements to CBAI:

a) Rudimentary pathfinding to keep CBAI from assigning jobs to builders who can't possibly reach the job site.
b) Have builders repair damaged coworkers.
c) Combat units added to group will guard/defend coworkers or job sites.
d) CBAI favors economy jobs when player is low on resources.
e) Inexact placement - if the exact specified build location is blocked or unreachable, shift build location slightly so build is possible.
f) Add "Central Build On/Off" buttons to builders' control panels.
h) Add custom group or ability for player to designate which unit group for CBAI to use.
i) Multiple CBAI-controlled groups with independent build queues.
j) Properly handle Dragon Teeth and similar fortifications. Currently, CBAI tends to reclaim/rebuild them repeatedly. I think they're being detected as reclaimable features. The original Group AI had the same problem.

Other possible considerations:

I) Use CBAI code as start of replacement for Economy Group AI.
II) Use CBAI code as start of AI skirmish opponent.

Posted: **15 Jul 2009, 19:36**

suggestion name it just central_build_Ai.lua and what line do i have to change to change the group-number (e.g. from 1 to 9)

edited for ai-master hoijui

Posted: **15 Jul 2009, 21:46**

you cant use group 0, that is the NULL group (i think)

Posted: **16 Jul 2009, 04:05**

manolo_ wrote:suggestion name it just central_build_Ai.lua and what line do i have to change to change the group-number (e.g. from 1 to 9)

The file name and the internal name returned by widget:GetInfo() should remain constant so that later versions can be dropped into the widgets folder and replace the older ones transparently. The reasons I keep changing them are 1) I keep losing track of which version I'm working on at any given time, 2) I sometimes like to keep two or three versions handy so I can swap them back and forth in the same game and compare behaviors, and 3) I've read the threads about Custom Formations 2 and Improved Metal Controller where people are having trouble keeping track of which version is the latest one.

I know it's annoying to have to pull up the widget manager, disable the old one, and enable the new one every time. But on the bright side, development should slow down now that I've got it doing mostly what I wanted, and you don't have to shuffle versions nearly as much as I do.

To change the group number, look down around line 33 or so for something that looks like this:

Code: Select all

local myGroupId = 1  --  Group number to be controlled by Central Build AI.

I have considered putting in a metakey combination or "/luaui cbgroup 5" text command sort of thing, but I figure those won't be any easier to remember than changing the code, and I figure the average user will change this setting exactly once to whatever group they usually use for builders and leave it there. I might create my own custom group using the Q/ctrl-Q commands that the old Group AI used to use.

With all due respect to ai-masterful hoijui, I have put units in group 0 before without difficulty. Also, gunblob's UnitGroups v5.1 displays icons so you can easily select groups and includes a group 0. I suspect hoijui is thinking of something else.

Posted: **16 Jul 2009, 08:59**

Okay, so I lied. The Central Build AI widget is now up to version 1.0. Now I'm finished playing with it for a while.

Changes? First of all, I fixed a little glitch where Central Builders who had been given orders outside the common queue would get those orders canceled before they could finish them.

Secondly, I thought it over and decided to leave the version number out of the file name so people could just copy it over the old version. Whoever put this widget into the widget manager had already done so (and thanks!). I'm still leaving the version number in the name as reported by GetInfo(), so you'll probably still have to hit F11 and enable it again. At least, I always have to every time I change that.

Thirdly, you now have the option of using a custom group for Central Build or one of Spring's regular unit groups. To use Spring's regular unit groups, change line 33 "local myGroupId = -1" to whatever group number you want to use.

The custom group (which is the default) uses the letter Q instead of a group number. Just press Q when you would otherwise press a number. Q to select all units in the group. Q twice to center the group. Ctrl-Q to add units to the group. Shift-Q to add the group to units already selected. If there are any other unit group-related functions I need to duplicate, let me know.

This is as close as I can get to combining what I remember of the old Group AI controls with the regular unit group controls. I hope nothing else uses Q for anything important. I think Q/ctrl-Q were only used by the old Group AIs.

Now I am seriously going to try to put this aside for a while and work on something else.

Posted: **20 Jul 2009, 14:09**

hoijui wrote:really??
what is the logic behind this?
as there is no logical widget order, there can not really be a logic behind this, right?

There is a logical widget order, they are ordered on layer, filename (layer one of the things being returned by widget:GetInfo()).

Of course with things like widgets made by a lot of people I can imagine it being hard to enforce your widget to be called after all other widgets. (only one can use math.huge as layer and zzzzzzzz.lua as filename after all

)

Posted: **20 Jul 2009, 23:39**

To whoever is uploading this widget to widget trackers, download managers, etc:

1) Thank you very much!
2) Please check the first post in this thread for updated description and instructions.
3) Thank you very much!

New for v1.1:

1) CBAI should now handle Dragon's Teeth and other fortifications properly instead of reclaiming/rebuilding them over and over. (thanks to mongus)

2) Edit line 33 to change which unit group (0-9, or -1 for custom internal group) you want CBAI to control. If you use a custom group, edit line 35 to change which key you want to use to select it (default is "Q").

Posted: **21 Jul 2009, 04:26**

nice, dl'd it and am still trying to really use it, seems to be working out nicely, thankyou for this!

Posted: **21 Jul 2009, 08:32**

troycheek wrote:To whoever is uploading this widget to widget trackers, download managers, etc:

no problem, you could ask very_bad_soldier to create an account on the springdownloader for you, so you could update/upload your widgets yourself (if you want to make more widgets in the future)

Posted: **22 Jul 2009, 04:29**

Tobi wrote:
hoijui wrote:really??
what is the logic behind this?
as there is no logical widget order, there can not really be a logic behind this, right?
There is a logical widget order, they are ordered on layer, filename (layer one of the things being returned by widget:GetInfo()).

Of course with things like widgets made by a lot of people I can imagine it being hard to enforce your widget to be called after all other widgets. (only one can use math.huge as layer and zzzzzzzz.lua as filename after all )

Is there a logical gadget order, and if so, what is it?

Posted: **22 Jul 2009, 04:53**

seems you missed a very important thing:
the returned value of those callins has a meaning, the widget/gadgetHandler stops any further processing, because the engine stops further processing too if the result of the lua call is e.g. true, e.g. in the case of CommandNotify it means "delete the command and don't send it to the host" (it is an unsynced callin!).
So if you just want _real_ commands (those which are already went through the server) you want to use the UnitCommand callin.

Posted: **22 Jul 2009, 09:15**

eyu100 wrote:
Tobi wrote:
hoijui wrote:really??
what is the logic behind this?
as there is no logical widget order, there can not really be a logic behind this, right?
There is a logical widget order, they are ordered on layer, filename (layer one of the things being returned by widget:GetInfo()).

Of course with things like widgets made by a lot of people I can imagine it being hard to enforce your widget to be called after all other widgets. (only one can use math.huge as layer and zzzzzzzz.lua as filename after all )
Is there a logical gadget order, and if so, what is it?

Same thing. Just replace widget with gadget in what I said.

Posted: **22 Jul 2009, 16:52**

Tobi wrote:
eyu100 wrote:
Tobi wrote: There is a logical widget order, they are ordered on layer, filename (layer one of the things being returned by widget:GetInfo()).

Of course with things like widgets made by a lot of people I can imagine it being hard to enforce your widget to be called after all other widgets. (only one can use math.huge as layer and zzzzzzzz.lua as filename after all )
Is there a logical gadget order, and if so, what is it?
Same thing. Just replace widget with gadget in what I said.

Then couldn't there be a problem with gadgets in the filesystem stealing callins from mod gadgets?

Posted: **23 Jul 2009, 01:45**

eyu100 wrote:Then couldn't there be a problem with gadgets in the filesystem stealing callins from mod gadgets?

jK wrote:seems you missed a very important thing:
the returned value of those callins has a meaning, the widget/gadgetHandler stops any further processing, because the engine stops further processing too if the result of the lua call is e.g. true, e.g. in the case of CommandNotify it means "delete the command and don't send it to the host" (it is an unsynced callin!).
So if you just want _real_ commands (those which are already went through the server) you want to use the UnitCommand callin.

THEY AREN'T STEALING ANYTHING

Posted: **28 Mar 2010, 18:14**

I've struggled with inability to remove the queued projects in any other way than re-clicking them all, losing quite a lot of cons to that, so at last decided to get down to code and fix that oversight.

This version adds two UI commands: cbai_clean and cbai_flush.
First one invokes reclaim cursor and lets you drag an area to remove all projects in. Second one just drops all queued projects, also stopping the cons working on them, if any.
These should be seen in the order menu, but the best part is that they can be bound to a key, of course.

Note that the commands are added to widgetHandler.customCommands, which weren't processed correctly in RedUI bundled with BA 7.11.
Solution is to either use another UI or fix the customCommands processing in the Red one. I liked Red, so I chose the latter, here's the fix, if it's still needed: http://springrts.com/phpbb/viewtopic.ph ... 70#p411870

Posted: **27 Jan 2011, 15:16**

Does anybody works on it in this days?

Posted: **28 Jan 2011, 03:47**

Sorry, but I haven't been keeping this updated. I haven't played a real game with Spring in ages. I've just had too many other things taking up my time. I released it as public domain or GPL, I forget which, so whoever wants to take my work and improve upon it is welcome.

Spring RTS Engine

Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Central Build AI v0.9

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Central Build AI v1.1

Re: Central Build AI as lua widget!

Re: Central Build AI v1.1

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!

Re: Central Build AI as lua widget!