Ok, so I 100% understand how ridiculous that question sounds and I’m sure the answer will be “no”… but here’s the use-case and perhaps you have alternative approaches that I could use.
I am spawning a Blueprint actor and attaching it to another actor. I use the SpawnActor node, setting the Blueprint class and create a spawn position. At the moment this position uses a hard coded value which is the size of the spawned actor’s BoxCollision extents multiplied by 2. This is allowing me to place actors neartly side by side.
The problem is, I have to hard code this value, as I cannot access the BoxCollision extents before I’ve spawned the Blueprint class - and at that point, I’ve already positioned it.
So, my choices seem - spawn it at a temp position, perhaps the parent actors location, then, once I have the instance of it, grab the BoxCollision extents value and reposition it - or - I could spawn a “dummy” instance, get the value, then dispose of it - just doing this once (not each time). This would then allow me to use that value in the creation of the spawn transform which I can pass in to the SpawnActor node.
I wondered whether I could do it a different way. As the Blueprint is already created and I’ve already set those values for the extents I figured they might be accessible somehow. I have tried creating a reference to the Blueprint class, but I couldn’t access the BoxCollision component, I’m guessing this is instantiated at run time. This feels like it would be the cleaner approach though, e.g. I don’t unnecessary spawn something to just throw it away, and I dont have to temporarily position actors only to then move them almost immediately.
Can I access properties of a Blueprint
before it’s instantiated?
The problem is, I have to hard code
this value, as I cannot access the
BoxCollision extents before I’ve
spawned the Blueprint class - and at
that point, I’ve already positioned
it.
It sounds like a simple case of utilising the Construction Script and an Exposed variable:
create a variable in the spawned actor to hold the data, flag it as Instance Editable and Expose it on Spawn
Thanks for the reply, and that’s really super useful to know - not something that would have occurred to me, although I’m not sure it was quite what I was after.
It’s not that I want to set the size of the Box Extents on spawn, what I want to do is retrieve them and then use the value (or half of it) to calculate the spawn position of each actor that is spawned.
To make it perhaps clearer. Consider Space Invaders, all the invaders in a row, at an equal distance apart. I want to do something like that, using the extents of the box collider on the blueprinted “invader” in the calculation for the position for the spawn.
That way, should I decide to change the size of the actors being spawned, the volume would be increased, but the functionality for spawning them would continue to place that correctly.
Just had quick look, looks like it only presents the variables for that class, not components of the class as well, from what I can see anyway. There’s also nothing I can see to make the component a variable, although its already listed under that section by default, under “Components” etc.
I think you may want to perform sizing prior to spawning an actor. Don’t think in “visual” objects at all times. You can have data objects that represent the information you are speaking of, set that, then calculate the spawn pt for the graphics actor. Does that make sense?
Or, if you’re stuck with the spawning of an actor and need to determine the size afterward, just make the actor invisible until you do with it what you need to, then make it visible.
That is not going to work in blueprints. You could store a component class in a variable, or even fiddle with soft references but I do not feel it’s worth it in this case. Do consider what @mrteuy is suggesting.
You can always spawn a hidden object with disabled collision (in case it could interfere with something else) and set it up with the Construction Script - the actor has access to its own components here.
In case you’re dealing with something more procedural - an actor that spawns components from a randomised list run-time, or an actor that simply does not know its final state upfront, keep it hidden until all components are present, recalculate, shift it to a new position and only then show it.
I think you may want to perform sizing prior to spawning an actor.
I kinda have though haven’t I? I’ve created a Blueprint Actor with a BoxCollision component and I’ve specifically set the extents of that BoxCollision component. So those values are already set.
You can have data objects that represent the information you are speaking of, set that, then calculate the spawn pt for the graphics actor. Does that make sense?
So, hold the extents in a separate variable, then use that for calculating the spawn location, spawn the Blueprint Actor, and then set the BoxCollision component afterwards?
I can see that that may work, does seem to make it a bit pointless to be able to set things up in a Blueprint in the first place though if I need to do that.
You can always spawn a hidden object with disabled collision (in case it could interfere with something else) and set it up with the Construction Script - the actor has access to its own components here.
I did consider spawning a kinda “temp” one first, and then grabbing the values from it, but that seemed a bit wasteful, as once I had the values I’d just be throwing it away again. I kinda assumed that I’d be able to just access the “class” of the Blueprint, the BoxCollision component being a part of that, and then just access the values that had already been set, albeit not instantiated.
Just feels a bit odd then not actually having the BoxCollision component set to the correct size in the Blueprin in the first place then though, e.g. it duplicates things, I might have it defaulting to 32x32x32 in the Blueprint, and then squirrelled away in the code is the “now set it to 100x100x100” etc… becomes a bit obfuscated.
The other way around, e.g. get the value from what’s alreadt set seemed to make more sense to me, e.g. I “design” it in the Blueprint, then get the values in the code…
I appreciate it seems to be the only way to do it though, just really surprised that the components that are added in a Blueprint are not accessible via Blueprint before being instantiated, like the default values are… I’d kinda expected the default values to also include a variable for each component, which I could then have branched off of to get its specific default values etc…
I often come across things like this and end up feeling like I’m always asking for the moon on a stick… lol…
Unless I’m missing something complete out of line, I think you want to place something in the editor and have it adjust a collision object to match it’s size? That can be done using a combination of what’s been stated - Everynone’s method of exposing variable and using them set in the editor using Construction Script works. If during gameplay, just add something in the Begin Play event to match spawned objects as well should top it off.
I ran some quick tests with spawned objects setting dynamic sizes at creation and worked as expected - in the Begin Play even, I set scales to an exposed vector variable.
Think of it as placing a row of cubes side by side… each cube is what I am spawning. But in order to know where on the X axis I should spawn the next one (so they are exactly the same distance apart), I need to know the size of the BoxCollision component on said Blueprint Cube.
Case in point…
In the editor I’ve set this to be 100x100x100, but I don’t want to hard code those values into the nodes that are spawning them, because if I wanted to change the size of the Blueprint Cube later on, this would break. So, by extracting this information from the Blueprint - before - I spawn them, I can then determine exactly where they should be placed and there’s no hard coded magic numbers.
I’m pleased you’re getting something out of this though!
Somehow I think OP needs to adjust a size of an object by the size of another object he is about to spawn.
As in: I’m about to spawn a giant puzzle piece, so I need to make room by making the preceding piece smaller to make the big one fit in. In order to do that I’ll query the big piece ahead of time for its size.
The big piece is made of many components, though - we can only get its final size once all of its components have initialised, which will not happen until it’s actually spawned.
I don’t think blueprints can pull component’s defaults from the owning class.
That’s very nice. It didn’t occur to me to get the size of the box extents after spawning the first one. The first would be direct from the Blueprint, so would be the size I wanted and its only the subsequent ones in which I really state where they have to go.
This would work really nicely, I don’t need the random sizes, or anything more elaborate, but the setting of the variable their is perfect.
I would mark this as the solution but I don’t think I can because it’s a comment etc.
Thanks for this, really appreciate the responses to this thread by all, and the different ways of looking at the problem
Above, I do not feed the object a transform; instead, I do let it know where the previous object is, and its size. Below, the Construction Script picks it up to create a new location based on the previous and current data. Do note that each box has random size here, nothing is hard-coded:
edit: there are many ways of doing the above. For something more elaborate, you could have a dedicated spawn manager actor that samples the environment (with traces or volume collision) and sends that data to the next actor. That actor can interpret that data - perhaps it indicates that a large enough empty volume is present on the game board and spawns a chunky boss in the middle. Or even adjusts its size dynamically to whatever space is available.
