|
Raenir Salazar posted:Can you elaborate on this? As I see currently understand it, this is essentially my problem in that I can't see a way of doing this, there is no way to put an Event/Delegate as a variable to just plop it down wherever. Currently it seems like "Create Event" indirectly resolves this, but it is unclear what the costs or pitfalls might be, based on googling it is essentially creating a Single Cast Delegate which we're plugging in our other Event/Delegate into, which is fine but I worry that using it indirectly as a Getter for my Event probably is completing a Demon Summoning circle somewhere. I can't because it looks like what I was thinking isn't possible with events! I booted up my personal PC here to poke it with a stick. I was thinking of the "promote to variable" option you get with a lot of outputs, but it doesn't work with events. I guess there isn't a way to save it off as a delegate like that? You can set a delegate use Set By-Ref, but I can't define a delegate variable as one of my variables manually. I feel like there's an intermediate type one could make in C++ to contain delegates of a type that could be used for this. I've had to do similar things in the past when I very specifically needed to use a primitive C++ type that wasn't exposed in Blueprint.
|
#
?
Apr 9, 2024 20:04
|
|
|
|
| # ? Apr 30, 2024 01:35 |
|
|
Unrelated, but does anyone know how to override "GetWorld" in a UObject derived Blueprint in Blueprint? I can't seem to get ride of compiler warnings using Nodes that require the "World Context Object" input even if I try to pass it UWorld from outside via a setter function. But the option to override seems to only exist for blueprints that derive from for example, Actor, but not Object. I can probably put the functionality I want in the Game Instance blueprint, but it's annoying that there apparently doesn't seem to be a good/proper case for wanting to do certain things in a regular UObject BP instead of an Actor BP, because naturally I feel like my "Manager"/Singleton objects shouldn't exist in the game world. Maybe this is what Subsystems are for? But it seems like I can't just create an arbitrary subsystem using the BP wizard? Rocko Bonaparte posted:I can't because it looks like what I was thinking isn't possible with events! I booted up my personal PC here to poke it with a stick. I was thinking of the "promote to variable" option you get with a lot of outputs, but it doesn't work with events. I guess there isn't a way to save it off as a delegate like that? You can set a delegate use Set By-Ref, but I can't define a delegate variable as one of my variables manually. Yeah as I thought; it doesn't seem like "set by-ref" is an option either because what would I be setting by ref if I can't make a variable? I think what I want isn't the intended use case for it, because when I create the node you can see the "target" pin, which is where the Event would go to, but then nothing makes sense to plug into the "Value" except another event?
|
|
#
?
Apr 9, 2024 20:59
|
|
|
...what about macros for that? I haven't really played with them yet since I haven't gotten wild enough with my Blueprints. I wonder if you can basically just put the event in a macro and reuse that block however you desire. This is coming out of my rear end though.
|
|
#
?
Apr 10, 2024 08:55
|
|
|
Rocko Bonaparte posted:...what about macros for that? I haven't really played with them yet since I haven't gotten wild enough with my Blueprints. I wonder if you can basically just put the event in a macro and reuse that block however you desire. This is coming out of my rear end though. So it turns out upon further googling you CAN pass Delegates via function parameters. So you can create a function, and then inside the function plap down your Binding (node), and take the Delegate input pin and drag it out to the Entry point node for the function and it will display a tooltip "Add pin to node" and it will add a pin of that type. I have no idea why this is apparently the only way to see this and why delegates just aren't something you can manually add, but gently caress consistency I guess? (As in if you click the + button to add a input, and then search "delegate" nothing relevant comes up; but does appear if you use the above method) And this only works inside Functions/Macros, and not the Event Graph. This is helpful and more or less works as a solution. Now we can have something like this:  Where Shutdown/Initialize are technically being used as functions for setting up the Binding/Unbinding of the Event (OnSomeEvent). For my other question about UWorld seems like a Japanese developer has a solution where you just make a bare bones C++ post which overrides GetWorld() and just reparent any UObject derived BP to the new UObject derived Object that implements GetWorld() and the compiler warnings about it being unsafe to use nodes that need the World Context Object pointer goes away. I still don't know for sure if "Create Event" is "good" but I guess I'll never know for sure and some poor Unreal Engine developer is slowly aging like I stepped on a crack on the sidewalk.
|
|
#
?
Apr 11, 2024 00:47
|
|
|
You are fighting the engine's architecture, on multiple fronts, for no discernible reason. You do not understand fundamentals like the game thread itself, the difference between synch/async actions, and the differences between very basic stuff like events vs. functions. You'll get less angry and frustrated if you watch some tutorials and/or read the documentation. Raenir Salazar posted:I still don't know for sure if "Create Event" is "good" but I guess I'll never know for sure and some poor Unreal Engine developer is slowly aging like I stepped on a crack on the sidewalk. You asked for an obscure solution to a problem that isn't common knowledge, and I provided it to you. Rethink being a dingus when you're asking for help.
|
|
#
?
Apr 11, 2024 01:41
|
|
|
For the UWorld thing, what’s your specific use case? Generally, if you’re in Blueprint land, you should be building global manager-type things as components hanging off of things that exist in the world.
|
|
#
?
Apr 11, 2024 02:46
|
|
|
Chillmatic posted:You are fighting the engine's architecture, on multiple fronts, for no discernible reason. You do not understand fundamentals like the game thread itself, the difference between synch/async actions, and the differences between very basic stuff like events vs. functions. You'll get less angry and frustrated if you watch some tutorials and/or read the documentation. I legitimately have no idea what your problem is. All I did was express confusion at your confusion at my explanation; and I very calmly and politely explained this. Raenir Salazar posted:I feel like I was pretty clear with my screenshot that I don't want the lines crossing (which they by necessity do in the screenshot) Raenir Salazar posted:I'm just going to say that this isn't helpful and people can be legitimately confused at other peoples confusion when they reasonably believe they gave all the relevant information that they thought they could give, which I legitimately believe that I did so; I can't help explain the problem any better without more specific information as to what isn't clear. Thank you for the suggestion regarding the "Create Event", hopefully it works out. At neither of these posts was I acting rudely towards you, I genuinely gave thanks despite my concerns about the solution, and my answer genuinely and politely explained that I legitimately don't understand what you're confused about, and I communicated my honest opinion that I didn't think your "good luck" reply to me was being helpful. I think the things you're saying about what I do or don't understand seems uncalled for and out of left field, I don't see how what you're saying has to do with anything. And of course, like, it's simply not true that there's "no discernible reason" as I did explain the reasons, maybe you disagree with them but I definitely explained them. Also to be clear, it's a comedy forum. Please don't take the content of some of my posts like "Unreal why!  " at face value. I hope you understand that I'm playing up to whatever extent I'm facing any issues to be more entertaining. And to be clear about your solution, which I did thank you for, I really just don't get your response here. All I did was ask reasonable follow up questions about it, I feel like its being a good developer to ask questions and want to dig into the solution and understand it more. I definitely feel like I'm allowed to have concerns about it. blastron posted:For the UWorld thing, what’s your specific use case? Generally, if you’re in Blueprint land, you should be building global manager-type things as components hanging off of things that exist in the world. So I don't think this is true, it is certainly very convenient to use Actors to access World, and I'm sure would work for most Indie projects but I don't think they're really meant to be the intended solution for things like Managers. At my previous job we had a few of those (Actor implemented Managers) and they were just absolutely painful to work with and had all sorts of issues. Based on my research it seems like maybe Subsystems might be the intended way, but I can't say more without trying them out first. But presumably and ideally I could have a "SomethingSubsystem" which has that world context, and does the things I need; but I'm not really supposed to be experimenting too much with stuff I'm not familiar with right now at my work so I picked the solution that at least I knew would work now and not require changing anything I've already implemented in Blueprint. With my solution I just had to reparent like one blueprint and my issue went away.
|
|
#
?
Apr 11, 2024 03:16
|
|
|
Subsystems are the answer to the "GetWorld" problem, and they're very easy to work with. Edit: Everything else I wrote, while still reflects my opinion, wasn't kind or helpful. My grandma had a fall today so I'm in a poo poo mood. I'm sorry. jizzy sillage fucked around with this message at 06:53 on Apr 11, 2024 |
|
#
?
Apr 11, 2024 04:54
|
|
|
jizzy sillage posted:Subsystems are the answer to the "GetWorld" problem, and they're very easy to work with. I'm sorry about your grandmother, I hope she gets better. 
|
|
#
?
Apr 11, 2024 12:13
|
|
|
Raenir Salazar posted:I'm sorry about your grandmother, I hope she gets better. She should be okay, just turned a kneecap into bone dust and broke her foot. Doc said she'd heal in 6 weeks, no expected complications. Thanks.
|
|
#
?
Apr 11, 2024 13:07
|
|
|
I think it is inevitable to get into trouble with UE5 based on all that X-instead-of-Y-instead-of-Z-instead-of-X stuff I experience in that Unreal Discord. I think it does make easy stuff easy and hard stuff possible, but the hard stuff gets really wacky. I suppose what I need to see a little is streams of advanced developers going into the muck or something.
|
|
#
?
Apr 11, 2024 15:50
|
|
|
Raenir Salazar posted:The first thing to consider is that aesthetics and making the resulting "look" of the graph pleasing by being neat and orderly matters to me; but the more substantive answer is that a messy Blueprint is hard to understand, debug, maintain, and fix any resulting issues. First, swapping the places as I suggested is much more visually appealing than the way you have it. Second, it's blueprints. It's going to look like poo poo and be hard to debug. If your task is so complicated that you can't make it look aesthetically pleasing and that's important to you, I'd suggest that's a sign you should be doing your work in C++. Blueprints are for glue code, not main systems (despite how often they're used for main systems...)
|
|
#
?
Apr 11, 2024 16:38
|
|
|
Raenir Salazar posted:So I don't think this is true, it is certainly very convenient to use Actors to access World, and I'm sure would work for most Indie projects but I don't think they're really meant to be the intended solution for things like Managers. At my previous job we had a few of those (Actor implemented Managers) and they were just absolutely painful to work with and had all sorts of issues. Again, what’s the thing you’re trying to do? Subsystems are a solution to having manager/supervisor objects, but whether they’re the best thing for your specific use case depends on your specific use case. I generally prefer components hanging off of the core game objects like the game mode/state (and sometimes instance) because they have specific lifecycles tied to the game flow and will get events like BeginPlay, whereas subsystems live outside of that flow and get different things. (Note that I’m specifically talking about components on existing objects, not sticking more actors in the level. That’s another good way to make managers, but it’s also very dependent on use case.) Rocko Bonaparte posted:I think it is inevitable to get into trouble with UE5 based on all that X-instead-of-Y-instead-of-Z-instead-of-X stuff I experience in that Unreal Discord. I think it does make easy stuff easy and hard stuff possible, but the hard stuff gets really wacky. Agreed! All of my deep knowledge has come from reading through documentation that’s hidden away as comments within the engine source and talking with my other Unreal engineer friends. For such a widely-used engine, there’s a depressing lack of comprehensive information out there on how to actually use it.
|
|
#
?
Apr 11, 2024 17:57
|
|
|
If Unreal had even a fraction of the documentation Unity does, hell even a fraction of the documentation Unity had a decade ago, I think Unity would be toast. It pretty much expects that you're working somewhere where there's people more experienced than you who can show you the right way to do things. My previous job was a Unity shop that transitioned over to Unreal (a bad business move but I did not complain about free training). I feel bad for the former Epic employee on our team who had to look at reviews and tell me over and over that I really shouldn't be using the C++ STL classes instead of TUniquePtr, TFunction, TArray, etc.
|
|
#
?
Apr 11, 2024 18:57
|
|
|
Hey thread, if you were going to start a hobbyist VR project what engine would you gravitate to? Unity and Unreal both have demo projects to start with so they seem like my best options so far. I've mucked around in both and I've found Unreal a lot easier to work in, personally, but a lot more mysterious when I'm trying to solve a specific problem (as the post above says). Is there another option I should consider as well?
|
|
#
?
Apr 11, 2024 19:05
|
|
|
Al! posted:Hey thread, if you were going to start a hobbyist VR project what engine would you gravitate to? Unity and Unreal both have demo projects to start with so they seem like my best options so far. I've mucked around in both and I've found Unreal a lot easier to work in, personally, but a lot more mysterious when I'm trying to solve a specific problem (as the post above says). Is there another option I should consider as well?
|
|
#
?
Apr 12, 2024 02:24
|
|
|
aardvaard posted:First, swapping the places as I suggested is much more visually appealing than the way you have it. Second, it's blueprints. It's going to look like poo poo and be hard to debug. If your task is so complicated that you can't make it look aesthetically pleasing and that's important to you, I'd suggest that's a sign you should be doing your work in C++. Blueprints are for glue code, not main systems (despite how often they're used for main systems...) I'm not quite sure what you mean, do you mean in the follow up image with the Create Events? Or the original image presenting the problem? If the original image, its just an example and there's going inevitably to be situations where swapping as I explained isn't practical without infringing on some other organizing principle or ultimately having some wire cross somewhere as BPs get more complex. In the follow up image its just a quick example to show the follow up, and isn't reflective of how I'd organizing it with that solution in mind, but even so perhaps there's a difference in subjective opinion regarding aesthetic tastes, in any case in either as-is situations the latter is preferable to me than the former, maybe you disagree but this is subjective and I don't think very productive to argue. And of course obviously I'd prefer to be doing my work in C++, but specifically right now I cannot; I would I assure you if I could. But in any case I'm sure it is at least a learning experience to see what the pitfalls are in case it ever shows up again during my career. Generally in my professional experience BP's show up very often for mockups or prototypes, not just merely for glue code; ideally these systems get converted to C++ where and when it is feasible but in practical situations this isn't always feasible due to various constraints. In this context it isn't unreasonable to want to make the BP's as readable and adhering to best practices as possible to better facilitate conversion to C++ (because the intentions remain clear) and facilitate their ongoing maintenance while pending that circumstance. blastron posted:Again, what’s the thing you’re trying to do? Subsystems are a solution to having manager/supervisor objects, but whether they’re the best thing for your specific use case depends on your specific use case. I generally prefer components hanging off of the core game objects like the game mode/state (and sometimes instance) because they have specific lifecycles tied to the game flow and will get events like BeginPlay, whereas subsystems live outside of that flow and get different things. In general I like to have manager classes that breakdown the game's systems into logical clean divisions of labour of the core systems. Although there might be systems that make sense as components on actors (perhaps inventory). Regarding In my specific situation where I am stuck in Blueprint Land one thing I came up against is that apparently updates to a Material parameter collection won't take effect if its done by the Game Instance during its Init event tick, but will take effect during Game Mode's Handle Starting New Player which seems to be guaranteed to run before the Begin Play events on Actors. So if I were to make a Subsystem that derived off of the GameInstance subsystem one thing I'm worried about is when exactly is it loaded relative to the other systems and objects. I think my choices are Editor, Game Instance, Engine, and Local Player? I think Local Player is unique to each player? That's not ideal. I could probably put an event in Game Mode that fires when its done and then calls whatever initialization that my subsystem needs to do before Begin Play but that's a little inoptimal. (And to be clear this is because since the BeginPlay events for Actors are non-deterministic, and it is desirable to me to be able to not need to worry about this by handling things at the moment before this) Handling the non-deterministic load order of Unreal Actors has been a struggle at my previous job so its something that's on my mind as a keen concern. So far it seems like deriving Game Mode and having it hold my managers seems best either in BP or C++ if I want something that's after Game Instance but before BeginPlay and not worry about it; otherwise I'd have to look at the Game Instance Subsystem more to see if it has any load order issues; it probably isn't very many things that need to happen after the game instance finishes loading so maybe I can just throw in an event for that if and when it comes up but it has at least one time come up so far for me.
|
|
#
?
Apr 12, 2024 16:35
|
|
|
Raenir Salazar posted:I'm not quite sure what you mean, do you mean in the follow up image with the Create Events? Or the original image presenting the problem? If the original image, its just an example and there's going inevitably to be situations where swapping as I explained isn't practical without infringing on some other organizing principle or ultimately having some wire cross somewhere as BPs get more complex. In the follow up image its just a quick example to show the follow up, and isn't reflective of how I'd organizing it with that solution in mind, but even so perhaps there's a difference in subjective opinion regarding aesthetic tastes, in any case in either as-is situations the latter is preferable to me than the former, maybe you disagree but this is subjective and I don't think very productive to argue. Respectfully, I think your whole mindset here is holding back your project.
|
|
#
?
Apr 12, 2024 17:33
|
|
|
aardvaard posted:Respectfully, I think your whole mindset here is holding back your project. I don't think its very respectful to ignore the clear explanations, context, and constraints, and to then vaguely claim that the problem is my mindset when I say that your suggestion doesn't resolve my issue.
|
|
#
?
Apr 12, 2024 18:01
|
|
|
I just don't think it's a good frame of mind to make structural decisions about your project based on fairly minor aesthetic concerns.
|
|
#
?
Apr 12, 2024 18:33
|
|
|
thank you! ive seen people talking about godot and i really like how this documentation is written
|
|
#
?
Apr 12, 2024 18:38
|
|
|
aardvaard posted:I just don't think it's a good frame of mind to make structural decisions about your project based on fairly minor aesthetic concerns. I don't see these structural decisions you speak of? What are you talking about?
|
|
#
?
Apr 12, 2024 18:59
|
|
|
aardvaard posted:I just don't think it's a good frame of mind to make structural decisions about your project based on fairly minor aesthetic concerns. It's just very advanced procrastination. I had to start attempting game jams again to break the same lovely spiral I was stuck in, which I feel is a symptom of burnout.
|
|
#
?
Apr 12, 2024 19:44
|
|
|
Ranzear posted:It's just very advanced procrastination. I had to start attempting game jams again to break the same lovely spiral I was stuck in, which I feel is a symptom of burnout. To be clear, that's not what's actually happening here as being able to store a delegate as a variable, or at least pass a delegate to a function in Blueprint is a useful thing to know.
|
|
#
?
Apr 12, 2024 19:53
|
|
|
Raenir Salazar posted:To be clear, that's not what's actually happening here as being able to store a delegate as a variable, or at least pass a delegate to a function in Blueprint is a useful thing to know. If multiple people are basically replying with "that doesn't sound like something I've run into before"/"what are you actually trying to do because this doesn't sound like the right approach", then it is not a useful thing to know; it is something that seems like a useful thing to know ..if you're trying to apply knowledge/approaches from a different engine/framework/language to one where it doesn't apply. It's really hard to get out of the "I know what I'm trying to do, I don't understand why people don't see why it's the right approach/an actual problem to solve" hole until you step back all the way to the actual problem you're solving (which in this case sounds like a combination of "I'm trying to keep X and Y in blueprint when it should ideally be in C++" and "I want my blueprint to look 'clean' like I'd want my C++ to be clean") and not the adjacent problems you're stuck on ("how do I get references to an event to be saved like in a variable" and "how do I avoid duplication/lines crossing/blueprint code becoming a spaghetti mess"). And yes even when internally it sounds like you've gone to the actual problem, it doesn't look like you have if people keep reacting with the same "but what are you actually trying to achieve" questions. The back and forth literally reads like every time I've helped someone moving from Unity to Unreal and had to repeatedly play the XY problem game as soon as they hit one of the big differences, like the most common being UI and how in Unreal you set up 'pull' code vs. Unity you push data from code instead. Yes technically you could write your Unreal UI code to work like Unity's UI code, and it will always look ugly as hell and ridiculously over-complicated, because you're fighting the actual system you're working in every step of the way. Neither approach is "the right one", it's not changing your normal approach to match the system ("how do I save a reference to the event" => "how do I tell the label to change its text"), it's realising that you have to learn a completely new approach ("how do people keep their blueprint code clean when they need to add complex logic like X" => "how do people get labels with dynamic text"). e: ^ all that being said, anecdotally yes Unreal does seem to cause this way more...primarily with the blueprint code split and the lack of people sharing actual advanced practical usage; I've seen so many working examples of how people using Unity solved actual problems they ran into while working with it, whereas with Unreal it tends to mostly be guides/documentation that solve standard problems. Unity's slowly going the same way though with newer versions/features, so yeah. Red Mike fucked around with this message at 21:41 on Apr 12, 2024 |
|
#
?
Apr 12, 2024 21:37
|
|
|
Red Mike posted:blueprint code becoming a spaghetti mess I have a weirdly personal vendetta against this line of thinking, mostly because in all honesty I love Blueprint. The last big studio I was at switched to UE for their current project, and I was the "Blueprint Person" that engineering would ask questions to when they didn't want to dig around in source. It's one of my favorite scripting languages, and it drives me crazy when people think it has to look like poo poo or be impossible to reason about. In eight years I don't think it's ever failed, when someone's blueprints look like this, they inevitably complain that cpp would make this all so much "Cleaner" and "More elegant", and when I look at their typed code it's the exact same kind of nonsense but this time in text form and even more impossible to understand.  Basically I think Blueprint bothers people because it doesn't give bad programming practices any place to hide; it makes spaghetti actually look like spaghetti. It is perfectly possible to make an entire game using it, and the only valid criticism I've seen about the format is that version control and merging is indeed a nightmare. That's a good enough reason on its own to minimize their use if that's an issue on larger teams. But messy blueprints are an unforced error on the part of the user, not an inevitable end result.
|
|
#
?
Apr 12, 2024 23:16
|
|
|
My only complaint with node based editors is I've been using a keyboard as my primary interface for decades, and moving to something mouse based feels really slow. It's better for exploring an api or for touch interfaces but scrolling around with a mouse and dragging lines around just feels kinda clunky. Some node editors have really slick keyboard hot keys and I appreciate that. It tends to feel like a secondary concern though. I'll 100% agree that code gets just as unintelligible as nodes in bad hands, neither has any advantage there.
|
|
#
?
Apr 12, 2024 23:26
|
|
|
Specifically, I don't think wires crossing wires is blueprint code smell, as long as you can still trace the connections. Adding nodes to your wires helps a lot with this. One important thing to learn is that a beautiful blueprint isn't necessarily more maintainable than an ugly one. Getting caught up in keeping everything aligned, making all the wires straight, is a fun bit of yak shaving but not necessarily productive. The important thing is that, like code, it's readable. A beautiful blueprint that takes me twenty minutes to decipher is not better than a straightforward ugly one.
|
|
#
?
Apr 12, 2024 23:34
|
|
|
xzzy posted:My only complaint with node based editors is I've been using a keyboard as my primary interface for decades, and moving to something mouse based feels really slow. I totally get that, yeah. The UE team could do a lot more to improve on this but stupidly it doesn't seem to be a priority. aardvaard posted:Specifically, I don't think wires crossing wires is blueprint code smell, as long as you can still trace the connections. Adding nodes to your wires helps a lot with this. Definitely. There are also a lot of other tips and tricks like: rather than dragging lines from function inputs/arguments all the way over to whatever they connect to, using the built in local variables that UE creates automatically for you, that way you can connect them right next to where they go. You can also press Q to automatically straighten a line of nodes, as well as alt-shift-S to align vertically. quote:One important thing to learn is that a beautiful blueprint isn't necessarily more maintainable than an ugly one. Getting caught up in keeping everything aligned, making all the wires straight, is a fun bit of yak shaving but not necessarily productive. The important thing is that, like code, it's readable. A beautiful blueprint that takes me twenty minutes to decipher is not better than a straightforward ugly one. Completely agree, except to say that all of this applies to typed code as well. Like man I have known some engineers who will kill themselves to create beautifully indented code with comment sections that border on ASCII art, and inevitably their poo poo is still really difficult to reason about. When I say "messy", I mean less about aesthetics and more about programming smells in general. Chillmatic fucked around with this message at 23:52 on Apr 12, 2024 |
|
#
?
Apr 12, 2024 23:46
|
|
|
Chillmatic posted:Completely agree, except to say that all of this applies to typed code as well. Like man I have known some engineers who will kill themselves to create beautifully indented code with comment sections that border on ASCII art, and inevitably their poo poo is still really difficult to reason about. When I say "messy", I mean less about aesthetics and more about programming smells in general. Absolutely. I think for code the war is slowly being won on that front - I've never worked at a place where that's been allowed by the style guide. But even though I hate it in code, when I look over at a blueprint some obsessive part of my brain takes over and wants it to look neat and tidy.
|
|
#
?
Apr 13, 2024 00:33
|
|
|
I don't really recall the conversation going that way but perhaps we'll just have to agree to disagree in that respect. But anyways, insofar as I think you're suggesting that the issue is I don't have the right perspective or I'm not realizing that I should reconsider my approach regarding the system that I'm using; I think the fact there isn't anything that suggests I'm not already well aware of this. The issue definitely isn't not having the right perspective in considering my approach, because that approach isn't actually in my hands. As I already explained that this is for work, I am currently stuck using Blueprints in this way for work reasons; I've already said I would be using a C++ instead if I could; but I also don't see it as approaching Blueprint as I would C++, I think I am approaching them in very different ways and the only ways that could come across as similar is pulling from my experiences regarding concepts and ideas that are definitely language/platform/system agnostic and clearly would be adapted differently to accomplish the idea behind it to suit the system/language/engine in question. For Blueprints I just don't like the lines crossing, that is my personal preference, I go on to attempt to justify it because I also think it would result in more clear to understand Blueprint code since my primary use case didn't seem to be a satisfactory (like the video game) explanation, that isn't really a C++ Clean Code thing that I'm misappropriating for Unreal Blueprints. The BP vs C++ thing is mainly coming from the perspective that it would be easier for me to do the various things I'd like to do in C++, specifically having delegates as variables or manager classes, which I agreed with, but I currently can't for this specific project/task for the time being. aardvaard posted:Specifically, I don't think wires crossing wires is blueprint code smell, as long as you can still trace the connections. Adding nodes to your wires helps a lot with this. I agree that just a couple of wires cross isn't "code smell", but I think mileage may vary about to what extent an ugly blueprint can be straight forward depending on the person. I just think that the threshold is going to be different for me than for you, and wouldn't be surprised if this also applied to others.
|
|
#
?
Apr 13, 2024 01:06
|
|
|
Chillmatic posted:Completely agree, except to say that all of this applies to typed code as well. Like man I have known some engineers who will kill themselves to create beautifully indented code with comment sections that border on ASCII art, and inevitably their poo poo is still really difficult to reason about. When I say "messy", I mean less about aesthetics and more about programming smells in general. Today's example, a piece of code that's used for quickly resolving "the longest prefix contained in a trie that matches the input string". Someone on my team was having a problem using it, and found it was a bug, it was actually resolving "the longest prefix contained in a trie that matches the input string and doesn't have a partial match on a longer prefix in which case it will instead return null", e.g. if the prefixes are "foo" and "foobar" and you give it "foob", it would not return "foo", versus if the prefixes are "foo" and "bar" and you give it foob, it *would* return "foo". So he was fixing that and I gave it a first review and I noticed the function was taking the target string as a char* and assuming it's null terminated. This is in a C++ context where e.g. string_view is available and widely used, and I checked all the call-sites and they were actually strings and c_str was being called on them to make it compatible with this loving function, so it's literally adding unnecessary code at the call-sites and potentially performance worsening, and doing it that way leads to the code being like code:code:Also the code had a potential null pointer dereference if the contents of the trie and the key were aligned in a particular way. Which is to say, it: 1. didn't work as intended. 2. could crash in production with valid data. 3. was filthy. But it had full coverage unit tests and was formatted in the required style and didn't have any portmanteaus in the comments, so it's lucky there was all those things!
|
|
#
?
Apr 13, 2024 04:27
|
|
|
Chillmatic posted:I have a weirdly personal vendetta against this line of thinking, mostly because in all honesty I love Blueprint. The last big studio I was at switched to UE for their current project, and I was the "Blueprint Person" that engineering would ask questions to when they didn't want to dig around in source. It's one of my favorite scripting languages, and it drives me crazy when people think it has to look like poo poo or be impossible to reason about. I pretty much agree, I just think there is a point at which generally blueprint spaghetti is much harder to read through than C++ spaghetti solely because of how the C++ spaghetti has enough tooling/IDE stuff around it to keep it sensible. And I don't think you can avoid "spaghetti" in this sense completely in a real project, some code just is a complicated mess and keeping it "clean" just means you have to do even more work the next time you need to change it. So I tend to prefer to keep the spaghetti parts wherever they're easier to read. Raenir Salazar posted:I am currently stuck using Blueprints in this way for work reasons; I've already said I would be using a C++ instead if I could; but I also don't see it as approaching Blueprint as I would C++, I think I am approaching them in very different ways and the only ways that could come across as similar is pulling from my experiences regarding concepts and ideas that are definitely language/platform/system agnostic and clearly would be adapted differently to accomplish the idea behind it to suit the system/language/engine in question. This is exactly what I'm raising: you're still assuming that these concepts are agnostic and therefore apply to every language/platform/system, and yet you're describing things that people haven't generally needed to do in this system (because in this system, there's a better/different pattern/approach that means those concepts aren't necessary). If you stop trying to pull from those experience, look at what you're really trying to achieve and ask how someone experienced in the system would achieve that, you'll likely get a different answer. A simpler example of what I mean: the idea of a plain CS linked list is language/platform/system agnostic, but if you kept asking how to create one properly in Javascript then you'd keep getting reactions like "what are you trying to do?" and "huh I've never really had to do this myself". If you instead asked how you'd store elements in a way you can iterate over them in Javascript, you'd be told to use the built-in arrays/objects and that's why people didn't really need to solve the problems you're having.
|
|
#
?
Apr 13, 2024 08:33
|
|
|
Red Mike posted:This is exactly what I'm raising: you're still assuming that these concepts are agnostic and therefore apply to every language/platform/system, and yet you're describing things that people haven't generally needed to do in this system (because in this system, there's a better/different pattern/approach that means those concepts aren't necessary). If you stop trying to pull from those experience, look at what you're really trying to achieve and ask how someone experienced in the system would achieve that, you'll likely get a different answer. The point you're raising is that you've decided I meant something else from what I meant? I don't see how it makes sense for you to decide I somehow only meant the concepts you can trivially point to in order to support your point about me. I don't think you know which concepts I was referring to, would you agree that there are some concepts in the universal set of CS concepts that would be widely applicable to some game engines and programming languages in gamedev? While of course, accounting that these concepts might be applied differently, which I've already said. Or are you saying that there is no single concept that would apply to both Unreal and Unity3D? Not a single one? e to add: It kinda just sounds to me like you maybe have certain notions about what makes a good programmer and that maybe I don't fit your particular mental mold of what that looks like, but I also don't feel comfortable with the fact that I feel like I'm being forced to defend myself for things I didn't say or do, and is coming across as very uncomfortable and personal and if you want to have a discussion about different approaches I'd like you to drop this being about me. Raenir Salazar fucked around with this message at 16:50 on Apr 13, 2024 |
|
#
?
Apr 13, 2024 16:31
|
|
|
Raenir Salazar posted:The point you're raising is that you've decided I meant something else from what I meant? I don't see how it makes sense for you to decide I somehow only meant the concepts you can trivially point to in order to support your point about me. I don't think you know which concepts I was referring to, would you agree that there are some concepts in the universal set of CS concepts that would be widely applicable to some game engines and programming languages in gamedev? While of course, accounting that these concepts might be applied differently, which I've already said. Or are you saying that there is no single concept that would apply to both Unreal and Unity3D? Not a single one? Sorry, I must have come across really aggressive but I definitely didn't mean it that way! I don't think any of this relates in any way to what makes a good programmer or anything like that, I think this sort of situation is one anyone can run into and generally I think more experienced programmers actually have more trouble with, because basically the deeper/more well-used your toolbox the less likely you are to think that a thing that looks like a screw/nail/etc doesn't actually need a screwdriver/hammer/etc. It's entirely possible I'm misreading what you're describing and you are in fact looking for something commonly done in Unreal, in which case maybe someone can actually help with it. But from my past experience it sounds a lot like the situation I'm describing, so I was only trying to help. When you replied with an explanation and it sounded to me even more like the situation I'm describing, I tried clarifying what I meant more in case it helped. If that still doesn't help, then yeah maybe I'm wrong. Either way sorry I definitely didn't mean it in any personal way or an attacking way, I was just trying to explain a situation I've seen/run into before and the problem/solution from my perspective.
|
|
#
?
Apr 13, 2024 17:49
|
|
|
Red Mike posted:Sorry, I must have come across really aggressive but I definitely didn't mean it that way! I don't think any of this relates in any way to what makes a good programmer or anything like that, I think this sort of situation is one anyone can run into and generally I think more experienced programmers actually have more trouble with, because basically the deeper/more well-used your toolbox the less likely you are to think that a thing that looks like a screw/nail/etc doesn't actually need a screwdriver/hammer/etc. Thanks, I appreciate you being willing to take a step back here; and for the record I've already went with the suggestion that was offered earlier in the thread and completed the task I was working on. I definitely get and understand the urge to want to try to helpful, and I'm sure it would be helpful in the right context, but I definitely I assure you understand the importance of flexibility when it comes to problem solving especially from moving between languages and frameworks. I picked the job offer I had from my previous Unreal job specifically because it was a job working full time with Unreal engine and was a learning experience regardless of of my previous inexperience with the Engine (I was a Unity3D hobbyist & a government/Defence C/C++ Cybersecurity software systems engineer prior to being hired) and got to learn Unreal & Unreal C++ for three years professionally which has helped open up further job opportunities for me after the recent industry wide layoffs.  So I think I'm keenly aware of the importance of being flexible, and everyone with any amount of expertese in anything should be wary of when the person they want to excitedly share information with might already be aware. 
|
|
#
?
Apr 13, 2024 19:55
|
|
|
Stop being an insufferable rear end in a top hat, and instead show appreciation for those willing to spend the time to answer your requests for help.
|
|
#
?
Apr 13, 2024 23:00
|
|
|
Chillmatic posted:Stop being an insufferable rear end in a top hat, and instead show appreciation for those willing to spend the time to answer your requests for help. Edit: vvvvv this was a very wise edit, well done. roomforthetuna fucked around with this message at 00:00 on Apr 14, 2024 |
|
#
?
Apr 13, 2024 23:22
|
|
|
E because it's really not worth it. The conversation already ended and resolved itself.
Raenir Salazar fucked around with this message at 23:59 on Apr 13, 2024 |
|
#
?
Apr 13, 2024 23:27
|
|
|
|
| # ? Apr 30, 2024 01:35 |
|
|
Al! posted:Hey thread, if you were going to start a hobbyist VR project what engine would you gravitate to? Unity and Unreal both have demo projects to start with so they seem like my best options so far. I've mucked around in both and I've found Unreal a lot easier to work in, personally, but a lot more mysterious when I'm trying to solve a specific problem (as the post above says). Is there another option I should consider as well? What with all the stuff Unity's been up to lately I wouldn't at all blame you for wanting to start in Unreal or Godot, but Unity is a lot more straightforward to set out in. Meta's newest update to the Oculus integration with the 'building blocks' makes getting a project going completely trivial (you could go from 0 to a demo scene where you can throw a ball in probably 5 minutes), and there's a wealth of tutorials and communities for it in a way my impression is there just aren't for Unreal. I don't use Unreal but when I look through the e.g. Oculus docs the Unity section is massively more fleshed out, although Meta's announced they're putting more support into Unreal going forward. I'm just sort of assuming you're using a Quest here, but even though other devices won't be so straightforward, the basic sentiment holds. If Unreal has particular appeal I wouldn't say don't go for it; unless you're developing for Vision Pro you can do all the same things, but there'll be less information to draw on. Anyway despite what I just said, have people here got much experience jumping to Unreal from Unity? I've been using Unity for 5 years and in a professional context (mostly VR exhibition work) for the past couple, but like a lot of people have been kind of mulling over making the effort to switch for the past couple of years. Most of my work is non-PBR and heavily art focused so aside from the part where I'd need to learn C++, seeing Unreal generally be focused on PBR is my big concern. Anyone have experience with stylized projects/Unreal shaders? How does it compare?
|
|
#
?
Apr 14, 2024 18:47
|
|
