Announcement

Collapse
No announcement yet.

Unreal Engine Livestream - Applying programming concepts to Blueprints - May 9 - Live from HQ

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    [LIVESTREAM] Unreal Engine Livestream - Applying programming concepts to Blueprints - May 9 - Live from HQ

    Click image for larger version  Name:	ApplyingprogrammingconceptstoBlueprints.jpg Views:	1 Size:	520.1 KB ID:	1616577


    WHAT
    Blueprints has unlocked the power of programming to designers and artists the world over. As you learn to use Blueprints and create more complex systems, you can run into some common challenges. During this week's stream, Tom Shannon and Victor Brodin will demonstrate how using concepts such as inheritance and base classes unlocks the true potential of Blueprints.

    WHEN
    Thursday, May 9 @ 2:00PM ET - Countdown

    WHERE
    Twitch
    Youtube

    RESOURCES
    Blueprints Visual Scripting | Documentation
    Blueprint Communications | Live Training

    WHO
    Tom Shannon - Technical Artist - @TomShannon3D
    Victor Brodin - Community Manager - @victor1erp


    NEWS
    Microsoft Build: Epic Games Recreates the Apollo 11 Mission for HoloLens 2 with Unreal Engine 4
    https://www.unrealengine.com/en-US/b...nreal-engine-4

    Developer Tigerton’s Jupiter & Mars is leading the way for “Games that Inspire Change”
    https://www.unrealengine.com/en-US/d...inspire-change

    Virtual production: Stargate Studios creates final pixels on set
    https://www.unrealengine.com/en-US/s...-pixels-on-set

    Brief Battles is a cheeky party game brought to life with Unreal Engine 4
    https://www.unrealengine.com/en-US/d...nreal-engine-4

    COMMUNITY SPOTLIGHT

    Midknight Story
    https://www.kickstarter.com/projects...idknight-story

    Kin - Game Jam trailer
    https://www.artstation.com/artwork/Ya44Lb

    The Copper Canyon Shoot Out
    https://forums.unrealengine.com/comm...ojects/1613749

    ARCHIVE


    Have questions for the stream? Ask them here!
    Last edited by VictorLerp; 05-17-2019, 11:44 AM.

    #2
    Will the recording be available? My timezone is not convenient for watching this event live.

    Comment


      #3
      megafanat they always save them on youtube: https://www.youtube.com/user/UnrealD...mentKit/videos

      I'm hyped for this stream, sounds like it'll be good for beginners.

      Comment


        #4
        Thanks for this, I gotta work but I will be catching this later, I really want to sink my teeth deeper into blueprint.

        Comment


          #5
          Base-Parent vs Child-BP corruption bugs: A lot of work has been done on making this area more stable... So cheers for that... But occasionally I still see 2 issues happening that are hard to repro:

          1. Making minor changes to the parent / root BP causes some child BP's to register being dirty and needing to be re-saved. But its rarely the same ones all of the time, and never all of them, unless a significant change is made to the parent obviously. Is there any reasoning / logic behind this?

          2. Specifically related to the 'Child Blueprints Get Their Variables Reset' bug above. Changes to default values of some variables in the parent don't always propagate down to Child BP's. For example, a handful of child spaceships out of a pool of hundreds etc. Using 'promote to variable' in the Parent may be a trigger here, not sure... But related to the first point, the child classes that 'didn't require saving' had the correctly inherited value. Now why would that be?
          Last edited by ClavosTech; 05-09-2019, 12:49 PM.

          Comment


            #6
            Originally posted by ClavosTech View Post
            1. Making minor changes to the parent / root BP causes some child BP's to register being dirty and needing to be re-saved. But its rarely the same ones all of the time, and never all of them, unless a significant change is made to the parent obviously. Is there any reasoning / logic behind this?
            At a high level the most important distinction is between loaded assets and unloaded assets. When a blueprint is loaded we will not automatically load its child types, but we will automatically load every blueprint that said blueprint references and that may include some or all of its child blueprints. For example, if a blueprint has a cast node in it then when said blueprint is loaded the type of blueprint in the cast will also be loaded. The loaded set of blueprints also tends to only grow - the editor does not typically unload assets. That means if you open a map that references all your child types then they will all be loaded.

            With an understanding of the load set we can now begin to dissect what happens when we make a change. Here's a specific example: removing a component from an actor blueprint.

            1. Operation begins in SSCSEditor::OnDeleteNodes and results in expected mutation of object graph in the asset that you're editing
            2. Later in SSCSEditor::RemoveComponentNode we get all loaded child blueprints and also remove the copy of the component in them - this is done because otherwise loaded children would still have the copy of the component they instantiated.
            3. Much later, if some other child is loaded we remove their deleted inherited components in a special postload step

            I'm walking a line here between specifics and simplicity, so feel free to ask for further details.

            Originally posted by ClavosTech View Post
            2. Specifically related to the 'Child Blueprints Get Their Variables Reset' bug above. Changes to default values of some variables in the parent don't always propagate down to Child BP's. For example, a handful of child spaceships out of a pool of hundreds etc. Using 'promote to variable' in the Parent may be a trigger here, not sure... But related to the first point, the child classes that 'didn't require saving' had the correctly inherited value. Now why would that be?
            In this case it seems likely that the ones that 'didn't require saving' were correct because they were not loaded, but it's also possible something went deeply wrong in property propagation logic.

            This complexity means that what assets are loaded is often very critical to finding a repro for a bug. In the long term we hope to further simplify the loading code so I'm confident that we will trend towards greater stability, but that's no reason not to fix issues for which we've nailed down a repro. Keep your eyes peeled.

            Comment


              #7
              Dan.OConnor nor
              Originally posted by Dan.OConnor View Post
              I'm walking a line here between specifics and simplicity, so feel free to ask for further details.
              Thanks Dan!

              Keeping things practical for a sec regarding cross-checking 'default values' between parent / child etc....... Using the Blueprint Tools (Diff etc), is there a way to run an automated check to see if any Child BP variable mismatches the Parent? For example, when a child BP's variable values are overridden manually, is there a hidden-bit or flag-set on that variable to mark that its dirty? If so, could that be used to warn developers: "Hey this Child-BP' has a different value from its parent, but its bit-flag isn't set so the value is questionable.... Or the value of Child-BP object variable 'default weapon' is 'none' which mismatches the Parent which has a valid object etc'???

              If there's no way to do this right now, is there anything coming down the line. On reddit recently Tim Sweeney posted about scripting language support coming to UE4. Will that mean Blueprints get a text-based interchangeable format at some point too? Something that might allow for more flexible or clever diffing during the auditing process to route out corruption etc. If not and Blueprints remain binary for the foreseeable future, is there any discussion about adding file-system like integrity-checking or zip-rar archive-consistency checking to Blueprints to look for corruption or other problems etc?


              Originally posted by Dan.OConnor View Post
              In this case it seems likely that the ones that 'didn't require saving' were correct because they were not loaded, but it's also possible something went deeply wrong in property propagation logic. This complexity means that what assets are loaded is often very critical to finding a repro for a bug. In the long term we hope to further simplify the loading code so I'm confident that we will trend towards greater stability, but that's no reason not to fix issues for which we've nailed down a repro. Keep your eyes peeled.
              Interesting... This helps explain a lot. I normally work on the parent but I can't rule out Gamemode etc referring to a Child-BP (especially in disconnected or de-activated code etc). I'll keep eyes peeled now that I know what to look for... Cheers
              Last edited by ClavosTech; 05-10-2019, 01:23 PM.

              Comment


                #8
                Originally posted by ClavosTech View Post
                Using the Blueprint Tools (Diff etc), is there a way to run an automated check to see if any Child BP variable mismatches the Parent?
                You could write a routine to find them, but there is no way to distinguish between legitimate user changed values and values that have been unintentionally stomped or failed to propagate.

                Originally posted by ClavosTech View Post
                Will that mean Blueprints get a text-based interchangeable format at some point too?
                Work on a text format for uassets is ongoing. You can enable the experimental support (TextAssetFormatSupport in experimental settings) and then right click on a blueprint and select export to text asset (don't recall the exact phrasing). Your .uasset will become a .utextasset and you'll be able to open it in notepad or whatever text editor you use. You'll see significant amounts of binary data that has simply been converted to base64, but other parts of your blueprint will be quite comprehensible.

                We hope to begin using text assets internally in production (rather than in engine test environments) very soon. Just to emphasize: at this time I would not recommend exporting all your blueprints to text assets and working that way - you would be the first person in the world to do so and would likely find some pretty rough bugs! It is a useful tool to audit the editor, though!
                Last edited by Dan.OConnor; 05-10-2019, 04:21 PM.

                Comment

                Working...
                X