Matthew
BloodStar Technologies
14
   |
Posted - 2014.05.06 20:39:00 -
[1] - Quote
Firstly, I like the second pass on the labs, makes much more sense.
Steve Ronuken wrote:tl;dr:
Apply a reduction to the cost of all jobs stated in an array.
Apply a penalty for every job started in an array.
So you get a 0.9 multiplier on cost for running at a pos, then a 1.01*number of active jobs in that structure. (if it knows that)
Means having multiple structures has a reasonable benefit.
I prefer the "inherent workers" approach from the previous thread to this one. While the above idea is easier to implement, I'm not keen on the gradual increase, and the lack of a cap on the increase. The gradual increase means that it is unclear what capacity the starbase arrays are "supposed" to have (similar to how the endpoint for ME/TE research used to be rather unclear).
The "inherent workers" approach means you keep the full discount up to the intended capacity of the array, and pay normal public prices for all jobs above that. Yes, it means you can continue loading up the array with jobs as far above that line as you like, but if we are letting people do that in NPC facilities, preventing it in starbase facilities would be a significant disadvantage to starbases.
While the "inherent workers" approach is slightly more complex to implement, it still isn't too bad. You need 2 additional facility attributes for each array and activity type (number of worker teams and worker cost multiplier). Industry jobs gain an additional attribute, StaffSource, being the itemID of the system or the array, depending on whether it is using public or inherent workers respectively. The Teams section of the industry UI would need a slight tweak, breaking it out into two boxes - I'd call these something like "Staff" and "Specialists". "Specialists" would be either blank or a Team. "Staff" would be either System staff or Array staff. If you select the Array staff, then the server goes away and counts the number of jobs currently installed in that array where WorkerSource = ArrayItemID, if that count is less than the InherentWorkers attribute of the array, then the job is permitted to be submitted, otherwise it is denied.
This adds an element of strategic choice for the player - which jobs do they choose to run using the Array staff, and which do they pay extra for the System staff.
It also adds more flexibility to the system, as other modifiers could be attached to the Array staff - e.g. an additional ME bonus could be attached to assembly array staff, balanced by only being able to be applied to a small number of jobs at a time. You could also do things like make intensive arrays with larger bonuses, but smaller staff counts, or bulk-build arrays with larger staff counts but a smaller bonus.
Babbet Bunny wrote:Please change how the per run cost reduction works. Make it per run and not per hour of run.
This is a really good point - because the installation cost scales based on the length of the job, time bonuses introduce an indirect penalty to this element of the installation cost formula. While this is most dramatic for the starbase arrays due to their very large bonuses, it will presumably also affect the time bonuses from TE research, skills that bonus job time etc.
While you do get a throughput benefit from completing the jobs faster, I'm uncomfortable with this disadvantaging the installation cost formula, as some of these factors (TE research, skills) are ones that you cannot turn on and off, so it isn't really contributing to meaningful decision making.
Probably the easiest fix for this is to adjust the formula so that the "hours already run" term is evaluated prior to any bonuses being applied.
Oxide Ammar wrote:So, what you can't do to POS code ? the ability change the UI to make it something similar to the new UI of manufacturing ?
From what we've seen change, and what we've been told can't be changed, I'd surmise that if there is already an array that does basically the same thing, they can create variants that use that same effect. The refining and compression arrays fundamentally do the same thing - take away X units of an item, and give back Y units of a different item. Similarly, adjusting the values of individual things (PG usage, fuel consumption per hour, ME/TE bonuses) is just adjusting a number within the existing framework, its not fundamentally changing how those numbers are then applied by the starbase code.
The things that we aren't getting are things that no existing array does, or that other aspects of the starbase code do not support. For example, being able to have the inventories of the various manufacturing arrays talk to each other (or even act as a single unified space) would be great, but the current starbase code means that the arrays do not know that they are all at the same starbase, so they don't know whether they should be able to talk to each other or not. Now, you can do some 3-D geometry to work out which control tower is closest to an array, and which other arrays are within range of that control tower, but it gets very messy and potentially very resource intensive in systems with dozens of control towers and hundreds of arrays. |