0002873: Change in Factory Behaviour wrt AllowUnitCreation

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0002873

Spring engine

General

public

2011-12-26 14:34

2012-01-09 23:28

Reporter

FLOZi

Assigned To

abma

Priority

normal

Severity

minor

Reproducibility

always

Status

resolved

Resolution

fixed

Product Version

85.0

Target Version

Fixed in Version

Summary

0002873: Change in Factory Behaviour wrt AllowUnitCreation

Description

[13:09:49] <[S44]FLOZi> well i can try and describe it
[13:09:59] <[S44]FLOZi> see, i found it because of CRAIG ai
[13:10:29] <[S44]FLOZi> it has a unit limit, implemented through AllowUnitCreation
[13:11:07] <[S44]FLOZi> now it used to be that when it returned false from AllowUnitCreation (unit limit is reached) the factory would skip that build order and move onto the next (the factory simply sets a few build orders and repeat on)
[13:11:14] <[S44]FLOZi> but now it no longer skips ahead
[13:11:40] <[S44]FLOZi> which totally breaks CRAIG AI, as the factories stop building anything as they can't build the limited units and don't move on

[13:13:01] <[ARP]hoijui_g5> kind of.. the engine asumes, if you dont want to build current unit in queue, you aslo dont want to build all following ones (in the queue)?
[13:13:13] <[S44]FLOZi> not necessarily
[13:13:25] <[S44]FLOZi> but if it got a unit it couldn't build, it would move onto next buildorder
[13:13:30] <[S44]FLOZi> now that might be for the same, limited unit
[13:13:35] <[S44]FLOZi> but it would keep skipping
[13:14:08] <[S44]FLOZi> until it reached something that it was allowed to create
[13:14:22] <[ARP]hoijui_g5> ok..
[13:14:37] <[ARP]hoijui_g5> so what happens now exactly, when you return false for the first time?
[13:14:49] <[ARP]hoijui_g5> no longer skips ahead...
[13:15:09] <[S44]FLOZi> correct, the factory just sits there with the buildorder which it is not allowed to create
[13:15:17] <[ARP]hoijui_g5> does that mean it build nothing of what folows, or build all of it? (creates)
[13:15:23] <[ARP]hoijui_g5> ah
[13:15:26] <[S44]FLOZi> builds nothing
[13:15:41] <[S44]FLOZi> if you cheat and remove the order for the limited unit, the factory springs back to life
[13:15:50] <[ARP]hoijui_g5> so it does not build, but also does not cancel the build propperly?
[13:16:00] <[S44]FLOZi> mm, but it never used to cancel exactly
[13:16:07] <[S44]FLOZi> because the order was still in the build queue
[13:16:12] <[ARP]hoijui_g5> ok
[13:16:27] <[S44]FLOZi> (so if those units died it would build them next time around in the repeat queue)
[13:16:37] <[S44]FLOZi> it just moved onto the next order
[13:16:54] <[ARP]hoijui_g5> mm
[13:16:55] <[S44]FLOZi> mm ideally i would dicuss this with Tobi, he wrote the AI :D
[13:17:12] <[ARP]hoijui_g5> so it canceld the build, but added the unit at the end of the queue again?
[13:17:25] <[ARP]hoijui_g5> mmm yeah.. i am not optimal for this for sure :D
[13:17:29] <[ARP]hoijui_g5> know nothing about all this

[13:18:19] <[LCC]KingRaptor[0K]> in simple terms: if a builder tries to build something, and AllowUnitCreation blocks it, in previous versions it would stop trying to build it
[13:18:26] <[LCC]KingRaptor[0K]> now it keeps trying to make that thing

[13:18:30] <[S44]FLOZi> yes
[13:18:40] <[S44]FLOZi> but it didn't remove from queue or anything, at least with repeat on
[13:18:49] <[S44]FLOZi> it just moved to next item
[13:21:28] <[ARP]hoijui_g5> ahh ok
[13:21:35] <[ARP]hoijui_g5> thanks :-)
[13:21:49] <[ARP]hoijui_g5> and this was not in 84.0 yet. for sure?
[13:22:43] <[S44]FLOZi> that's another problem - not sure when it broke
[13:22:55] <[S44]FLOZi> CRAIG doesn't get tested that thoroughly that often
[13:23:12] <[S44]FLOZi> it was moving around and building things... took a while for anyone to notice it stopped working
[13:23:20] <[S44]FLOZi> (once unitlimits are reached)
[13:23:43] <[S44]FLOZi> i suspect it was kloots big refactor https://github.com/spring/spring/commit/62171b0326dd34ed90f45d7755eda8a68bed6391#rts/Sim/Units/CommandAI/FactoryCAI.cpp
[13:23:49] <[S44]FLOZi> but no evidence either way
[13:25:48] <[ARP]hoijui_g5> mmm ok
[13:28:55] ** vbs left the channel( Quit: Exiting ).
[13:29:16] <[ARP]hoijui_g5> yeah.. that commit looks good
[13:29:25] <[ARP]hoijui_g5> as a candidate

Additional Information

Testable with current S44 build: http://spring1944.net/files/Build/S44v158_PreMorgenrote.sdz
If you edit the LuaRules/Configs/craig/s44/unitlimits.lua and comment out the imposed limits, the barracks will happily chug out units forever, unedited, they stall due to trying to build engineers which are limited.

Tags

No tags attached.

Checked infolog.txt for Errors

Attached Files

Relationships

Relationships

Notes
~0008019 FLOZi (reporter) 2011-12-26 14:50	TL;DR in simple terms: if a builder tries to build something, and AllowUnitCreation blocks it, in previous versions it would stop trying to build it now it keeps trying to make that thing

~0008020 hoijui (reporter) 2011-12-26 15:28	also see the commit that FLOZi mentioned as most likely being the cause: https://github.com/spring/spring/commit/62171b0326dd34ed90f45d7755eda8a68bed6391#rts/Sim/Units/CommandAI/FactoryCAI.cpp this commit is between 84.0 and 85.0, where the change in behavior was introduced too. could it be what we have to handle the return value of CFactory::QueueBuild() in rts/Sim/Units/CommandAI/FactoryCAI.cpp:353 (currently ignored)?

~0008070 tvo (reporter) 2012-01-02 22:52	Intentional behavior is for factory to skip the blocked item, as there are no guarantees that AllowUnitCreation will ever start returning true again. So assume it was an accidental change, i.e. a bug.

~0008074 tvo (reporter) 2012-01-03 00:47	From this comment: +// if fac->QueueBuild() returned false, this will NOT be called (so +// when eg. the unit-limit is reached, build commands will remain in +// the queue) it looks like it was intentional. I suggest it is changed like I commented here in QueueBuild: + if (uh->unitsByDefs[team][buildeeDef->id].size() >= buildeeDef->maxThisUnit) + return false; // SKIP ORDER + if (teamHandler->Team(team)->AtUnitLimit()) + return false; // KEEP TRYING + if (luaRules && !luaRules->AllowUnitCreation(buildeeDef, this, NULL)) + return false; // SKIP ORDER + if (curBuild != NULL) + return false; // KEEP TRYING In other words, a factory shall keep trying to build the same unit if global/team unit limit is reached, because in that case it is guaranteed the next unit cannot be built either, so it would effectively erase its whole queue. But a factory shall skip one unit if building is blocked by per-unit unitlimit (maybe this limited unit will stay alive a very long time, while many unlimited units are still in queue...), or by Lua (can't say anything about the reason here: be optimistic and assume AllowUnitCreation returns true for next unit in queue). Probably even better would be, if a unit that cannot be built due to per-unit unitlimit or AllowUnitCreation is skipped, but an order to build it is added again to the end of the queue. (i.e., it is "temporarily skipped", "deferred", whatever you want to call it)

~0008111 abma (administrator) 2012-01-09 23:28	should be fixed by https://github.com/spring/spring/commit/d4d0308a3d9a60f767e4cb44a96a333f8b2e471d (thx kloot!(

Notes

Date Modified	Username	Field	Change
Issue History
2011-12-26 14:34	FLOZi	New Issue
2011-12-26 14:50	FLOZi	Note Added: 0008019
2011-12-26 15:28	hoijui	Note Added: 0008020
2012-01-02 22:52	tvo	Note Added: 0008070
2012-01-03 00:47	tvo	Note Added: 0008074
2012-01-09 23:28	abma	Note Added: 0008111
2012-01-09 23:28	abma	Status	new => resolved
2012-01-09 23:28	abma	Resolution	open => fixed
2012-01-09 23:28	abma	Assigned To	=> abma

Issue History