Discussion Is anyone else having problems with game maker ignoring .ini included files?

[MilesThatch]

Got a lighting system that saves the all the lights of the level into an .ini file. I grab that file, included it and use a function in an master lighting object "instance creation code" to read all the light properties and re-generate all the lights.

So here's the deal, the ini files that the game outputs with all the lights data is saved into the %appdata% folder using the room name as the file name. So I get "Level001lights.ini" I take the file, include it, add it with the function in the creation code of the light master object and the light are re-created. Now I figure I need a few more lights and some changes made. If I added a couple of lights, I'd just save the new ini file, open it, copy the contents, then, in game makers included files, right click > edit the existing ini file, delete everything and then paste the copied text there. Game Maker will then prompt that the file has been changed and asks whether you want to re-load it so that changes are taken in or to save it so that changes are overwritten with what was in the file before I pasted the content.

Now the problem tho is that those changes aren't showing up in the game, those new lights are not showing up. Instead I am forced to create a custon blank ini file, call it something different like "Level001lights-new01.inf" and put that file name in the creation code to load the files. The changes now showed up but I thought this was strange, game maker refusing to take in the changes of the ini file even though it prompted that changed were made... Now mind you, I did try the "clear target platform" button.

So ok, I did the above mentioned and the new lights with the changes showed up, so I try something. I check both ini files "Level001Lights.ini" and "Level001Lights-new01.ini" and they are both identical. I go into the %AppData% folder of the game where it saved the ini files originally, delete them.... and now all the loghts are gone. WHAT IS GOING ON HERE I think. Does game maker read files from the project directory or the game folder in %appdata% ? Maybe I'm missing something, maybe I'm supposed to save the included ini files into the %appdata% folder before accessing them. This is very confusing. All I can do now, to get the new lights working is to include a blank ini file, call it something new, this time "Level001Lights-new02.ini" and copy the data there. So every time I make a change I'd have to rinse and repeat going into "-new03" "-new04" etc. instead of just opening the original ini file and pasting the new config text there.

 

[Nocturne]

What you are doing sounds correct (add the files as included files then editing them). It could be that the cache is preventing the updated files from being used, so after changing the included file contents click on the clean cache button at the top of the IDE and then try and build.

 

[MilesThatch]

What you are doing sounds correct (add the files as included files then editing them). It could be that the cache is preventing the updated files from being used, so after changing the included file contents click on the clean cache button at the top of the IDE and then try and build.

Yep, as I mentioned, I tried to the "clear cash" button by the compile button up top left. Let me see if rebooting the IDE does anything.

 

[Nocturne]

If the behaviour persists, then please file a bug as the IDE should pickup changes to the included files I'm sure.

 

[MilesThatch]

@Nocturne Ok so I just tried something for the sake of seeing what will happen. I still have the copied text with all the lights configurations of the room.

I included a blank ini file in game maker. Called it "Level001TestLights.ini"
I put that name into the function which reads that included file and creates all the lights.
I Right Click > Edit on the ini file from within game maker and pasted the text with the configuration.
Compiled the game - not working, nothing's showing up.
Now here's the kicker. I went into the %AppData% folder and created a blank ini file. Also called it "Level001TestLights.ini" and pasted the text into that.
Compiled the game, now the LIGHTS ARE WORKING!
And now the punchline - I went back to game maker, deleted the included "Level001TestLights.ini" file and compiles. LIGHTS ARE STILL THERE!

So maybe I didn't code the file access properly. Maybe the

ini_open(file);

first prioritizes the files located in the local storage of the application instead of the included files?

The re-generation of lights is handled by a script I wrote. The code the loads the ini file:

file = argument0;

ini_open(file);

so where the argument0 would be "Level001TestLights.ini"

 

[Nocturne]

I use included files all the time, and I edit them all the time too.... and I've not seen this issue! When I edit an included file GMS asks me to reload it, which I do, and then it uses this new file. This is a weird issue that you're getting, which is why I think you should file a bug...

One thing though! Is it the same project that generates the lightmap INI file as the one you are having issues with for loading it? If so then that may be the issue... If you include a file with GMS it will go to one location on the PC and then if you create a file with the same name, it won't overwrite the included file but instead go to a different location so you'll have two files with the same name located in different places, and GMS will use the one generated by the game and NOT the one used as the included file (or at least that's what's supposed to happen ). You can find a more complete explanation here: http://docs2.yoyogames.com/index.ht...iew/3_additional_information/file_system.html

 

[MilesThatch]

I use included files all the time, and I edit them all the time too.... and I've not seen this issue! When I edit an included file GMS asks me to reload it, which I do, and then it uses this new file. This is a weird issue that you're getting, which is why I think you should file a bug...

One thing though! Is it the same project that generates the lightmap INI file as the one you are having issues with for loading it? If so then that may be the issue... If you include a file with GMS it will go to one location on the PC and then if you create a file with the same name, it won't overwrite the included file but instead go to a different location so you'll have two files with the same name located in different places, and GMS will use the one generated by the game and NOT the one used as the included file (or at least that's what's supposed to happen ). You can find a more complete explanation here: http://docs2.yoyogames.com/index.html?page=source/_build/1_overview/3_additional_information/file_system.html

Yes I've made a lighting engine that allows you to build the lighting for your levels directly in a game, so when you save the lights to an ini file, it's indeed the game that generates the file. So perhaps you are right and Game Maker really does proritize the files created in the %AppData% folder over the included file. But that's a very strange behavior. The only thing is that if I have the file as included resource and delete the same file from %appdata% then it won't switch back to using the included file, it just seizes to read it all-together. This has been going on for a long time too, not sure how this hasn't been caught by now. Guess it's up to me to file the bug report.

 

[Nocturne]

But that's a very strange behavior.

It's designed for you to create "default" files for things then be able to overwrite them without actually deleting them. For example, you have a GameOptions.ini that contains the default settings for your game and you include it in the EXE. The player then changes the settings so the game saves the GameOptions.ini to local storage with the new settings and uses that... the user then wants to go back to the default settings so clicks the reset button and the game deletes the GameOptions.ini from local storage, and will use the original included ini file again as the default (this cannot be deleted).

 

[MilesThatch]

It's designed for you to create "default" files for things then be able to overwrite them without actually deleting them. For example, you have a GameOptions.ini that contains the default settings for your game and you include it in the EXE. The player then changes the settings so the game saves the GameOptions.ini to local storage with the new settings and uses that... the user then wants to go back to the default settings so clicks the reset button and the game deletes the GameOptions.ini from local storage, and will use the original included ini file again as the default (this cannot be deleted).

Oh so I was only half way there. So I really should just have game maker first save the included file into the appdata folder and only then access it for building the lights. Got it. Any idea how I can do that? I'm sure I can figure it out by tinkering, just figured as long as we're on the subject. How do I save the file from the included directory into the appdata one?

 

[Nocturne]

How do I save the file from the included directory into the appdata one?

I'm pretty sure just doing a file open then a file_save would achieve this. You may need to add a character to the file though... not sure how optimised that pipeline is...

 

[MilesThatch]

I'm pretty sure just doing a file open then a file_save would achieve this. You may need to add a character to the file though... not sure how optimised that pipeline is...

I don't suppose there is a way to just read the included file without first saving it into %appdata% or maybe there is still a slim chance that it's still a bug?

 

[MilesThatch]

When I do

ini_open("filename.ini");
ini_close();

With filename.ini being the name of the included file... it doesn't save that file into the &appdata& folder. Doesn't appear there. Something's missing.

Another thread from 1.4 stated this:

As far as how GM:S's sandboxing, the way you would accomplish this is by creating your text files externally, and then drag it into the "Included Files" section. If you want to open a particular text file, you would use "file_text_open_read("game_text.txt");". You don't have to add "working_directory" or anything of the sort, since it's considered part of the game file.

So basically this is THE way to open included files so this must be a bug.

 

[MilesThatch]

Hey, @Nocturne I just figured out the problem. It actually really is a bug! It seems that game maker ignores the INI file if it's located in a group folder of the "included files" instead of in the root of the "Included file" section. So if, in Game Maker Studio 2, you will create a group folder and place the ini file there, game maker will ignore it. I've just found this out by moving the ini file in and out of the group folder just to see if that was it. So that's definitely a bug, would you and @Eisenhans mind testing this on your end? I've sen't a bug report before stumbling onto this clue so I don't know if there's a way to edit the bug submission.

EDIT 1: I've just also found out that you can add the group name as a part of the file path and it will open the file. I'm guessing that might be an included file only thing. None of the other resources like sprites, sounds, objects etc require this, just the resource name is enough. So At least it's working now and I can still keep the ini files organized, not sure if this is a feature or a workaround.

So instead of:
scr_build_lights("room_trial_story_001.ini");

Go with:
scr_build_lights("Trial_Course_6/room_trial_story_001.ini");

 

[Eisenhans]

It.. actually makes sense that you need to include the "group path", so to speak. The bug is probably that it's undocumented. Good work finding it, I imagine others will bump into this as well.

A use case could be this for example: you have a lot of objects that need values. Each object has several INIs, defining different stuff (for example: spawn timings, and intrinsic values, such as gold, energy, whatever).
Now, you might want to have each of these INIs have the same name for each object. And by that group path mechanic, you can. I just tested it, 2 INIs with the same name, but different content, in different groups - works.

If the groups didn't have an impact on the path, there would be a collision. Because "name.ini" and "group/name.ini" would resolve to the same file. Which they should not and they don't currently. So everything is right, it just needs to go into the manual.