@
Thanks for the info. In that case I will start a clean project and see if that helps. I’ve brought one from 4.6.1 and I remember toying around with the Monitor Content Directories prior in previous releases. Back then I couldn’t get that to work either, perhaps I messed something up when I was changing the settings?
[=daniele_niero;229836]
Is there a place where we can submit bugs?
I have found a problem with color pickers, both on Mac OSX and Windows (7) and tested on two different machines.
Any color picker UI, the one that appears when we click on a color property, disappear immediately when we click anything or anywhere in it, making impossible to adjust colors within it.
[/]
I’m experiencing , it’s a bit of an annoyance. I’ve been opening linear colour variables and adjusting rgb values directly as a workaround.
Is anybody else experiencing problems building for Android? We literally can’t deploy to an Android build at all.
[=;229290]
Hi! The price change to prices ending in ‘99’ is no accident. at Epic Games we’re constantly researching ways to improve the Marketplace for both buyers and sellers. When we initially launched the Marketplace, we chose a round pricing structure for asset costs, keeping them as whole numbers. After further research and consideration, we’ve changed our pricing policy moving forward to adhere to the tenets of pricing theory, so that all prices will now end in “.99” in USD, and converted to the equivalent in other currencies.
What means is that instead of an asset selling for $30, it’ll now sell for $29.99 instead. Studies have shown that actually increases sales, so that’s the direction we’re going in now to keep the Marketplace competitive and keep content creators happy. Over the last two weeks I’ve reached out individually to currently selling assets on the Marketplace, and has agreed to the adjustment.
[/]
I cant be the only one that doesn’t care if it increases sales or not, I absolutely hate it. I personally think its stupid, its a bit like gas prices with the 9/10th of a cent at the end, its infuriating and demeaning to people’s intelligence. I understand Epic’s reasoning behind , and i’m sure that it might actually sell more, but I would opt in to have that $0.01 added back on, even if its just for show.
Sorry for the rant, but its been a huge peeve of mine for a long time, similar to why don’t we add tax prices into the price of object so people know exactly how much they are going to pay by the time they hit the checkout. We do it to trick and deceive. Someone is far less likely to put something back because tax prices pushed the total price beyond what they can afford, than if the whole price was there for them to see at the beginning they might not even try to buy it. I associate the .99 ‘trick’ with the same boat as the tax ‘trick’.
Again sorry for the rant, i’m not trying to attack Epic or anything, I just personally find it demeaning and would love to see whole numbers even if it is just in my launcher.
I agree. It’s obviously not of great importance in the scheme of things. However the thing is that, as specifically stated, Epic had made the decision to use rounded prices. To then do ‘research’ and decide to explicitly change the approach is just ridiculous.
(Post moved to feedback thread mentioned by below. Then I realized it was quoted in the post immediately before the one I made, so you can just it there)
Hey,
Can we please keep the conversation on topic with 4.7 and any issues that may be happening specifically with the editor. A thread has already been started in the Feedback section of the that you can discuss the Marketplace change.
You can see that thread : https://.unrealengine/showthread.php?60087-Marketplace-Please-don-t-do-to-the-0-99-pricing
Thank you!
[=;229290]
Hi! The price change to prices ending in ‘99’ is no accident. at Epic Games we’re constantly researching ways to improve the Marketplace for both buyers and sellers. When we initially launched the Marketplace, we chose a round pricing structure for asset costs, keeping them as whole numbers. After further research and consideration, we’ve changed our pricing policy moving forward to adhere to the tenets of pricing theory, so that all prices will now end in “.99” in USD, and converted to the equivalent in other currencies.
What means is that instead of an asset selling for $30, it’ll now sell for $29.99 instead. Studies have shown that actually increases sales, so that’s the direction we’re going in now to keep the Marketplace competitive and keep content creators happy. Over the last two weeks I’ve reached out individually to currently selling assets on the Marketplace, and has agreed to the adjustment.
[/]
That sounds great! Just wondering since it happened right when we switched over to 4.7.
[=;229300]
Hey Demolition Man-
When you say “run it after a successful build” are you referring to compiling the code though Visual or the Editor, or do you mean after packaging the game for Windows? Also could you make a post on the AnswerHub to help us monitor bug better.
Cheers
[/]
I packaged the game (i.e. Just Shooter Game) for running on Windows with the minimum OS being Windows XP via the editor. So when I tried to run the application the window popped up, I ended up with a totally black screen. The editor told me that everything was created successfully (Build successful) but all I got was the audio like I mentioned before.
There seems to be a problem with SpawnAI from Class BP when using the option “dedicated server” for testing a clients view.
When the enemy gets spawned, it does not react to the Navmesh. It stands still and does not move. It still reacts to services and does tasks, but Navmesh is not registered.
AI that already exists in the level does not have .
When spawning server and client both as players, AI moves normally.
[=artoculon;229661]
Hey guys, Light build times are incredibly slow for me now. I started up a small scene which is basically floor + ceiling mesh, walls, and 1 point light. It is currently stuck on 5% for 15 minutes, and earlier had it go to 96% after around 30-40 mins but did not finish.
Previously on 4.6 and Previews, a simple scene would build within a minute reliably. Anyone else experiencing ??
[/]
I have the same problem, on 4. build time was about 15sec for a simple test scene. Now in 4.7 its about 5 minutes for the exact same scene. Also since 4.7 i’m experiencing short slowdowns, stutter problems when flying around the viewport in that scene every few minutes. Never had that problem in 4.6.
: I’m hoping to get an acknowledgment for the Build Lighting issues i’m facing. 4.6.1 I had no issues, a simple scene would take less than a minute to build. In 4.7, I am getting a Lightmass Crash everytime, or it just gets stuck.
Granted I have 4gb of ram, but in 4.6.1 it never was an. I am just testing right now with a simple scene: floor, ceiling, walls, 1 point light.
Semmel: Sorry to hear you’re facing same. Does yours eventually build though?
[=;230095]
I’m experiencing , it’s a bit of an annoyance. I’ve been opening linear colour variables and adjusting rgb values directly as a workaround.
[/]
We’ve got the color picker logged as UE-9745 and already have a fix for it in place for 4.7.1.
Cheers
Reminder about Bugs
Hey ,
If you are experiencing a bug with the 4.7 release, please remember to log a bug report for the on the UE4 AnswerHub to the Bug Reports section. way Epic can investigate and respond to each individually. Unfortunately the are not well suited to investigating bug reports due to all the different conversations, and your reports may be lost or we may not notice each other’s replies. It would also be beneficial if you began the title of your AnswerHub report with [4.7.0].
We are currently working hard to investigate, reproduce, and log the 4.7 bug reports that are being submitted to us, especially any crashes. Thanks for both your help and your patience.
Cheers!
Get distance to function has no execition pins anymore which I used often in my game.
I have to make a workaround for that which took me some time now 
I made a question related to that on answer hub.
GPU Visualizer (profilegpu) has a bug.
Texts are drawn but window background is not.
https://answers.unrealengine/questions/179244/gpu-visualizer-window-has-a-bug.html
[=artoculon;230345]
: I’m hoping to get an acknowledgment for the Build Lighting issues i’m facing. 4.6.1 I had no issues, a simple scene would take less than a minute to build. In 4.7, I am getting a Lightmass Crash everytime, or it just gets stuck.
Granted I have 4gb of ram, but in 4.6.1 it never was an. I am just testing right now with a simple scene: floor, ceiling, walls, 1 point light.
Semmel: Sorry to hear you’re facing same. Does yours eventually build though?
[/]
Hey Artoculon,
No worries, I’ve been assigned your on AnswerHub. Thank you for your patience and I’ll respond once I get a to take a look. 
I was unclear about the html5 improvements in 4.7. Do we still need to download the full source to run an html5 project? I’ve downloaded the Emscripten SDK and restarted the editor but I don’t see my browsers under the launch menu.
I might be missing something…is there no way to override an actor component’s constructor with blueprints? (What does the Auto Activate flag do, anyway? I had hoped that it setting it to true would cause the Initialize Component event to act like a constructor – but it doesn’t seem to be the case.)
For lack of finding an overriddable constructor, I tried using the Get Components node on my actor’s constructor, then calling a function on the component – which sort of works. A few problems there, though.
First, if a component is part of the actor, rather than just attached to the actor out in the level, there’s no way to modify the component’s variables from the level editor. It’s terribly inconvenient. It would be really nice to be able to change those variables on a per instance basis from the level editor. I’m not sure why it works the way it does.
Second, if the component is attached to the actor in the level, it’s exposed variables are modifiable, but the editor doesn’t dirty the actor and thus fire it’s constructor when these variables are messed with. I made an exposed boolean on my actor that I can toggle on and off in order to force the constructor to execute (more easily), but again, it’s inconvenient. It’s a couple extra clicks for something that updates wonderfully and automagically when the code is in the actor’s constructor. It’s swank to move a slider and see things happen immediately in the viewport.
Third, it’s pretty fragile. For example, I ‘accidentally’ deleted an event on a component that was called by the actor’s constructor, and the editor crashed hard. I’ve had some other minor bugs that I believe are caused by the way the components handle circular references, where a level containing an actor attached to a component refuses to save because the component is a ‘private object’.
[=drekmonger;230707]
I might be missing something…is there no way to override an actor component’s constructor with blueprints? (What does the Auto Activate flag do, anyway? I had hoped that it setting it to true would cause the Initialize Component event to act like a constructor – but it doesn’t seem to be the case.)
For lack of finding an overriddable constructor, I tried using the Get Components node on my actor’s constructor, then calling a function on the component – which sort of works. A few problems there, though.
First, if a component is part of the actor, rather than just attached to the actor out in the level, there’s no way to modify the component’s variables from the level editor. It’s terribly inconvenient. It would be really nice to be able to change those variables on a per instance basis from the level editor. I’m not sure why it works the way it does.
Second, if the component is attached to the actor in the level, it’s exposed variables are modifiable, but the editor doesn’t dirty the actor and thus fire it’s constructor when these variables are messed with. I made an exposed boolean on my actor that I can toggle on and off in order to force the constructor to execute (more easily), but again, it’s inconvenient. It’s a couple extra clicks for something that updates wonderfully and automagically when the code is in the actor’s constructor. It’s swank to move a slider and see things happen immediately in the viewport.
Third, it’s pretty fragile. For example, I ‘accidentally’ deleted an event on a component that was called by the actor’s constructor, and the editor crashed hard. I’ve had some other minor bugs that I believe are caused by the way the components handle circular references, where a level containing an actor attached to a component refuses to save because the component is a ‘private object’.
[/]
Not really related to your problem, but i had the same problem you have in your third statement. Just placed a mesh to my scene, added a blueprint component on scene, choosed where to save blueprint component, and at the end i created a blueprint class from the object i have in scene. But now, trying to saving scene gives me error that blueprint component is an external object and couldn’t be saved. Making my components from blueprint editor doesn’t give me the same error. Very frustrating.