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
Rex
Rex•6d ago
Instances of an item descriptor?
MrWolf
MrWolfOP•6d ago
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.
Rex
Rex•6d ago
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
Robb
Robb•6d ago
>xyproblem
FICSIT-Fred
FICSIT-Fred•6d ago
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/
Robb
Robb•6d ago
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
MrWolf
MrWolfOP•6d ago
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.
Robb
Robb•6d ago
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
MrWolf
MrWolfOP•6d ago
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.
Robb
Robb•6d ago
oh, I thought you were using shapez's system as an example. you actually want the full shapez range of shapes good luck
MrWolf
MrWolfOP•6d ago
Ill need it 🙂 Ty for taking the time to chat anyway
Want results from more Discord servers?
Add your server