Then it will warm you nice and early before you get to test on device as they are always case sensitive.
IE if it doesnt match exactly the case then give the same error as a device would.
Im always getting caught out by this right at the end
If you’re just joining this discussion or reading this post at a long future date, please page down a ways and get the free fix for the above problem.
- Ed (aka RoamingGamer)
Case sensitivity is an operating system dependent thing, not something the simulator cares about.
Granted, they might be able to check for case differences, but it would be a lot of messy changes and overhead which in turn might introduce bugs as well as cost time and effort.
My suggestion it that you adopt some fixed practices regarding file naming. i.e. Always name them using the same rules and you’ll be golden. This will serve you well both to avoid issues with Corona and in general organization.
Cheers,
Ed
I do not see how implementing something into the simulator that reveals a bug as it would appear on an real device would be a problem. That is what the simulator is for - simulating as close to a real device as possible. The Lua runtime already asserts on a real device so its already there. Im sure it wouldnt be too much of a problem. I certainly cant imagine it creating bugs, only revealing them properly. Perhaps some Corona Staff could clarify .
I already use fixed naming conventions but obviously now and then there are errors due to whatever reason and the larger your project, the more chance you could miss something.
The point is the simulator should be simulating.
First, I feel your pain, with regards to case names. We’ve all been bitten by it, and it still happens to me on occasion.
Second, I guess I wasn’t clear. I’m pretty sure that what your asking for would require a change to the SDK and not the simulator. The SDK relies on the target systems for libraries that do file access. Checking for case is a non-existent step right now. The simulators are merely targets (like devices are targets) and they don’t do any special work.
Regardless, you’re right. Maybe the staff will weigh in on this. Also, this is a great question and valid topic. I’ll see if there is a pure Lua-side solution for this. If I come up with something useful I’ll post back.
I just had one of those days. Right at the end of the project. Everything seems perfect and ready to ship and bang. It crashes. Wasn’t connected via adb at the time and it was an event which is rarely triggered so after playing through for two hours, it was just one letter “E” instead if “e”. What made it worse is that I had even gone through looking for it but missed it. Definitely a Grrr moment. Its not essential but just would make sense for simulator accuracy.
In a simplistic explination, it goes something like this: we call fopen() to open the file name. That call goes to the operating system’s file open library call. If we get a valid file handle back, we process the file. If that file handle is nil then we process it as an error (what ever that is).
On OS-X and Windows if the file is Bubba.PNG and we ask for bUbBA.pnG, we get a valid file handle. This is a well known issue. It’s something we could spend a lot of energy trying to address, but the purpose of the simulator isn’t to be a realistic device but a rapid development tool. We could spend years trying to solve this.
Rob
@All,
I have a solution for this.
Originally, I thought I’d monetize this, but instead I’ll be giving it away for free so folks can add to it and improve it.
You can find the current solution here:
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2015/01/caseDetectError.zip
https://www.youtube.com/watch?v=AOkAiR-9y-c&feature=youtu.be&hd=1
Looks promising. Just sent you email (wltrebor). Ill try it ASAP
@All,
I’m done updating this (now free) module. You can find it here:
https://github.com/roaminggamer/RG_FreeStuff/tree/master/AskEd/2015/01/caseDetectError
, or download it as a ZIP here:
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2015/01/caseDetectError.zip
It now checks all of the following:
- require()
- display.newImage()
- display.newImageRect()
- graphics.newImageSheet()
- graphics.newMask()
- graphics.newOutline()
- widget.setTheme()
Note: require() ignores any paths containing these strings (see line 128-ish in caseErrorDetect.lua):
local requireIgnoreList = { "ads", "analytics", "gameNetwork", "facebook", "composer", "crypto", "json", "lfs", "licensing", "media", "physics", "socket", "sprite", "sqlite3", "store", "storyboard", "system", "widget", "plugin", "CoronaProvider", }
Cheers!
Hi again folks. I made a small change to the module so that the ‘require()’ tests do the following:
- Always try to require the file and return something.
- ONLY print messages to the console. i.e. Never throw an error and pop-up a dialog.
Why?
It seems the original way didn’t account for:
- Lua++ libraries I didn’t know about.
- People requiring things that are already included like ‘string’, ‘io’, etc. I didn’t expect this so I put no checks in.
So, now, you’ll get warnings if the module ‘thinks’ something may be wrong, but requires should always do their best to complete.
PS - I may do more updates, but don’t forget folks: This code is free and open source. So get it, modify it, and share your changes here. If I see something I like I’ll incorporate it in the main release.
I can confirm this works - kind of. I had to make a few changes. At first I had to keep adding all kinds of strings to the exclusion list and it got pretty complicated and crashed on other things. Mainly related to the ads library and corona plugins but the easiest way to get round it is remove the whole "_G.require = function( path ) "function . I figured that it would be pretty obvious a whole module wasnt loading.
Now this successfully detects the incorrect filename for a .png including incorrect folder names.
This basically does the job. Just needs audio load sound added. Thank you for this Roaring Gamer. Good job and not two years to do either 
Its also quite easy to add audio. This detects files loaded with audio.loadSound:
Just add it before the display section
-----///////////////////AUDIO
local audio_loadSound = _G.audio.loadSound
_G.audio.loadSound = function( … )
if( type(arg[1]) == “string” and not resourceFiles[arg[1]] ) then
ced.print("***** WARNING! audio LoadSound File ‘" … tostring(arg[1]) … "’ - does not exist. Check case of file.")
return nil
elseif( type(arg[2]) == “string” and not resourceFiles[arg[2]] ) then
ced.print("***** WARNING! audio LoadSound File ‘" … tostring(arg[2]) … "’ - does not exist. Check case of file.")
return nil
end
return audio_loadSound( unpack(arg) )
end
This module will be used at all times for me from now on that is for sure . Thank you and well done again RG
Hello all. I’m posting back to let folks know I FINALLY fixed the issue with caseErrorDetect and OS X. The script works properly now and will detect case errors for these cases:
- require
- display.*
- graphics.*
- widget.*
- composer.*
I purposely left audio.* and media.* unfixed since files may come from temporary, document, or event remote sources. You can easily extend this module if you need to check temporary and document folders.
If you’re just joining this discussion or reading this post at a long future date, please page down a ways and get the free fix for the above problem.
- Ed (aka RoamingGamer)
Case sensitivity is an operating system dependent thing, not something the simulator cares about.
Granted, they might be able to check for case differences, but it would be a lot of messy changes and overhead which in turn might introduce bugs as well as cost time and effort.
My suggestion it that you adopt some fixed practices regarding file naming. i.e. Always name them using the same rules and you’ll be golden. This will serve you well both to avoid issues with Corona and in general organization.
Cheers,
Ed
I do not see how implementing something into the simulator that reveals a bug as it would appear on an real device would be a problem. That is what the simulator is for - simulating as close to a real device as possible. The Lua runtime already asserts on a real device so its already there. Im sure it wouldnt be too much of a problem. I certainly cant imagine it creating bugs, only revealing them properly. Perhaps some Corona Staff could clarify .
I already use fixed naming conventions but obviously now and then there are errors due to whatever reason and the larger your project, the more chance you could miss something.
The point is the simulator should be simulating.
First, I feel your pain, with regards to case names. We’ve all been bitten by it, and it still happens to me on occasion.
Second, I guess I wasn’t clear. I’m pretty sure that what your asking for would require a change to the SDK and not the simulator. The SDK relies on the target systems for libraries that do file access. Checking for case is a non-existent step right now. The simulators are merely targets (like devices are targets) and they don’t do any special work.
Regardless, you’re right. Maybe the staff will weigh in on this. Also, this is a great question and valid topic. I’ll see if there is a pure Lua-side solution for this. If I come up with something useful I’ll post back.
I just had one of those days. Right at the end of the project. Everything seems perfect and ready to ship and bang. It crashes. Wasn’t connected via adb at the time and it was an event which is rarely triggered so after playing through for two hours, it was just one letter “E” instead if “e”. What made it worse is that I had even gone through looking for it but missed it. Definitely a Grrr moment. Its not essential but just would make sense for simulator accuracy.
In a simplistic explination, it goes something like this: we call fopen() to open the file name. That call goes to the operating system’s file open library call. If we get a valid file handle back, we process the file. If that file handle is nil then we process it as an error (what ever that is).
On OS-X and Windows if the file is Bubba.PNG and we ask for bUbBA.pnG, we get a valid file handle. This is a well known issue. It’s something we could spend a lot of energy trying to address, but the purpose of the simulator isn’t to be a realistic device but a rapid development tool. We could spend years trying to solve this.
Rob
@All,
I have a solution for this.
Originally, I thought I’d monetize this, but instead I’ll be giving it away for free so folks can add to it and improve it.
You can find the current solution here:
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2015/01/caseDetectError.zip
https://www.youtube.com/watch?v=AOkAiR-9y-c&feature=youtu.be&hd=1