[=;275993]
Are they any plans for a patching system? Downloading 4.5 GB for every single hotfix seems a little bit, er, you know…
[/]
We actually already diff chunks and only send down ones that change. My guess is that large hotfix sizes are caused by rippling changes in files like .pdb and .lib that may change drastically all throughout the file even if little has really changed, but someone on the launcher team will be investigating in the future to see what we can do to get the size down further.
We’re also interested in doing some sort of ‘optional downloads’ system further down the road which would separate out the bits for different platforms, maybe the C++ libs/pdbs, etc… so you could pick and choose what you want to download / have installed.
[=;276409]
We’re also interested in doing some sort of ‘optional downloads’ system further down the road which would separate out the bits for different platforms, maybe the C++ libs/pdbs, etc… so you could pick and choose what you want to download / have installed.
Cheers,
[/]
That would be pretty cool. I know for example that I’m probably never going to deploy anything to iOS or HTML5 etc, so not downloading and installing all that stuff would be great.
I am a bit confused. In both of the threads you linked (your links are broken, I used the ones from your last post), you posted that you found the specific commit for the fix and in both it seems that the errors you are seeing have been resolved internally and will be implemented into the engine, potentially in 4.8. I don’t understand your meaning by “there is no hope for a solution”. Can you clarify?
[/]
At the moment I’m trying to get to work with these commits editor. They are repairing these problems and add new ones. Until the process converges.
I have no hope that in the near future will release an editor with the correct assets loading.
I wonder how epic fix these kind of bugs. Its really annoying to bugfix I think, because you have to make changes, then apply material again, then build again, then package again and finally deploy to mobile to see if it fixes the problem.
I wonder how epic fix these kind of bugs. Its really annoying to bugfix I think, because you have to make changes, then apply material again, then build again, then package again and finally deploy to mobile to see if it fixes the problem.
[/]
Don’t worry mate, UE4 it’s still a baby, all those issues will be fixes in the next updates for sure. Most of those “bugs” are actually made by our own hand.
Hello and sorry for asking but it’s really important to me.
Is the coming 4.8 preview version reliable enough to start a brand new project in it and then move the data to the final 4.8 ? Since the project relies highly on the new features that come with 4.8 such as ecosystem painting and large landscape handling etc.
[=;280331]
Hello and sorry for asking but it’s really important to me.
Is the coming 4.8 preview version reliable enough to start a brand new project in it and then move the data to the final 4.8 ? Since the project relies highly on the new features that come with 4.8 such as ecosystem painting and large landscape handling etc.
Regards,
Alireza.
[/]
You should never start or continue production work on a preview build. Feel free to try out the tools and report issues, but they are previews for a reason and I would hate for you to lose work if there turns out to be a serialization or something like that.
[=;280336]
You should never start or continue production work on a preview build. Feel free to try out the tools and report issues, but they are previews for a reason and I would hate for you to lose work if there turns out to be a serialization or something like that.
Cheers,
[/]
We’d keep our development delayed until final version then.
Thank you.
If I where in your shoes, I would go ahead and start development on 4.7.5. That way when 4.8 comes out you will already have a start on your project. Things like static meshes and materials aren’t going to change much between versions so you wouldn’t lose much time. On the plus side, you will get some experience converting your project over to a new engine release (i.e. and that’s always good experience to have!)
[=Demolition Man;280596]
If I where in your shoes, I would go ahead and start development on 4.7.5. That way when 4.8 comes out you will already have a start on your project. Things like static meshes and materials aren’t going to change much between versions so you wouldn’t lose much time. On the plus side, you will get some experience converting your project over to a new engine release (i.e. and that’s always good experience to have!)
[/]
Thank you for the suggestion but the very first step on the project is to setup the terrain which is a large one and requires 4.8 to be there, the rest of the things also need the terrain to be setup already. I have converted projects from 4.6 to 4.7 though and not much problem there but converting from 4.7 to 4.8 isn’t going to work regarding large terrain and ecosystem painting tool since they are not implemented in 4.7.
Why do you need to start making your game with creating a landscape with trees etc? All the visual stuff is mostly not really important at the beginning, so you surely could just create all the gameplay logic and then after some months you would make a landscape and so on.
[]
I have converted projects from 4.6 to 4.7 though and not much problem there but converting from 4.7 to 4.8 isn’t going to work regarding large terrain and ecosystem painting tool since they are not implemented in 4.7.
[/]
I already got a broken project , and will make me worry when there is some new update to get another broken project when updating it.
[= ;281042]
Why do you need to start making your game with creating a landscape with trees etc? All the visual stuff is mostly not really important at the beginning, so you surely could just create all the gameplay logic and then after some months you would make a landscape and so on.
[/]
We had our time creating what we need. It’s just a matter of starting a level and throwing it all together and that requires a terrain and environment to be there.
@, When I was porting my landscape pack from 4.6 to 4.7 my foliage was looking terrible. With the new foliage shading added even though I adapted the materials but the shading was just wrong and the only thing I had to do was to create a new project/level using 4.7 and setup everything again. And yes is really a stab in the back when you are on a tight schedule. But well I’m so happy I don’t have to migrate from Cryengine 3.6 to 3.7. That’s a really fun story happening to their users right now
[]
I had to do was to create a new project/level using 4.7 and setup everything again. And yes is really a stab in the back when you are on a tight schedule. But well I’m so happy I don’t have to migrate from Cryengine 3.6 to 3.7. That’s a really fun story happening to their users right now
[/]
When i loose months of work on a finished level map because i can’t recover it , it is a serious problem.
[=;281091]
I already got a broken project , and will make me worry when there is some new update to get another broken project when updating it.
[/]
In general, we don’t recommend moving projects you are actively developing between versions unless there is a fix or a that you need in the newer versions. There is always a risk of incompatible changes or something breaking when moving between versions of live software and it is typically best to keep projects on one version unless it is absolutely necessary to move to another. Continually switching versions could increase the risk of something going wrong.
[=;281288]
When i loose months of work on a finished level map because i can’t recover it , it is a serious problem.
[/]
We expect users to use version control for their projects, even when working alone. Perforce, Git, SVN are all extremely useful and we highly recommend using any of them to avoid losing work.
