[]
Yeah, I get what you mean. You come from Unity, are you? That’s typical there and, yes, it is “done all the time” in Unity. Still, it IS a bad habit, nonetheless.
Nah. Never worked with Unity. But In (Delphi) coding its quite common to set the initial values of a sub object in the constructor of the actual object.
Like in this example I posted avbove, thats how C++ does it as well…
https://msdn.microsoft.com/library/f1h35k32%28v=vs.110%29.aspx
Maybe I don’t comprehend what you mean here because you can create mesh components and set a transform for them via blueprint in the constructor. I thought you meant full mesh generation as in outside objects from inside an object constructor, but if you mean components you CAN do it.
If you then intend full procedural level design than that’s best done in level blueprints (or you can mix the two things together depending on what you want to do).
[]
If you then intend full procedural level design than that’s best done in level blueprints (or you can mix the two things together depending on what you want to do).
Yeah, Im taking about procedural placement of standard meshes.
But instead of just placing meshes, I wish to place actors that create those meshes.
Imagine a BP that cretaes a house out of modular pieces.
Then I want to have another BOP that places those house BPs across the level.
And that is whats not possible. Actors cant spawn other actors at designtime…
[=;509218]
Yeah, Im taking about procedural placement of standard meshes.
But instead of just placing meshes, I wish to place actors that create those meshes.
Imagine a BP that cretaes a house out of modular pieces.
Then I want to have another BOP that places those house BPs across the level.
And that is whats not possible. Actors cant spawn other actors at designtime…
Yeah, I saw your post, now I understand what you mean. I never had to dabble with something similar so I didn’t know about this. Problem is: I don’t know the possible consequences of enabling something like that in a general constructor function in BPs. It is something that goes beyond my level of experience in the engine to be frank.
[=;488642]
Another thing is refactoring. It is a real pain to move a variable declaration or a function with its implementation to a parent class.
One has to manually recreate the function in the base class, copy all nodes inside, delete the child class implementation, drag the inherited function in and reconnect all nodes.
About that:
I think it would be quite helpful if we can replace variables inside a blueprint script more efficently. It is already possible to drag-and-drop a variable - lets say from type integer - onto another variable, that is connected to some pins, in order to replace a variable that is of the same type (in this case integer), while maintaining the pin connections. If you hold ctrl before drag-and-dropping, you will automatically set your dragged variable to the dropped variable.
It would be really if - by pressing and holding SHIFT for example - you could drag and drop a variable onto another and it would replace ALL occurences of this variable with the one you dragged (maybe including “setting” the variable?). It would also be if type-compatibility would be enough for this. For example, if I could automatically drag and drop a float onto an integer to replace it, while it should be not possible the other way around due to loss of information.
Edit: I also think that this is quite feasible, since it is already possible to find ALL references to a variable
[=;509381]
About that:
I think it would be quite helpful if we can replace variables inside a blueprint script more efficently. It is already possible to drag-and-drop a variable - lets say from type integer - onto another variable, that is connected to some pins, in order to replace a variable that is of the same type (in this case integer), while maintaining the pin connections. If you hold ctrl before drag-and-dropping, you will automatically set your dragged variable to the dropped variable.
It would be really if - by pressing and holding SHIFT for example - you could drag and drop a variable onto another and it would replace ALL occurences of this variable with the one you dragged (maybe including “setting” the variable?). It would also be if type-compatibility would be enough for this. For example, if I could automatically drag and drop a float onto an integer to replace it, while it should be not possible the other way around due to loss of information.
Edit: I also think that this is quite feasible, since it is already possible to find ALL references to a variable
Hi ,
Thank you for your request. I have entered a feature request, UE-29283, to be considered by the development staff.
[= ;509660]
Hi ,
Thank you for your request. I have entered a feature request, UE-29283, to be considered by the development staff.
Thank you very much 
Actually, I gave it some more thought. While the feature above might be quite useful already when you need to change your variables inside a blueprint, for migration of blueprint scripties to other blueprint following feature might be more interesting:
With selecting nodes in a blueprint and copy and pasting them to any other blueprint, I am able to transfer all nodes I have to a different blueprint. If I do so and I have variables of the same name inside my blueprint (even if their type is different), the node gets update if possible. So for example if it was originally a setter for a float and I have a variabe of type boolean in my new blueprint with the same name, the setter node will be converted from a setter for a float to a setter for a boolean. If that node was not a setter and lets say an “Float + float” node, then the link to that node will simply get broken when pasted because there is no comparable node for booleans.
What I do not like about this is: When I have a variable of the same name in my new blueprint, but want to call the variables used in the old blueprint differently in my new blueprint, I lose, because the nodes get automatically updated for the existing variable.
If a variable of the same name exist, It would be cool if there was a prompt asking you what to do: Behave as always and try to integrate the code into the existing one or create a new variable with a different name with which the new blueprint scripties should be associated.
If there are variables referenced in the blueprint scripties that do not exist in the new blueprint, a prompt should ask me for what I want to do: Ignore it (and behave as always), create a new variable and associate it with the blueprint scripties or simply promote the variables (this one would skip the step of setting the type and name of the new variable).
Also, it should be possible to specify a type for the new variables that is compatabile with the old one - in case the class changes due to changes in inheritance structure.