Irrlicht 1.4.1 released

does not have my new sample :(
space ship moving

I'm getting really worried about Irrlicht development when a bug which corrupts filenames(!) is now known since half a year and no one seems to care much.

It's been discussed now several times like here: http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=25414
And unlike mentioned in that threadtitle it's not just a bug on Linux where it prevents working with customer files (as you can't rename those) and causes problems in any situations where you need to work with absolute paths (as you also can't control pathnames sometimes). On Linux you get at least errors soon. On Windows it's even way worse as you don't notice that Irrlicht modified filenames until much later. And that's just nothing you do ever expect from an engine. This bug is sooo bad - I simply don't get why it isn't top priority to fix this? A working fix would be as simple as just removing all make_lower calls.

So thanks for a new release, I appreciate all the work that's put into it. But as long as such a serious problem gets ignored I'm not getting happy with new releases anymore. Filenames are on the lowest level and one of the most important parts of any library and if problems there don't get fixed then this is killing my trust in the engine.

Fishing for Niko's attention, or why don't you discuss in the forums?
Anyway, please remember that there's only one string identifying a mesh or texture - the filename. Now, it's possible to load abc.3ds and Abc.3DS under Windows, and it should resolve to the same file. If the first one was actually the correct name, this also works under Linux. However, the proposed fix would silently create two mesh instances under Windows and result in an error under Linux. I do understand that there are situations which would like to load the second file instead of the first one, which is not possible ATM. But I don't know where this prohibits a workflow at all. Simply make this restriction explicit to your customers.
So please continue this discussion on the forum, it's way easier than in this blog...

@Hybrid, I tried to raise this topic by now three times in the last half year in the forum and didn't get anywhere, so yes - now I try to raise Niko's attention as I really would like to see what he is thinking of this. This is the worst bug I did see using Irrlicht so far. And I found a lot of bugs in the last two years and I never really cared or mentioned it again when reports got ignored, because I know how much time you need to fix problems and I never though of any other problem as really important. And in this case I already know that you and bitplane know about it and I'm rather sure that Ing. Apfelbaum also knows it already as he added it. And none of you did really seem care or even think that this is a real bug. So well - maybe I'm the only thinking this is a serious problem and well, then maybe the Irrlicht team just sets very different priorities about importance than I do. But before I accept that I want to give it a last shot and know if Niko also thinks like that.

And sorry - but I am not really sure if you even get the problem so far. Sure I know that the idea was probably to solve the problem with identical texturenames - and like I already mentioned in the thread in the forum a solution would be to split the identification from the filename. Or you could ignore the case whenever it's used. But that's not done currently - and so *this is the filename* and not just some identifier you are changing here. And this is wrong on all systems, not just on Linux. This bug hit me a lot harder on Windows, where it silently changed filenames on serialization. I only noticed when I tested my app some time later on Linux, where this simply prevented loading the files thereafter.

And I must admit that I don't really understand why a developer who is as good as you still thinks that it's fine that a library changes filenames which the user did give it. This is confusing me as hell. I don't know of any strings which are more sacred in computing than filenames. I mean if that would be ok, then why don't you just continue and create hashnumers instead? They are even more unique - and well, they prevent the loading of a few more files (all of them now), but do I rather see fail such a bug in an obvious way than seeing it modifying filenames in a sneaky way that can get by unnoticed for a long time.

You try to help some users who don't get how filenames work on their system (and any other library I know) and to solve that you wreck them on all systems, add behaviour which is completely unexpected and even prevent loading a lot of files on other sytems completely? You know - even Microsoft does *retain* the filenames. If you read/save a filename with Irrlicht on Windows you wreck the names of files. And even on Windows users will not accept when applications change their filenames. I think you might get an idea of that if you ever tried to check in filenames in SVN where someone decided to just change the uppercase/lowercase of the name.

I guess I fail somehow - or I don't see something - or whatever - it's so completely confusing me that you defend something which I see as the worst bug I did see in Irrlicht so far. I know you're one hell of a developer and I'm usually not a completely horrible programmer myself, so I don't understand how we can have such completely different opinions on that.

And that's why I hope Niko maybe takes notice and unfortunately he does not really often seem to care about threads in the forum.

hi,
yes, I think it would have been better to send me a mail about this or discuss it in the forums than here on the blog, but in short: yep, that's a small glitch in how irrlicht works currently, but for 99% of all users not a problem, usually. Also the reason why this hasn't been adressed, sorry.
And BTW: sure I care about the forum and irrlicht, but don't have that much time anymore. Looks like I don't much for Irrlicht anymore, but I think you don't want to know how many irrlicht user emails I have to answer every day... :)

Yeah, sorry, I thought about mailing you, but this here still felt less intrusive and I already knew that the other people from the team also read this here, so it was not as completely behind their back. I'm having a bad enough feeling doing that already anyway. I already tried the forums and unfortunately there is no developer mailing list which would be perfect for such topics.

And well, now I'm rather completely frustrated to see that you also feel that it's just a small glitch. Support for valid filenames is completely broken in Irrlicht as soon as they contain uppercase characters and the official solution is not to acknowledge that this is a serious problem but to recommend that users just should rename all filenames which are used with Irrlicht to lowercase names? It's really hard to believe this, as this sounds a like a real bad joke :-( The engine ain't broken - the world just has to switch to using lowercase filenames, wtf...

Right, it's not 'a small glitch' but a problem which nearly affects noone which uses Irrlicht for creating normal games (which is the intended usage). It's clear that it is not nice, and should be adressed, but it doesn't have a very high priority. The switch to lowercase is there for windows and other OS's, so that no texture gets loaded twice.
Yep, that's bad for people like you, I know, but maybe also understandable from our point of view.

Yes, I know why it's there:
1. You need a unique identifier for Textures
2. You had filenames already for textures
3. You use the texturefilenames as identifiers and now there are some problems due to filenames not being unique on some systems.

But those problems where rather minor (worst that could happen was a texture loaded twice, right?) to what you did now
4. You didn't fix the identifier but you fixed the filenames so it meets the need for an identifier for textures.

And if there is some sorting priority for bugs, shouldn't it be first "how bad can the bug affect people" and only second "how many people will notice"?

I would sort of agree if this would be mainly the problem on Linux where it fails loading files sometimes. But that's just the minor problem. What's the worst that can happen? You might not load some files and maybe you might accidently save files with a wrong name thereby creating a copy. Not nice, but I wouldn't make such a stink if that would be the worst.

But now just imagine any Application on Windows which does change the filenames of users. You don't even know the old names afterwards as those get overwritten. And *that* sounds really really bad for me - because suddenly you no longer just have an application not working correct, rendering wrong, or simply crashing, but now you have an application wrecking user data. And even worse than programming an application that behaves like that is programming a library which does that internally so the application programmers does not even know about this until they get bitten by that bug.

Yes, many people won't notice - but this bug is dangerous and that's all that matters for me here. And it's so far the only bug I found in Irrlicht which I would categorize as dangerous.

Btw. I got bitten by that bug while programming a simple tool for a "normal" computer game which I used to create the GUI.

Oh well, at least I tried. It seems we really have different priorities about what's important.

Still I don't see why Windows people would be affected. There are apps under Windows which might have problems (such as the mentioned SVN, but did you every try to commit to files with only different cases under Linux, and then check those out under Windows? I guess it's not only Irrlicht that has problems...), but even if you don't know the exact name anymore, it will save correctly under Windows.
And please, please use the forum. This is a blog, not a discussion board...

Btw.. another fix which might be even simpler than removing the to_lower would be to keep the filename simply separate and not mix it. Just add it as an additional variable and use that one in the texture serialization. Then loading will work again - and you no longer use the only copy of the filename for identification but you have separated that. Add a getFilename to the places where you have now getName and the user will also no longer be confused that he can set a filename but gets back something different and the only way to know the filename is no longer to remember it for himself.

hybrid, the problem is the danger of changing user data. And really - I don't want *any* application change the spelling of my texture names.

Yeah, yeah - I'll go back to the brightly lighted official forum now. This dark corner here was just to get off some heavy complaining which started to drive me crazy.