Announcement

Collapse
No announcement yet.

Unreal Engine 4.6 Released!

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

    #91
    Originally posted by Hourences View Post
    We already had this problem with C++ variables, and this BP change only makes things worse rather than fixing it.
    It sounds like you are using the wrong settings when specifying your UPROPERTY.

    UPROPERTY(EditAnywhere, BlueprintReadWrite ....) is going to let anyone access this property anywhere.

    But you can specify EditDefaultsOnly and then it can only be modified in the blueprint defaults and there are a number of different permutations. See https://docs.unrealengine.com/latest...ers/index.html for more degtails.

    Comment


      #92
      Originally posted by prcn3dlight View Post
      Is there Any tutorial about how to integrate SQLite ?
      I tried to include the header files "SQLiteDatabaseConnection.h" to use the db connection class, But the error occurred and "SQLiteSupportPrivatePCH.h" cannot be found. I downloaded 4.6 by Launcher and did not build it from the source.
      Here's a little writeup I put together on the Answerhub, short answer is you'll need a source build for now in order to integrate a few fixes I made after 4.6 was branched :
      https://answers.unrealengine.com/que...tesupport.html

      Comment


        #93
        Originally posted by twiddle View Post
        Here's a little writeup I put together on the Answerhub, short answer is you'll need a source build for now in order to integrate a few fixes I made after 4.6 was branched :
        https://answers.unrealengine.com/que...tesupport.html
        Thank you so much!!!

        Comment


          #94
          I've had the demo record feature crash as well. I was beginning to think that I was the only one who had this issue. Perhaps it only works in a compiled game and not in the editor yet.

          Comment


            #95
            BTW, did anybody else notice that the sign used to demonstrate the new emissive lights changes in 4.6 is the sign from the old Samaritan demo? Could it be that the Samaritan demo is coming to UE4?

            Comment


              #96
              did the experimental cylinder projection make it into the release? How do I get this working?
              I dug up some basic information on it:

              * put this to 1 to enable the feature, 0 to deactivate, in between numbers are used as transition
              r.Upscale.Cylinder

              * useful to render with super sampling (>100, e.g. 150)
              r.ScreenPercentage

              * useful to see the feature (or ScreenPercentage) in editor:
              r.ScreenPercentage.Editor

              Comment


                #97
                What are the limitations of using shared samples? I heard the format must be the same for all textures, but do all the textures need to be the same size?
                There are no limitations on the textures used with shared samplers. it just causes the wrap mode on the UTexture used to be ignored, instead it that TextureSample is forced to use the wrap mode that comes from the shared sampler.

                Comment


                  #98
                  Originally posted by getnamo View Post
                  After taking a look at the engine source for 4.6 input mapping, I noticed FSlateApplication::Get().ProcessKeyDownEvent(KeyEvent); and FSlateApplication::Get().ProcessAnalogInputEvent(AnalogInputEvent); are exposed, so using something like

                  Code:
                  bool EmitKeyDownEventForKey(FKey key, int32 user, bool repeat)
                  {
                  	FKeyEvent KeyEvent(key, FSlateApplication::Get().GetModifierKeys(), user, repeat, 0, 0);
                  	return FSlateApplication::Get().ProcessKeyDownEvent(KeyEvent);
                  }
                  Would approximate FSlateApplication::OnControllerButtonPressed(FKey, int32, bool);

                  Except that using KeyEvent() causes FKeyEvent::ToText(void)const implementation to be required in your implementation file, e.g.

                  Code:
                  FText FKeyEvent::ToText() const
                  {
                  	return NSLOCTEXT("Joystick Plugin Events", "Key", "Text");
                  }
                  which you cannot add because doing so causes error C4273: 'FKeyEvent::ToText' : inconsistent dll linkage.

                  Any guidance on adding custom input mapping in 4.6 epic? or has this been broken without an engine patch?

                  Edit:
                  I guess you can suppress the warning with #pragma warning( disable:4273 ) but this feels hacky, still would like to know the proper way to achieve this
                  The following code suggested here is absolutely how you would generate input and is the correct way to do it now.
                  Code:
                  bool EmitKeyDownEventForKey(FKey key, int32 user, bool repeat)
                  {
                  	FKeyEvent KeyEvent(key, FSlateApplication::Get().GetModifierKeys(), user, repeat, 0, 0);
                  	return FSlateApplication::Get().ProcessKeyDownEvent(KeyEvent);
                  }
                  I'm unclear why you implemented FKeyEvent::ToText()?
                  This certainly is the cause of the inconsistent dll linkage error.
                  Is there another warning or error that has lead you to implementing this function?

                  Ensuring we sort out this issue is a high priority to us, I appreciate the report and information.

                  Comment


                    #99
                    It appears that BlueprintImplementableEvents are not showing up in Blueprints since 4.6

                    https://answers.unrealengine.com/que...in-editor.html

                    Help on this would be nice, thanks!

                    Comment


                      Originally posted by Hourences View Post
                      Is there any reason for this change? Because it is a pretty bad change.

                      We already had this problem with C++ variables, and this BP change only makes things worse rather than fixing it.

                      Consider this case for example, which has been happening to us on multiple large productions:



                      This is a BP placed in a level. Everything except for the green marked properties should not be visible, but it is, because all those properties came in from the C++ base class. The green properties internally control everything, so the end user is only expected to change those green properties. They are faced however with a long list of very confusing properties, most of which they cannot change or it will break things/not work.

                      We have had it happen before that people start editing stuff they are not suppose to, because it is not clear what they should and should not change. And that was a problem already with C++ based classes, but now that BP enforces you to do the same thing this problem just got worse.

                      Speaking of which, what we also don't have is the ability to make grayed out properties in BP, and information boxes. I want to be able to display info (text/values) in the properties to the end user. For example if I have a text field, I want to be able to display somewhere "text field length is currently 65 characters" to ensure there is feedback to the end user as to how he is doing char limit wise (or for whatever other reason).
                      Seconded. Just because I want something to be accessible from other blueprints doesn't mean I want it to be accessible to the level designer or cluttering up my actor properties. Why'd someone think this was a good idea?
                      Impromptu Games|dev blog|twitter|itch.io store|Patreon
                      Impromptu Procedural Ladders|Impromptu Procedural Handrails|Impromptu Procedural Stairs
                      |Impromptu Fire Propagation|InFlux Example Game|Impromptu Vector Field Painter

                      Comment


                        Originally posted by Chris Gagnon View Post
                        The following code suggested here is absolutely how you would generate input and is the correct way to do it now.
                        Code:
                        bool EmitKeyDownEventForKey(FKey key, int32 user, bool repeat)
                        {
                        	FKeyEvent KeyEvent(key, FSlateApplication::Get().GetModifierKeys(), user, repeat, 0, 0);
                        	return FSlateApplication::Get().ProcessKeyDownEvent(KeyEvent);
                        }
                        I'm unclear why you implemented FKeyEvent::ToText()?
                        This certainly is the cause of the inconsistent dll linkage error.
                        Is there another warning or error that has lead you to implementing this function?

                        Ensuring we sort out this issue is a high priority to us, I appreciate the report and information.
                        Hey Chris, I have a question for you. How do you go about providing the actual value for let's say a given axis? Before I could pass the normalized value from -1 to 1 with FSlateApplication::Get().OnControllerAnalog(...) but I haven't found where to store that yet. If you could let me know where I can specify the current axis value, that'd be great, thanks.

                        EDIT: I found it, no worries... FAnalogInputEvent

                        UPDATE: If anyone wants the modification for analog events, here you go...

                        bool EmitAnalogEventForKey(FKey key, int32 user, bool repeat, float value)
                        {
                        FAnalogInputEvent AnalogEvent(key, FSlateApplication::Get().GetModifierKeys(), user, repeat, 0, 0, value);
                        return FSlateApplication::Get().ProcessAnalogInputEvent(AnalogEvent);
                        }
                        Yup, I'm suffering from the same issue Chris...
                        Error 3 error LNK2001: unresolved external symbol "public: virtual class FText __cdecl FKeyEvent::ToText(void)const " (?ToText@FKeyEvent@@UEBA?AVFText@@XZ) D:\Unreal Engine 4\Projects\Prototype\Intermediate\ProjectFiles\JoystickDevice.cpp.obj Prototype
                        I was getting them for FKeyEvent, FInputEvent, and FAnalogInputEvent. I looked at the engine code and clearly if you look at Events.cpp, all of the ToText(...) overrides have been implemented and I noticed it doesn't fail to compile on Debug, only on Release. If I get a chance, I'll try to debug it further. Hope this helps.
                        Last edited by MC Stryker; 12-09-2014, 05:11 AM.

                        Comment


                          Regarding BP Vars having to be declared public to be accessible now:

                          Originally posted by Hourences View Post
                          Is there any reason for this change? Because it is a pretty bad change.

                          We have had it happen before that people start editing stuff they are not suppose to, because it is not clear what they should and should not change. And that was a problem already with C++ based classes, but now that BP enforces you to do the same thing this problem just got worse.

                          Speaking of which, what we also don't have is the ability to make grayed out properties in BP, and information boxes. I want to be able to display info (text/values) in the properties to the end user. For example if I have a text field, I want to be able to display somewhere "text field length is currently 65 characters" to ensure there is feedback to the end user as to how he is doing char limit wise (or for whatever other reason).
                          I also would like to know the logic behind this change, it requires extra user understanding and means everything gets exposed to the instanced F4 menu (Details)

                          It makes things more complicated for new users, less convenient for existing users, and I still dont know what it accomplishes as a distinct change that was not in place or working priorly.



                          Originally posted by Marc Audy View Post
                          It sounds like you are using the wrong settings when specifying your UPROPERTY.

                          UPROPERTY(EditAnywhere, BlueprintReadWrite ....) is going to let anyone access this property anywhere.

                          But you can specify EditDefaultsOnly and then it can only be modified in the blueprint defaults and there are a number of different permutations. See https://docs.unrealengine.com/latest...ers/index.html for more degtails.
                          In regards to this issue, I was not even made aware of this issue until just now. For anyone else experiencing this, you simply use EditDefaultsOnly in c++ as Marc mentions.

                          However, this only works for C++!

                          Originally posted by JoeWintergreen View Post
                          Seconded. Just because I want something to be accessible from other blueprints doesn't mean I want it to be accessible to the level designer or cluttering up my actor properties. Why'd someone think this was a good idea?
                          The issue of all BP vars becoming public everywhere still needs to be addressed as there does not seem to be an EditDefaultsOnly option for BP programmers.

                          ~~~

                          Visible Anywhere

                          Hourences also mentioned wanting a VisibleAnywhere option exposed to BP, which would be neat! Easy to do in C++, not possible in BP as far as I know

                          However I am still questioning the foundation of this change to requiring all cross-BP vars to be public, and until that is sorted out / flowing well for everyone adding in visible anywhere and edit defaults only... well that might actually be what's need, to just give people all the options

                          Have fun today!

                          Rama
                          Last edited by Rama; 12-09-2014, 08:38 AM.
                          100+ UE4 C++ Tutorials on the UE4 Code Wiki, including UE4 Multi-Threading!

                          UE4 Marketplace: Melee Weapon Plugin & Compressed Binary Save System Plugin | Rama's C++ AI Jumping Videos | Vertex Snap Editor Plugin

                          Visit www.ue4code.com to see lots of videos about my C++ Creations! ♥ Rama

                          Comment


                            Pero no tiene el soporte a HTML5 sin el source

                            Comment


                              Just a quick question - can I enable the static lighting from emissive channel for meshes that are generated by a blueprint? This would be extremely handy!
                              Check out my GTA2 remake in UE4

                              Comment


                                Originally posted by JoeWintergreen View Post
                                Seconded. Just because I want something to be accessible from other blueprints doesn't mean I want it to be accessible to the level designer or cluttering up my actor properties. Why'd someone think this was a good idea?
                                As a quick-fix, why not preface the categories with "DO_NOT_EDIT_"?

                                Comment

                                Working...
                                X