And what if i want all of the non-Macro/Function advantages ?

[anonymous_user_5326e6bd]

Macro has no normal local variables, functions can’t have delays, not even talking about events.
Is it ok that if i use a blueprint as a funciton i will just spawn an instance of it anytime i want to use it ? Will it kill the performance ? I kinda already guess it will, but i’m really desperate here. i really don’t wanna spent my developing time with watching the compiler doing it’s thing ( C++ ) each time i wan’t to change something in the script and lose the whole momentum with it…

[AnadinX]

I think the iTween port (search the forum) does it that way, it spawns iTween Actors to do its thing then destroys them

[Zeustiak]

There is some balance to be had. I don’t think using a separate blueprint where normally you would use a function would be the best way to do things. Functions have input and outputs, make use of them. Collapse everything around the delay, event, etc into a function.

Blueprints are what houses macros, delays, functions, etc. Make use of that, but don’t split things up that don’t need to be split up. It really depends on what you are doing and why.

The whole system is built to be modular. Make a blueprint where a blueprint would make sense. I don’t think making 20 blueprints instead of 1 blueprint with 20 functions would be the right way to go, but I doubt it would add any amount of overhead that would affect your performance. The real problem would be that you are losing a lot what makes blueprints visual by splitting it up like that. You might as well be working in C++ at that point.

[anonymous_user_5326e6bd]

@Anadin;185341

I think the iTween port (search the forum) does it that way, it spawns iTween Actors to do its thing then destroys them

Thanks, i would really like an UnrealEngineDeveloper to confirm it so i can be sure.

@;185343

There is some balance to be had. I don’t think using a separate blueprint where normally you would use a function would be the best way to do things. Functions have input and outputs, make use of them. Collapse everything around the delay, event, etc into a function.

Blueprints are what houses macros, delays, functions, etc. Make use of that, but don’t split things up that don’t need to be split up. It really depends on what you are doing and why.

The whole system is built to be modular. Make a blueprint where a blueprint would make sense. I don’t think making 20 blueprints instead of 1 blueprint with 20 functions would be the right way to go, but I doubt it would add any amount of overhead that would affect your performance. The real problem would be that you are losing a lot what makes blueprints visual by splitting it up like that. You might as well be working in C++ at that point.

I’v tried a lot of stuff. if the system is too complicated, it will always get messy as hell.
And this is very annoying that half of the time i’m making my game i need to start messing around with how the blueprint should be built without making so much mess.

[Zeustiak]

Keeping your blueprints organized is just one of those things you have to spend time doing. If you split it up into dozens of extra blueprints, sure those messy lines go away, but you have just hidden everything under the rug. The mess is still there, but now you have even less of an idea of what is talking to what and how. Why even bother with blueprints if you are going to throw the most important part, the visual aspect, in the trash?

Without visuals, blueprint is just a slower, less flexible C++. Unless you want to learn and use C++, you have to master everything that makes organizing blueprint easier; comments, reroute nodes, collapse to function, pure functions, positioning and sequencing of nodes/sections, etc, etc.

[anonymous_user_5326e6bd]

@;185361

Keeping your blueprints organized is just one of those things you have to spend time doing. If you split it up into dozens of extra blueprints, sure those messy lines go away, but you have just hidden everything under the rug. The mess is still there, but now you have even less of an idea of what is talking to what and how. Why even bother with blueprints if you are going to throw the most important part, the visual aspect, in the trash?

Without visuals, blueprint is just a slower, less flexible C++. Unless you want to learn and use C++, you have to master everything that makes organizing blueprint easier; comments, reroute nodes, collapse to function, pure functions, positioning and sequencing of nodes/sections, etc, etc.

I would love to go C++ if the compile time was the same as unity3D, so i can actually try stuff and not losing all day trying them.

[Zeustiak]

@;185377

I would lovely to go C++ if the compile time was the same as unity3D, so i can actually try stuff and not losing all day trying them.

Are you on 4.5? I thought Hot Reload was supposed to take care of compiling?

[anonymous_user_5326e6bd]

@;185378

Are you on 4.5? I thought Hot Reload was supposed to take care of compiling?

Isn’t it like two minutes on compiling instead of blueprint’s instant compiling ?

[Zeustiak]

I can’t comment on the exact difference. Just the things I have heard about it. If I had to wait 2 minutes for every change I would be prototyping everything in blueprint before moving it into C++ which sounds like what a lot of people are doing.

[anonymous_user_5326e6bd]

@;185402

I can’t comment on the exact difference. Just the things I have heard about it. If I had to wait 2 minutes for every change I would be prototyping everything in blueprint before moving it into C++ which sounds like what a lot of people are doing.

It sounds like doing the same job twice, If you already got it good in blueprint why moving it to c++ ? when i try stuff with blueprint sometimes it gets too messy and i can’t really see what is going on so i didn’t got any good idea to go and write on it c++.

[Zeustiak]

Coming up with working systems is the hard part. Porting a working system over to C++ should be much easier than building it from scratch.

Anyway, blueprints can get messy if you let them, but it also perfectly manageable. My blueprints are incredibly complicated but I keep them neat and ordered so I can quickly understand any given piece when I come back to it. I would highly suggest making good use of the multitudes of graph organization tools that are available.

[zeOrb]

@;185382

Isn’t it like two minutes on compiling instead of blueprint’s instant compiling ?

Actually with hot reload takes from 2 seconds up to 10 seconds maximum. Usually it’s around 2-5 seconds, but, of course, it is when you modify stuff, adding new functions, variables, struct or new class. But I have not tried adding 20 new complex classes at one moment and then looking at compiling time.

[anonymous_user_5326e6bd]

@;185433

Coming up with working systems is the hard part. Porting a working system over to C++ should be much easier than building it from scratch.

Anyway, blueprints can get messy if you let them, but it also perfectly manageable. My blueprints are incredibly complicated but I keep them neat and ordered so I can quickly understand any given piece when I come back to it. I would highly suggest making good use of the multitudes of graph organization tools that are available.

I think i’m getting somewhere with organizing it. keeping it object oriented helps a lot. Thanks for the advises

@zeOrb;185435

Actually with hot reload takes from 2 seconds up to 10 seconds maximum. Usually it’s around 2-5 seconds, but, of course, it is when you modify stuff, adding new functions, variables, struct or new class. But I have not tried adding 20 new complex classes at one moment and then looking at compiling time.

Seriously ? Playing with existing functions is that fast ? Good to know i may give it a try.