Announcement

Collapse
No announcement yet.

Unreal Engine 4.6 Released!

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

  • replied
    PLEASE Fix Cascade Colour modules guys I have no idea how or why this change was made!

    https://forums.unrealengine.com/show...114#post192114

    Leave a comment:


  • replied
    Originally posted by Goerge Carlin View Post
    I've road and I've done all the steps of this webpage
    but even now whenever I want to build an HTML5 project the engine just redirects me to the same webpage. I don't know what's wrong! I tried to write the question here but cause I don't have enough rep I can't do it there.
    this is my account there
    any answer or comment are welcome. or even if someone can come to me and say his version is working very well, It would be great. THANKS IN ADVANCE.
    Have you got emscripten 1.25 installed?

    Leave a comment:


  • replied
    Originally posted by Chris Gagnon View Post
    These linking errors are caused by the module not being included.

    Open YourProject.Build.cs

    Code:
    // Uncomment if you are using Slate UI
    // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" });
    Uncomment the PrivateDependencyModuleNames.AddRange(...) line as it suggests and you should be good to go.
    Thanks Chris! As a heads up, it wasn't commented out in my plugin since I started it around 4.0.1. I had to include it with my Joystick plugin build file within my project but good to go and now I'm able to compile in 4.6. Much appreciated for the quick update.
    Last edited by MC Stryker; 12-12-2014, 02:26 AM.

    Leave a comment:


  • replied
    HTML5 is not working in 4.6 version

    I've road and I've done all the steps of this webpage
    but even now whenever I want to build an HTML5 project the engine just redirects me to the same webpage. I don't know what's wrong! I tried to write the question here but cause I don't have enough rep I can't do it there.
    this is my account there
    any answer or comment are welcome. or even if someone can come to me and say his version is working very well, It would be great. THANKS IN ADVANCE.
    Last edited by Goerge Carlin; 12-11-2014, 12:53 PM.

    Leave a comment:


  • replied
    Originally posted by Chris Gagnon View Post
    These linking errors are caused by the module not being included.

    Open YourProject.Build.cs

    Code:
    // Uncomment if you are using Slate UI
    // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" });
    Uncomment the PrivateDependencyModuleNames.AddRange(...) line as it suggests and you should be good to go.
    Great, that removed the need to suppress the warning and the additional functions. Will be pushing this update throughout my plugins!

    That said Slate should probably include SlateCore automatically unless there is a compelling reason to not to.

    Would also be nice to get guidance on adding custom files in the packaging process for plugins so we can get Launching mode to work as well as automatic packaged/shipping support (vs manual file copying after packaging) for plugins with dependencies.

    Leave a comment:


  • replied
    Originally posted by MC Stryker View Post
    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.
    These linking errors are caused by the module not being included.

    Open YourProject.Build.cs

    Code:
    // Uncomment if you are using Slate UI
    // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" });
    Uncomment the PrivateDependencyModuleNames.AddRange(...) line as it suggests and you should be good to go.

    Leave a comment:


  • replied
    Just a quick question - can I enable the static lighting from emissive channel for meshes that are generated by a blueprint?
    Sure, the component has to have Mobility set to Static (which means it must be added in the construction script), and CastShadows enabled. Then modify the component's default properties to have Lighting->LightmassSettings->UseEmissiveForStatic lighting to be enabled.

    Leave a comment:


  • replied
    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_"?

    Leave a comment:


  • replied
    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!

    Leave a comment:


  • replied
    Pero no tiene el soporte a HTML5 sin el source

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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?

    Leave a comment:


  • replied
    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!

    Leave a comment:


  • replied
    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.

    Leave a comment:

Working...
X