Unreal Engine 4.6 Released!

[Marc Audy]

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.

[twiddle]

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

[prcn3dlight]

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

[Demolition Man]

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.

[Demolition Man]

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?

[DanielW]

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

[DanielW]

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.

[LittleGiant]

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

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.

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.

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.

[smilingrob]

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!

[JoeWintergreen]

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?

[MC Stryker]

The following code suggested here is absolutely how you would generate input and is the correct way to do it now.

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.

[Rama]

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

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.

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++!

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

[slam_]

Pero no tiene el soporte a HTML5 sin el source

[Hackmet]

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!

[kat0r]

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