Content app builds my files just fine, fine as always… Added a shader/effect via content tool menu, then moved the file around, deleted it, game will not launch at all…
I have not EVEN modified my game code, I just added a blank/new shader to the project, did NOT load it or use it in code, then moved the file and deleted it, and the game crashes…
-I have seen this error before, where my only fix was to create a new project with a new name, and copy paste all my code, and re-import all assets… A HUGE chore…
Does anyone have ideas? How do I clean away any change I may have caused by tampering with the content files… I get no errors. Just failed to build.
Game launches fine from executable in folder… Not working in visual studio.
When you use the MGCB Editor to add a new content file, like a shader, the editor is just a GUI tool that edits the Content.mgcb file.
One of the NuGets packages that is part of MonoGame projects is the MonoGame.Content.Builder.Task package. This package adds a task to the project build step that will (1) build the content xnbs as described in the Content.mgcb file and (2) copy those built assets to your projects build output directory.
So if im reading your post currently, it sounds like you used the MGCB Editor to create the new shader file, which again the editor just makes edits to the underlying Content.mgcb file and adds an entry in it to process that file. Then you moved/deleted that file directly and not through the MGCB Editor.
Because of this, your Content.mgcb file was never updated to now exclude that content file you moved. In turn, when you build your project, the MonoGame.Content.Builder.Task attempts to build the Content.mgcb file which is now referencing a file that has been moved, so it throws an error.
In your use case, it might be beneficial to look into one of the third party libraries that automate the content stuff for you without the need of the MGCB Editor. These libraries work by detecting files simply added or removed from the content directory. They are linked below.
Aristurtle is absolutely right. However if you appreciate the content tool and want to continue using it, just make sure to update it when you move/rename/delete files. Remove the reference to the old file and add the new one, because the content tool (or really the underlying content config file) needs to know about all of your content files, and if you move a file without telling it then it will break.
Thanks so much both of you, after so many hours last night of pulling out my hair, it feels good to feel understood by somebody.
I think there are some deep implications of this I am missing, like it’s not connecting.
It’s like back in 1995, when I learned what the difference between a file and a shortcut was.
-I thought I could put the shortcut to a game on a floppy, and thus invent pirating cd rom games on disks, like a genius.
I remember this being a mystery for me always… It’s like I can use the content pipeline, following instructions, but if something goes wrong, I clearly have no foundational knowledge to trouble shoot the issue…
If it’s outside the scope of my code logic, I have no clue what’s happening.
I honestly can’t explain why I cant just have a folder with my code text files, and a folder with content I collect over the years, and a folder near my exe with pre-compiled shaders and xnb content…
Like I don’t even understand why this needs to be harder than using windows even…
You can open the Content.mgcb file with your text editor to see what it looks like without the GUI tool. More info about how to read the text file here: https://docs.monogame.net/articles/tools/mgcb.html.
It’s quite possible there’s still some stuff about that shader in there.
On a side note to everything above, be sure to have your projects backed on git (github or gitlab or any other solution they are all fine) and before doing any refactoring changes like shuffling files around or changing projects structure, be sure to commit and push everything.
That way if you mess up your files and don’t know how to recover your project back into working state, you can just revert and retry the process. Worst case you’ll only lose the refactoring work.
So my code runs now, from the editor… I can insert a break-point, tweak the code, and resume running.
But then the editor wont let me insert another break-point…
“the source code is not the same as the original version”…
And for changes in my code to take effect, I have to stop the program, and restart it.
This is new and annoying behaviour. There must be some setting in the editor, or the solution explorer, or something?
This is just how debugging is in c#. When you start a debug session it has to compile the current code with symbols, run it, then attach a debugger to it.
If you make changes in the middle of a debug session, it will need to recompile those changes with new symbols to update itself.
You may have some success with the new Hot Reloading in Visual Studio, but i can’t say for sure since i dont use it or Visual Studio.
I used to be able to insert a break-point, or even just “pause” the code, make changes, and resume the game… at least in debug mode… in release mode, i had to re-load the game… I don’t know why that has changed, and now it says “source code is not the same as original”…
wierd…
With VS you can breakpoint, edit and continue 90% of the code, there are some exception, stackallocs prevent doing that in local scope, for unsafe code it is often no go, etc.
Hey I think I ran into something like this before but I’m not sure if it’s the same issue.
Do a diff of your .mgcb files from your project that doesn’t work and the new project you create that does work. Are there any differences that aren’t just content files, specifically a header at the top of the file?
I had a problem where some file decoration changed and it made my content not build with some error, but when I manually edited the file to restore it I was able to recover.
Sometimes I wish Microsoft would just integrate this XNA project of theirs right into VS, and just manage all the backend stuff using some smart intellisense-like content management system…
Write code, drag and drop or delete content, click publish…
I don’t know how you guys learn all this stuff, APIs and github, .net and nuget packages… I have no idea what any of it is, I just declare variables, and change values, and draw pictures on coordinates…
EXACTLY like you would do if working on a bill-board, and you had to tell a friend how to do it physically.
It’s like coding has an allure, but all the stuff making that happen is just intangible. There is a huge barrier of entry… - Especially considering how much time it already takes, just making content, and writing game logic and shaders… Maybe you guys who know these things have degrees?
In this context, a header is just some info that comes at the start of a file that provides information or configuration settings. Really though, don’t worry about the label, just look at the file contents. If you’re writing a game using MonoGame, your ability to read code-like files should be strong enough, or it’s a skill you’re clearly intent on developing. So try not to let yourself get discouraged here
Put simply, take your .mgcb file that doesn’t work and diff it against one that does (using WinDiff, Beyond Compare, or any file diffing tool). You should be able to tell what is what by just making an educated guess, so look for things that are out of place.
Worst case, post both versions of the file in your next message and I can take a look for you. This may not be the problem (at which point I don’t have any further thoughts), but it’s worth a shot.
It’s something I used since like 2017, but I know to some people it looked like magic, guess something wrong with their project setups? It just worked for me, so never really dived into it.
See, this is what I’m talking about… We all have YEARS of experience, and there are still very basic things we can exchange thoughts on… Like breakpoints even.
A large part of the world outside the scope of my game-logic, is just fog, I bet everyone feels that to some degree… Nobody can turn sand into a programmed computer on a network… Everyone does some small part of it… Is what I tell myself.
