Riot Control ship queue bug (?) and question

[Catma]

So I had 4 SS constructors going, and set two of them to build 2 custom riot control ships, and the other two to build 2 of a different riot template. At one point, I had 3 Riot Control ships in service, and at least 3 more were queued and building, taking up resources, etc. I can find or reproduce a save if this is a bug, and if that proves necessary. This is my first time using multiple constructors in the same system, so it may be normal behavior that I hadn't noticed yet.

Secondly, is there any way to see what is mounted on the Riot Control ships (besides zooming all the way in and hovering over the hardpoints)? This info should be in the tooltip somewhere, IMO, as well as a template name if one applies.

[keith.lamothe]

So I had 4 SS constructors going, and set two of them to build 2 custom riot control ships, and the other two to build 2 of a different riot template. At one point, I had 3 Riot Control ships in service, and at least 3 more were queued and building, taking up resources, etc. I can find or reproduce a save if this is a bug, and if that proves necessary. This is my first time using multiple constructors in the same system, so it may be normal behavior that I hadn't noticed yet.

I would need a save where that's happening or could be reproduced to hunt it down

Secondly, is there any way to see what is mounted on the Riot Control ships (besides zooming all the way in and hovering over the hardpoints)?

Other than inferring based on whether you see the shield bubble and what it's shooting, no.

This info should be in the tooltip somewhere, IMO, as well as a template name if one applies.

I may be able to put the list of modules in the tooltip (only if there's only one ship being represented, not when mousing over the planetary summary and there's more than one), but the template is not actually associated with a unit once it's built.  Modules may be destroyed, scrapped, rebuilt, etc.

[Wanderer]

So I had 4 SS constructors going, and set two of them to build 2 custom riot control ships, and the other two to build 2 of a different riot template. At one point, I had 3 Riot Control ships in service, and at least 3 more were queued and building, taking up resources, etc. I can find or reproduce a save if this is a bug, and if that proves necessary. This is my first time using multiple constructors in the same system, so it may be normal behavior that I hadn't noticed yet.

I would need a save where that's happening or could be reproduced to hunt it down

Pretty easy.  Build off six starship constructors, then have each one queue up a light starship.  You'll be building 6 even if you fleet cap at 5.  It's a little more painful when you've got 3 of those and they're all competing for 2 spire starship builds.

[keith.lamothe]

Pretty easy.  Build off six starship constructors, then have each one queue up a light starship.  You'll be building 6 even if you fleet cap at 5.  It's a little more painful when you've got 3 of those and they're all competing for 2 spire starship builds.

Ohhh, I got it.  Sorry, misunderstood.  It's not a bug that "potential" ships in other queues do not count against the ship cap for the purposes of determining whether a given dock can start a ship.  Once there's actually a full cap "in service" the other docks will skip over that type, but iirc they don't lose the progress on it (I could be wrong on that; that would be more painful if it lost that).

[Wanderer]

Pretty easy.  Build off six starship constructors, then have each one queue up a light starship.  You'll be building 6 even if you fleet cap at 5.  It's a little more painful when you've got 3 of those and they're all competing for 2 spire starship builds.

Ohhh, I got it.  Sorry, misunderstood.  It's not a bug that "potential" ships in other queues do not count against the ship cap for the purposes of determining whether a given dock can start a ship.  Once there's actually a full cap "in service" the other docks will skip over that type, but iirc they don't lose the progress on it (I could be wrong on that; that would be more painful if it lost that).

I *think* they transfer current progress to the next ship in queue, but it's hard to tell sometimes.  I agree, it's never struck me as a bug though, just bad planning.  If I have ships like that I'll dedicate a single constructor to them (I do that with Raids a LOT, since I keep overusing them and am a bit suicidal with 'em.).

[TechSY730]

Pretty easy.  Build off six starship constructors, then have each one queue up a light starship.  You'll be building 6 even if you fleet cap at 5.  It's a little more painful when you've got 3 of those and they're all competing for 2 spire starship builds.

Ohhh, I got it.  Sorry, misunderstood.  It's not a bug that "potential" ships in other queues do not count against the ship cap for the purposes of determining whether a given dock can start a ship.  Once there's actually a full cap "in service" the other docks will skip over that type, but iirc they don't lose the progress on it (I could be wrong on that; that would be more painful if it lost that).

AFAIK, the behavior in these circumstance where a queued item becomes ineligible to build due to whatever is:
If there is something else eligible to build in the queue, refund all resources spent so far on the now ineligible ship, and move to the next eligible item. (or possibly, transfer some of the already spent resources to the new ship's progress, refunding any leftovers)
If there is no other eligible item in the queue, and progress has not started on that item, then stop constructing, stop consuming resources, engineers stop assisting it for construction, until it becomes eligible (say, the ship count fell below ship-cap), at which case it should resume normal construction on that ship.
If there is no other eligible item in the queue, and progress has been started on that item, then continue finishing the item, but don't actually "emit" it.
   If another ship in the queue becomes eligible while building the ineligible item, refund all resources spent so for on the current ineligible ship, and move on to the next eligible item. (or possibly, transfer some of the already spent resources to the new ship's progress, refunding any leftovers)
  When the current ineligible item is done, don't actually emit it, stop constructing, stop consuming resources, engineers stop assisting it for construction, and wait until it becomes eligible to build. If it does become eligible to build, then since all the resources and time were already put into it, it should "release" the item with no extra resources or time.
     If another ship type in the queue becomes eligible before the current complete yet ineligible item becomes eligible, then refund all resources spent so far on the ineligible ship, and move to the next eligible item. (or possibly, transfer some of the already spent resources to the new ship's progress, refunding any leftovers)

In no case should resources be spent or engineers be trying to assist construction when no progress can be made on the current item. Also in no case (resource caps aside) are resources wasted.

[TechSY730]

The whole process in the previous post is just my understanding. It is not necessarily a bug if that is not the way it handles it.

It IS a bug if the property of whatever process it uses I mentioned (quoted below) is violated.

In no case should resources be spent or engineers be trying to assist construction when no progress can be made on the current item. Also in no case (resource caps aside) are resources wasted.

EDIT: Also, when I say engineers stop constructing, I mean it no longer becomes an eligible target for idle/FRD engineers seeking targets to auto-assist, and any currently auto-assisting engineers stop and start finding other things to do. Engineers given an explicit order to assist something should continue trying to assist it, regardless of if it is doing anything or not. Of course, if nothing is being built or repaired at the moment, the engineer's assistance will do nothing, and consume no resources. You can tell that an assist operation is doing nothing when the "assist beam" turns red.

[Catma]

Thank you for the clarifications.

I may be able to put the list of modules in the tooltip (only if there's only one ship being represented, not when mousing over the planetary summary and there's more than one)

Of course. It would be a huge mess any other way.

Regarding the build queues, I can see how it would be desirable sometimes to allow pre-building of replacement ships. On the other hand, why can't I queue a large number of replacement ships to be pre-built in a single dock? That would definitely be ridiculous and counter-intuitive behavior, and allowing it for a single ship is only a difference of degree.

It strikes me as odd, is all. I suppose I'll just have to pay more attention to my SS constructors.

[keith.lamothe]

Regarding the build queues, I can see how it would be desirable sometimes to allow pre-building of replacement ships. On the other hand, why can't I queue a large number of replacement ships to be pre-built in a single dock? That would definitely be ridiculous and counter-intuitive behavior, and allowing it for a single ship is only a difference of degree.

It's not doing exactly that: if the cap is 5, and you have 5 in service, queuing another one does not cause any construction to take place on it.  If you have 4 in service, and 2 constructors queued to build one, they both build normally until one finishes.  The game has no way of knowing which one should "take priority" and which one should skip production, and even if it did there's no guarantee that the "priority" constructor would survive to finish construction.

It does lead to some oddness, I admit, but I think it's the least of the available problems

[Catma]

I understand. The survival issue is the nail in the coffin, really. Thanks again!

[TechSY730]

Regarding the build queues, I can see how it would be desirable sometimes to allow pre-building of replacement ships. On the other hand, why can't I queue a large number of replacement ships to be pre-built in a single dock? That would definitely be ridiculous and counter-intuitive behavior, and allowing it for a single ship is only a difference of degree.

It's not doing exactly that: if the cap is 5, and you have 5 in service, queuing another one does not cause any construction to take place on it.  If you have 4 in service, and 2 constructors queued to build one, they both build normally until one finishes.  The game has no way of knowing which one should "take priority" and which one should skip production, and even if it did there's no guarantee that the "priority" constructor would survive to finish construction.

It does lead to some oddness, I admit, but I think it's the least of the available problems

As long as the one that didn't "win" the race condition was either canceled and refunded, or held until it can be built and then emitted immediately, I'm fine with that behavior.

[Hearteater]

It wouldn't be unreasonable to count under construction against the cap.  If I have two starship constructors queued to build the same ship, whichever gets their first would start construction and the other would skip it.  This avoids the problem completely, is the way I always assumed it worked anyway, and I believe is even how most RTS games handle the situation.

[Cyborg]

http://www.arcengames.com/mantisbt/view.php?id=5513

I've already opened this bug.


My suggestion:

I think you need to implement some basic locking for the construction. I don't know how you have the code set up, but you need to give credit for where the ship is beginning construction at the constructor itself and abstract out the ship caps. This means that whenever a constructor takes a ship off the queue, they have to request a lock from this ship cap object first.

It has to be considered a bug when 2 different constructors are building the same ship, presumably using resources for both of them for one ship, and it only comes out of one of them, leaving the other as a infinite resource drain.

[keith.lamothe]

It has to be considered a bug when 2 different constructors are building the same ship, presumably using resources for both of them for one ship, and it only comes out of one of them, leaving the other as a infinite resource drain.

Ok, I'll make a note to look at that save because even in the current implementation I can't think of why it would spend resources without making progress on the build.  Nor why it would continue to try to make progress once the actually-in-service count reached the cap.  Thanks for the clarification on what was going wrong.

[TechSY730]

Oh, so when a constructor "loses" this race condition, it continues to drain resources like it is building, even though what it is building is already done (but cannot come out due to ship caps)?
Yea, that's a bug.

So, in this case, should it cancel the order (or send it to the back of the queue in circular building mode) and refund the cost? Or hold the ship until ship count falls below ship cap?