Difference between UFGRecipe* and TSubclassOf< class UFGRecipe > as implemented by BuildableManufact
Anyone know why the BuildableManufacturer class holds both and My understanding is that the first, "UFGRecipe*" would allow any pointer to any UFGRecipe object, but "TSubclassOf< class UFGRecipe >", also allows pointers of children of UFGRecipe to be assigned to it. Functionally, I believe they are very similar... perhaps the advantage of TSubclassOf as implemented here is simply to avoid casting? Maybe the reason both exist, is because classes that inherit UFGRecipe can be held in mCurrentRecipe, and instead of casting those as UFGRecipe where UFGRecipe is required, we cached the cast? Idk... I am way out on a limb on this
11 Replies
i dont know either, but the descriptions are slihtly different
what sparks my eye is CDO part, an
TSubclassOf<class UFGRecipe> doesnt need to be the CDO, so maybe they store a reference to its CDO
to get a CDO it will need to do
Cast<UFGRecipe>(mCurrentRecipe->GetDefaultObject());
so they might want to avoid thatRecipes are class-based, instancing
UFGRecipe objects doesn't make sense. TSubclassOf<UFGRecipe> is a UClass* that is a subclass of UFGRecipe. The code in question is caching the CDO of the recipe class so that it doesn't need to call mCurrentRecipe->GetDefaultObject() (which returns a UFGRecipe*) a bunch of times.
I don't think you are supposed to set the value of either of these variables. There should be a function to set the current recipe that updates both variables accordingly.There will be a function when Im done writing it. Im essentially re-implementing the manufacturer class. The reason is because I need to implement a lot of the underlying functions. Item collection and output. Inventory manipulation and management. Recipe management. While I could just tack those along side a manufacturer… if Im already doing what the manufacturer does, may as well do both… bo reason to call a css implementation then my implementation because Im already looping over the input connections etc.
:adisweata: that sounds like a lot of work
I srsly tried avoiding writing up my own manufacturer. But I essentially need two manufacturers in one building. I've tried a bunch of different solutions for a few days... looking at what others have implemented RRD and Nogs... everyone starts at a BuildableFactory or higher... it just makes sense
This will also give me granular control over everything which allows for additional functionality. Recipies with percent chances of outputting different byproducts. Outputting 2 or more outputs onto the same belts. Inputting 2 or more different items from the same belts... on and on and on...
yeah if you want all those things, seems like a different baseclass for your building makes sense
Why do you need two manufacturers together?
To make burner manufacturers
It needs to eat fuel and output byproducts which enables it to eat input items and spit out output items.
@Rex when I have an initial revision done, would you consider reviewing the pull request I make to my repo? You seem to have a lot of knowledge and catch me in my mistakes quite often.
Totally cool if you don't just figured more eyes on it would make the code better. All good.
I'm afraid I don't have the knowledge to review such a thing, sorry.
Thank you anyway.
Nice catch on the Cast<UFGRecipe> of the default object ^_^
thank you