There was a huge discussion on MS forums immediately after Visual Studio 2012 was released. The problem was that users(lots of users) where very dissatisfied with the performance of Visual Studio 2012 compared to VS2010. Virtually every one was unhappy about it, and expressed his dissatisfaction. But there were few people who claimed the very opposite, that performance of Visual Studio 2012 not only didn’t decrease. No, in their case it improved.
After couple of days of that disscussion, Microsoft officially confirmed that there is decrease in performance in VS2012. You know what those few dudes did? They still claimed that VS2012 performs better than 2010.
And you remind me of those dudes. Epic does admit that there are problems with UE4, that there are rough edges, yet you seem to be oblivious to that. To you there are no problems with UE4 whatsoever.
@smallB: You have to understand that some guys probably dont or hardly get any crashes → e.g I’m using the engine since the beta 3-4 hours each day for various stuff like level design, programming, bp programming, fx stuff, import/export,…(actually for everything :p) and I just got two major crashes in that period of time. (one due to my outdated gpu driver)
With laptops it’s another topic -> there you should make sure that you run it with the “high performance” power setting and with the right gpu (most laptops have an integrated gpu -> so you will have to make sure that you use the nvidia gpu) e.g my PC shuts down after some hours in the UE4 when I just use my integrated gpu
Also make sure to:
“…but it would help us if you could create a new post for each of the issues you listed.”
leave it out man
you have valid points but there is no need to be so agro about it, ue4 works fine for some people and not for others.
Epic is willing to take a look at any problems users have and if it is something wrong with the engine they try to fix it, but they need information to reproduce the errors.
just going on and on about it without any hard facts only gets certain people riled up, if thats what you want then go for it, if you want the engine fixed give Epic something to fix.
Simple: My fault!
Because Epic is not responsible for the integrity of my assets. A corrupted asset can crash any software.
Just open a notepad and write:
“MZ ÿ‹t$PHƒÄ A]A_Ã„”
Save it as EXE file and run it. Surely you will get a nasty crash. But that is not Windows/Microsofts fault.
So when I create a TGA file with an HEX editor and make a mistake, its indeed not Epics fault that this data crashes the editor as it expects plausible tga data.
Its similar to create an infinite loops in a blueprint and then complaining that the enngine “hangs up” and then crashes…
When geometry causes editor crashes, its usually corrupted/extreme geometry. Somewhere in the processing results appear that shouldnt and are not anticipated.
Calculating the surface of a rectangle with one side at zero length for example must go wrong. Its now easy to create this kind of geometry in max.
Now saying “yeah UE4 should be smart enough to catch that” is not valid. You cannot anticipate all possible forms of input.
If you find such a solution, then you would be immortal among computer scientists because you would have found solutions for the halting and the decission promblem, the holy grales in computer science…
Yes, probably I did. I managed to track it down to a corrupted file in the intermediate folder. When I delete it, the editor behaves normally again.
Now Im investigating what causes this problem.
Since the editor is only going loco with this specific project and all other projects are fine, Im sure its not UE4 related but something I did to the project to corrupt it. My prime candidates are the meshes. So often you import meshes and some NGons are screwed up. Maybe thats the case here.
Like some normal vectors have the length of zero. That might confuse UE, or something else. Im still checking…
I remember I also was very dissatisfied with Microsoft when they released DOS 6.0… Until then I was happy with 5.0 which was very stable.
With 6.2 they cured a lot of the problems, but still…
I will, thanks.
I will leave out, that is ;). I do not enjoy aggro, nor I want to riled up anyone.
I do love that community and I see some great people here. I also want be able to help others. And I also believe that UE4 will be great software. In a year or so…
But it really irks me when thread after thread people are reporting crashes for no obvious reason and yet I get response from some dudes that engine is in very stable stage and they don’t see anything wrong with the current state of affairs.
Anyway, thanks for the cool down sign. Really appreciated.
Epic is not responsible for integrity of assets. That is true. But epic is responsible for providing quality software. I’m telling you, that if software cannot properly handle importing a file (be it corrupted) then this is a fault of a software. Even more, it says that software is poorly written with that regards. By properly I mean that if file cannot be imported for any reason the software reports it back to you, via dialog box for example. You close that dialog box, but software do not crash.
Imagine that this tga file you got from one of your friends and you don’t know where and how to manually edit it. You try to import it and it crashes your UE4. Surely correct behavior is that UE4 reports in some way that the format of that file is invalid and do not crash? Won’t you agree on that with me?
And I will be the same. As soon as the instability will get fixed I will never say that the engine is unstable.
Crashing the engine during import is an extreme situation though and you should report it on AnswerHub or post in the forums so that people can help you figure out what is wrong. Normally you do get a dialog box that tells you import failed if something is wrong with the asset, then you click OK and then editor keeps running.
That’s a little bit of a loaded question. I think more and better should always be pushed for, but also we should temper that with a realization of the fact that this software is used by lots of people from one-person indie shops to teams with hundreds (maybe thousands?) of people making just about every kind of game and interactive software you can imagine. Epic has limited resources. In my experience, they put a LOT of those resources on bug fixing. I’ve gotten rapid responses and people earnestly trying (and usually succeeding) to help me when something isn’t working. I’m not sure what more I should ask from Epic. I’m a software developer and I know that my software is never perfect. I can’t hold Epic to a different standard than I hold myself.
Hey, every software has a bugs (believe it or not mine has them too, I know it is hard to believe but yep I can admit that us unbelievable as it sounds my software has bugs ;), but if company with such a status like Epic, and with their resources, and with their experience, having all that they releasing a product which crashes during simplest actions, surely you can/should expect higher standard from them than from one man shop (you that is) (I’m sorry I’m assuming you are independent developer working on your own or with rather unsubstantial (in number) team of other developers when compared to what Epic employs).
Surely it is only reasonable to expect more and better from team of most likely best professionals in the world than what can be expected from you (or me or any small number of independent developers for that matter)? Would you agree?
The problem with this is that you’re assuming your experience is typical. We have a team of seven people working in UE4 regularly and we don’t see major stability issues. We’ve had problems with mobile device builds, we’ve had problems with functionality at times. We also had some major problems with animations on Mac laptops (that was resolved in 4.5.1), but we absolutely haven’t seen the kind of instability you’re talking about, and our team works across many device configurations from mid-range laptops to high-end workstations using both Windows and Mac computers.
The fact is, there are a lot of variables that could contribute to software crashing, and that’s even more true with a development toolset like UE4. It’s impossible for Epic to test every single permutation. It’s frustrating as hell when you experience problems like yours and I don’t mean to belittle your situation, because I know what that’s like. But I also know how frustrating it is when a customer is mad at you for a problem you can’t recreate and couldn’t reasonably foresee. Because the software crashes for them, they assume your software is bad. That’s frustrating for developers because they want customers to be happy and to appreciate our hard work. I’m just trying to look at both sides of the equation.
I know from the code and from my interaction with them that the Epic developers are competent. In my experience, the Epic team really wants to address problems. Every problem that our team has reported has been fixed. Sometimes it has taken a release or two, but they’ve worked with us every time we’ve reported a problem and have been very responsive to our feedback.
I understand you are experiencing problems that I am not and that it’s frustrating, but I’m also confident that Epic support will do what they can. Things are probably slow right around Epic HQ right now because of the American holiday, though.
It all depends on what your project entails in regards to stability, we still get the odd crash from deleting trees. Material editor crashes, weird bugs where we have to restart the project for it to work and over the past three months we have hit a plethora of bugs. I’m not sure if heavy use of terrains / effects and world composition is normal use case…
The trick is to work with Epic to resolve these, I firmly believe that if you’re paying for a product it should work correctly even though in reality an engine will always be a work in progress. It’s the advantage of paying for an engine, as opposed to building and maintaining your own.
As long as Epic keep up with the great service, I’ll take it one step at a time…
And what sort of question is that? Did I say that there are better tools than UE4? No. Did I suggested that they are better tools than UE4? No. All I’ve said is that UE4 at the current moment is at a very unstable stage (and not just with regards to crashing, API, features, etc). And it is. Thread after thread is confirming that. Epic agrees and confirms that there are still rough edges.
The crux is that not every computer science problem can be fixed with money.
Think of the engine as avery very complex finite state automaton.
Requesting now that the engine “shall handle all possible forms of input”, then you are asking for a program that solves the halting program.
I dont know about your background, but just look look up things like “Turing machiine”, “Halting/decission problem” and “Gödels theoreme of incompleteness”.
For any machine that is capable of handling natural numbers (and UE is certainly cabable of that and way more…), there exist input patterns that transition the machine into an undefined state.
Even the C++ compiler is not above that principle. Who says I cant trigger a buffer overflow with my assets. In C its pretty easy to exploit gets() for example…
Handling correctly import of a corrupted file doesn’t fall into that category.
And please don’t tell me(us) how to think about engine. Yes, it is complicated, yes it is difficult to maintain. No, it is not the most complicated software ever produced.
And again, you throwing lots of pointless theory, just like you did in the thread about lightmaps, and the fact is that you were wrong there and you are wrong here. You have problems with understanding basic concepts and porting ideas from analogy to analogy. Example, you talk about writing some nonsense letters in notepad and saving it as an exe. Then you say it will crash.
You have to ask yourself what will crash and how this relates to engine crashing during importing some possibly corrupted file.
Your analogy is incorrect in the sense that if you did write the letters and save this file as an exe and run it and this action would crash Windows, then that analogy would be correct. Then it would mean that Windows cannot handle corrupted files. But just because file doesn’t executes (why should it, it is not a proper exe) it doesn’t mean anything, you make no valid point with your example. The fact is that you have really (it seems to me anyway) problem with understanding basic concepts of computing in the sense that you cannot distinguish responsibilities of software from responsibilities of user of that software. For example, responsibility of a software is to provide proper/correct output. Responsibility of user of that software is to provide proper input. If software cannot provide proper output given proper input then that is the responsibility of a software and software designer not a user.
You are saying that it is your fault by providing hand made tga file and you don’t see anything wrong with UE4 crashing whilst trying to import this file. I’m telling you that your understanding of responsibilities is weak/incorrect.
I as a user have responsibility to provide a file to read - this is a proper input, file with proper extension recognizable and acceptable by this software - I don’t have the responsibility to make sure that this file is not corrupted! This file can come from different sources, I as a user may not even have the opportunity/tools to check if this file is correctly formatted etc.
If I want to import a file there are couple of plausible scenarios:
a)File is corrupted, software detects it, informs me about it, import unsuccessful.
b) File is NOT corrupted, software properly imports it, import successful.
Any other scenario means that there is some problem with software.
And please don’t try to throw theory on me(us). I did my science degree some time ago, read more theorems, thesis and what not then you will probably ever read. And even with all that reading and all that theory you throw, you cannot grasp the fact that if software crashes during an import of corrupted file the responsibility lies with a software.