Irrlicht3d.org
::
Blog
|
About Me
|
Twitter
Add comment for
Irrlicht 1.4.1 released
Posted by:
Enter the missing letter in: "Interna?ional"
Text:
[quote][b]CuteAlien[/b] wrote: @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.[/quote]
Possible Codes
Feature
Code
Link
[url] www.example.com [/url]
Bold
[b]bold text[/b]
Quote
[quote]quoted text[/quote]
Code
[code]source code[/code]
Emoticons