Anyone know when ItemDesc Blueprints are loaded?
I am trying to dynamically create items using a set of base mesh's. In theory, I could create a new mesh, a new mesh descriptor... append a bunch of mesh descriptors to the new mesh descriptor. Then build the new mesh with the new descriptor. Subsequently I could in theory assign this to the conveyor mesh object of an itemdesc.
I think I can do this to an instance of an itemdesc, so every item could in theory share that itemdesc. But I am floating the idea that for every unique item I should also have a unique ItemDesc. I think I can make them, but idk if I can register them.
11 Replies
Instances of an item descriptor?
So in theory... could I generate them on the fly at runtime? Or will Satisfactory get upset because they were not registered earlier in the process?
I should be all set right? The item descriptors are referenced by a bunch of things like recipes... but Im not making a recipe, just the item descriptor.
Ah, you want to generate new item descriptors at runtime, i.e. generate new classes
You may want to look into how ContentLib does its magic
Or use ContentLib's API
>xyproblem
We can better help you if you ask about the overall problem you're trying to solve instead of a specific approach you are trying to use to tackle it. Read more: https://xyproblem.info/
do you actually needs items generated at runtime, or are you trying to make it easier for you to make a bunch of similar items at development time @MrWolf
unless they have the potential to vary at game launch time, you probably want development time. in which case you should probably look at editor scripting
Yes. Due to codding up the bulk of a FGBuildableManufacturer, and my poor modeling skills. I shifted focus for a second to trying to implement Shapez like behavior into satisfactory. This essentially means I only have to model a few primitives and a half dozen buildings and dont have to focus on making anything look realistic or super pretty, just functional. So I've made a quarter circle and quarter square in blender. Imported those. While I could, in theory... generate a mesh for every single permutation. I figure that would be less then desirable. Similarly, a bunch of static mesh's flying around wouldn't be great from a performance stand point. So to achieve this, I figure a subsystem could be used. I could pass it a request for a shape using a FString, say "CuRu----", if I have not created that yet, create it and a ItemDesc for it, using the mesh as its conveyor mesh. To make "CuRu----" That would be a quarter circle top left quarter square top right, both uncolored. I can handle the mesh generation by creating a new mesh, creating a new mesh descriptor, and then merging the descriptors from the circle and the rectangle into that descriptor with the proper translation. For performance reasons, I'll use the same texture for everyone, and instead just translate the uvmap also found in the mesh descriptor... over to the proper colors. This should provide me a Dictionary.. sorry a TMap< FString, UStaticMesh* > with all of the meshs we have created up to this point. I think I can hold those in a package and save/load them but haven't got that far. In order to pass these around I'd need them of type FInventoryItem, which... means we need one of these TSubclassOf< class UFGItemDescriptor >, which implies I need to generate a UFGItemDescriptor for them.
Which... in theory... I should be able to do and hold a list for every one we make. I think if I hold them all as the same Class then they will stack ontop of eachother and make a mess. I could solve this by reducing inventory size to 1 I guess... but I think I'd prefer to make a new ItemDesc for each unique ShapeCode ex. CuRuCuRu, so on and so forth...
My concern is creating ItemDesc objects at runtime might run up against undefined behavior due to how various Objects and Managers are loaded.
that is a lot of words
1. this sounds like a big departure from how the game wants items to behave so you will need to do a lot of work (arguably more than learning how to model) to get it working, I highly suggest you test the gameplay side of it on a small scale first before spending a ton of time making a system that might not even be fun to play with
2. what you have described is not runtime generated items or meshes, it is still a known fixed set at development time, because end users can't define their own colors or shape types
shapez 2 already did 3d shapez
if you still want to go this shapez route, scripting on the blender side can create you all of the meshes you need at dev time, and editor scripting can create all the item descriptors for you
Uh... is it really feasible to hold all the meshes? Just one layer is 4 shapes per quadrant, 5 including none... so 625 possible combinations per layer. 5 possible layers... 95,367,431,640,625 possible shapes. Assuming we dont need to handle colors because I can handle that in the UVMap.
@Robb (Busy) Honestly its not about learning how to model. I have a pretty decent foundation and am continuing to build off of that. Rather... I'm a bit burnt out, so I'm trying something fun. I'll definitely get back into making the original stuff I was making. Ill also learn alot through this process too.
oh, I thought you were using shapez's system as an example. you actually want the full shapez range of shapes
good luck
Ill need it 🙂
Ty for taking the time to chat anyway