Production block handlers #276
Conversation
Update Refinery registration to parental ProductionBlockHandler, from grandparental FunctionalBlockHandler
This file provides handler class for IMyProductionBlock, the parental class for IMyAssembler and IMyRefinery blocks. It also subsumes much of the code that had been present in AssemblerBlockHandler.cs, and as such that file needs to be removed from the repository. This file does re-provide handler class for IMyAssemblerBlock and its properties and methods available above and beyond IMyProductionBlock.
Functionality subsumed by new ProductionBlockHandlers.cs
Because apparently project blows up if we delete AssemblerBlockHandlers.cs and don't change the .csproj reference to refer to ProductionBlockHandlers.cs instead
…dler, oops So, that's important, yeah. whoops. ProductionBlockHandler needs to be a generic class
This should be an IMyProductionBlock, not an IMyAssembler
* fixed two typos * elevated member methods to protected access so child class can access them
added .IsProducing boolean property handler (minor) clarified a TODO comment-note for PropertyHandler .CREATE
Add Property .PRODUCING, to handle IMyProductionBlock.IsProducing
Add words for new Property.PRODUCING, which handles IMyProductionBlock.IsProducing
update comment about minification symbol for class ProductionBlockHandler
Add comment about minification symbol for new Property PRODUCING
|
I also think overloading the existing property seems better. If that's the plan anyway, I'd rather not introduce a similar sounding property. Are there challenges with getting the overload to work correctly? |
| AddPropertyHandler(Property.AMOUNT, new PropertyHandler<IMyAssembler>() { | ||
| AddBooleanHandler(Property.PRODUCING, b => b.IsProducing) | ||
|
|
||
| // TODO: if supplied with no argument, return <IMyProductionBlock>.IsProducing |
There was a problem hiding this comment.
If we plan to do this, do we need the separate property?
There was a problem hiding this comment.
I don't know. I haven't been able to grok how to overload your Property.CREATE's ParameterParser handler, visavis the ValuePropertyCommandParameter() assigned to words "produce", "producing", "create", "creating", "make", "making".
I do think that having the inversion of "idle", "idling" is clearer, but I don't think inversions are possible with ValuePropertyCommandParameter()'s, from what I understand of their code.
could do a thing where we make a command of "produce", "create", "make", and a seperate value-fetch with "working", "producing", "creating", "making" (with inversions of "idle", "idling"), but I don't know how to do that
the answer of your query touches on aspects of EasyCommands that I haven't been able to understand, yet; namely, the input parser and lexer
| namespace IngameScript { | ||
| partial class Program { | ||
| public class AssemblerBlockHandler : FunctionalBlockHandler<IMyAssembler> { | ||
| public AssemblerBlockHandler() { | ||
| AddBooleanHandler(Property.SUPPLY, b => b.Mode == MyAssemblerMode.Assembly, (b, v) => b.Mode = v ? MyAssemblerMode.Assembly : MyAssemblerMode.Disassembly); |
There was a problem hiding this comment.
I take it the AssemblerMode is deprecated in favor of the more generic "isProducing" ?
There was a problem hiding this comment.
AssemblerMode is seperate from IsProducing. IsProducing is merely a getter, which resolves to "is this block actively crafting blueprints in its queue", regardless of what mode the assembler is in. mode would still be required for AssemblerBlockHandler to handle Assemble vs Disassemble
| }); | ||
| AddPropertyHandler(Property.DESTROY, new PropertyHandler<IMyAssembler>() { | ||
| Get = (b, p) => ResolvePrimitive(b.Mode == MyAssemblerMode.Disassembly && GetProducingAmount(b, p) >= GetRequestedAttributeOrPropertyValue(p, 1f)), | ||
| Set = (b, p, v) => { b.Mode = MyAssemblerMode.Disassembly; AddQueueItem(b, p); } |
There was a problem hiding this comment.
Is setting the AssemblerMode still to correct way to do this, or should it be updated?
There was a problem hiding this comment.
AssemblerMode is seperate from IsProducing. IsProducing is merely a getter, which resolves to "is this block actively crafting blueprints in its queue", regardless of what mode the assembler is in. mode would still be required for AssemblerBlockHandler to handle Assemble vs Disassemble
|
I would like to point out that I built and minified my fork with these changes, and ran the resultant script in-game without problems, save that the inversion words "idle" and "idling" seemed to always result in |
|
|
||
| AddPropertyHandler(Property.AMOUNT, new PropertyHandler<IMyAssembler>() { | ||
| AddBooleanHandler(Property.PRODUCING, b => b.IsProducing) |
There was a problem hiding this comment.
could the missing semicolon be an issue here? seems like it should be an issue
There was a problem hiding this comment.
blast it, I thought I'd corrected that in my github repo -.- I know I did in my local files. sorry!
Get some tests created for these properties and you'll be able to debug through the execution, that may shine some light on why the value isn't working. it's also much faster than minifying the script and trying to load it in game. Should drastically improve your turn-around time. You should be able to just extend/modify the existing test files: |
Because I am derp. missing semicolon
Templates are hard, yo :|
restructured block handlers to accommodate intermediate interface class IMyProductionBlock between IMyFunctionalBlock and IMyAssembler, which is also the parent class of IMyRefinery. This exposes whitelisted IMyProductionBlock API to EasyCommands, specifically .IsProducing (which is true if a ProductionBlock is (1) Powered, (2) Functional, (3) Enabled, (4) Actively processing blueprints in its queue).
block handler heirarchy has been changed thusly:
old: AssemblerBlockHandler : FunctionalBlockHandler
new: AssemblerBlockHandler : ProductionBlockHandler : FunctionalBlockHandler
also, block registry for Refinery is now as ProductionBlockHandler
to support access to API property .IsProducing, a new Property has been added to Types.cs, PRODUCING
to support parsing of the new Property, new words have been added to ParameterParsers.cs:
"working", and inverse "idle", "idling"
WARNING: whilst new word(s) "working" function as intended, inverse words "idle", "idling" seem to only always result in False
TODO: overload ProductionBlockHandler's PropertyHandler .CREATE to handle no-arg instances of "producing", "creating", "making" as if words for Property .PRODUCING