[Tiled] MGCB not handling reference properly

[kaltinril]

I'm not sure if I'm missing a step, or if I'm doing something wrong, but after I add my MonoGame.Extended.Content.Pipeline.dll in the editor (before I save/close the editor) I can add a tmx file and change it's content processor to tiled, but once I save and close it, the tmx reference dissappears from the content.mgcb file, and when I open it again, the editor displays an odd folder path, as if it's trying to load the reference like a content asset?

[blank folder]
-> [build=]

• -> [build=]
• • -> MonoGame.Extended.Content.Pipeline.dll

Fresh brand new project (MonoGame.Framework.DesktopGl)
VS 2019
.net core 3.1.420 installed along with 5.0.408
MonoGame.Extended 3.8.0
MonoGame 3.8.0.164

Complete Content.mgcb file:

#----------------------------- Global Properties ----------------------------#

/outputDir:bin/$(Platform)
/intermediateDir:obj/$(Platform)
/platform:DesktopGL
/config:
/profile:Reach
/compress:False

#-------------------------------- References --------------------------------#

/reference:..\..\..\..\Users\myusername\.nuget\packages\monogame.extended.content.pipeline\3.8.0\tools\MonoGame.Extended.Content.Pipeline.dll

#---------------------------------- Content ---------------------------------#

#begin Levels/level1.tmx
/importer:TiledMapImporter
/processor:TiledMapProcessor
/build:Levels/level1.tmx

Before:

After:

Error if trying to "build" with no content":

However, if I add a tmx file, it shows me all the Extended content importers, but fails to build still:

Project structure:

[kaltinril]

UPDATE: I copied MonoGame.Extended.Content.Pipeline.dll to the root of the project in the solution, and referenced it there instead.

Now the reference stays put, however, when I add a TMX file, there is no option for Tiled in the Importer.

[sandord]

I think that a relative path to the MonoGame.Extended.Content.Pipeline.dll cannot be determined when your repository is not located under C:\Users\myusername.

In my case, I'm using the exact same location for the repository (C:\Git) and I'm suffering from the same problem you're having.

Since MonoGame.Extended.Content.Pipeline.dll is a NuGet tool, it isn't copied to the bin directory when the .NET project is built. This means that we'll need to reference it in the .nuget directory, which is located under C:\Users\myusername by default. But, since our repository isn't located under C:\Users\myusername, we'll need to include C:\Users\myusername in the path because we can't reach like we otherwise could've done using a relative path that stays inside the user directory.

Having your username hardcoded in a path is of course unacceptable (especially if you're sharing code across machines or with other people) but I have no idea how to work around this without moving my repository somewhere under C:\Users\myusername (e.g. Documents\Git).

If you were to move your repository, you shouldn't need to copy the dll to your project root anymore and use the following reference instead:

/reference:..\..\..\..\.nuget\packages\monogame.extended.content.pipeline\3.8.0\tools\MonoGame.Extended.Content.Pipeline.dll

I took the reference from this demo. You might need to adjust the number of ..\s to match your situation.

[kaltinril]

Was this resolved ever or is it still in a work-around status?

[AristurtleDev]

@kaltinril can you try one of the following and confirm if this is resolved now

1. Use the source code of MonoGame.Extended directly and reference it in your project
2. Use the most recent (at the time of writing this) prerelease NuGet https://www.nuget.org/packages/MonoGame.Extended/3.9.0-prerelease.4

[tomislav12]

@AristurtleDev Installing 3.9.0 from NuGet does not help. I get "Processor 'TiledMapTilesetProcessor' had unexpected failure!" and some other errors as well:

EDIT: It work now. I had to change reference to 3.9.0 dll

[AristurtleDev]

EDIT: It work now. I had to change reference to 3.9.0 dll

@kaltinril so everything is good? Good to close this issue out?

[kaltinril]

I'll have to check I think I did a work around I don't recall this was 2 years ago. Jeremy Swartwood

…

On Wed, May 29, 2024, 2:02 PM Christopher Whitley ***@***.***> wrote: EDIT: It work now. I had to change reference to 3.9.0 dll @kaltinril <https://github.com/kaltinril> so everything is good? Good to close this issue out? — Reply to this email directly, view it on GitHub <#774 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGDTEFNSOXVHM34DOH72ULZEZGAHAVCNFSM5Z3JXGRKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTHAZTGMZQGI3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AristurtleDev]

Oh sorry @kaltinril i thought the reply above was from you but it was from @tomislav12 , my mistake.

but you were the original issue opener, if you don’t mind checking as well that would be great so we can close out the issue

[kaltinril]

I'll check tonight after work

…

On Wed, May 29, 2024, 2:45 PM Christopher Whitley ***@***.***> wrote: Oh sorry @kaltinril <https://github.com/kaltinril> i thought the reply above was from you but it was from @tomislav12 <https://github.com/tomislav12> , my mistake. but you were the original issue opener, if you don’t mind checking as well that would be great so we can close out the issue — Reply to this email directly, view it on GitHub <#774 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGDTEFEXSCUOPOCLWOOJPDZEZLB7AVCNFSM5Z3JXGRKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTHAZTONRWGY4A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kaltinril]

Sorry I was busy with family and forgot to check, plan is to validate tonight. On Wed, May 29, 2024, 2:46 PM Jeremy Swartwood ***@***.***> wrote:

…

I'll check tonight after work On Wed, May 29, 2024, 2:45 PM Christopher Whitley < ***@***.***> wrote: > Oh sorry @kaltinril <https://github.com/kaltinril> i thought the reply > above was from you but it was from @tomislav12 > <https://github.com/tomislav12> , my mistake. > > but you were the original issue opener, if you don’t mind checking as > well that would be great so we can close out the issue > > — > Reply to this email directly, view it on GitHub > <#774 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABGDTEFEXSCUOPOCLWOOJPDZEZLB7AVCNFSM5Z3JXGRKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTHAZTONRWGY4A> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[kaltinril]

Alright, sorry for the delay.

I am getting similar or same issues. Perhaps I am not setting up the project correctly.

Here are the steps to reproduce the issue:

1. Open VS 2022
2. Create a new MonoGame Cross Platform Desktop Project
   1. (I did notice documentation states extended doesn't work with monogame 3.8.1.303 on the github page getting started for extended, so perhaps I am not doing a valid test? I'm hoping this development build does)
3. Once the new solution/project opens, press play to verify it compiles and runs.
4. In the PM window, I CD'd down to the folder containing the project to avoid the error "Could not find any project in ...path"
5. I installed the following nuget packages per extended.tiled documentation:
   1. dotnet add package MonoGame.Extended --version 3.9.0-prerelease.4
      1. From this page https://www.monogameextended.net/docs/getting-started/installation/
   2. dotnet add package MonoGame.Extended.Content.Pipeline --version 3.9.0-prerelease.4
      1. From this page https://www.monogameextended.net/docs/getting-started/installation/
   3. dotnet add package MonoGame.Extended.Tiled --version 3.9.0-prerelease.4
      1. https://www.monogameextended.net/docs/features/tiled/
6. I then followed the steps under section Using the MonoGame Pipeline GUI
   1. From this page https://www.monogameextended.net/docs/getting-started/installation/

At this point, I copied a TMX file into the directory and opened the MGCB editor again, and it doesn't show the Importer or processor for TMX files, and it has the odd build= build= folder structure.

So I can only assume:
A) I did something wrong
B) or, it's still broken.

Please let me know what steps I'm doing wrong, or, missing.

EDIT: I just checked and the MGCB editor is version 3.8.0.1641 and it says its "mgcb-editor-wpf" in open with. I ran dotnet tool restore from the project sub-folder, and it shows dotnet-mgcb-editor is available with command dotnet mgcb-editor. I ran this command from the project folder and it opened version 3.8.1.303 and the help says "MGCB Editor" instead of "wpf". However, even this tool has the same issue/behavior.

If it helps...

Here is the actual PATH
C:\Users\username\.nuget\packages\monogame.extended.content.pipeline\3.9.0-prerelease.4\tools

And the entry that the GUI adds to my content file:
/reference:........\Users\username\.nuget\packages\monogame.extended.content.pipeline\3.9.0-prerelease.4\tools\MonoGame.Extended.Content.Pipeline.dll

Here is where my solution file lives:
C:\git\mge_tiled_learning2\mge_tiled_learning2.sln

Here is where the project file lives:
C:\git\mge_tiled_learning2\mge_tiled_learning2\mge_tiled_learning2.csproj

[kaltinril]

Alright, I got it to work, but essentially this issue break down to 1 thing:

The attempt to use "relative paths" to move up and then back down to the files.

How I got it working:

1. Manually edit the Content.mgcb file to remove the ........\ and just put c:\ instead
   1. BROKEN: /reference:..\..\..\..\Users\username\.nuget\packages\monogame.extended.content.pipeline\3.9.0-prerelease.4\tools\MonoGame.Extended.Content.Pipeline.dll
   2. WORKING: /reference:C:\Users\username\.nuget\packages\monogame.extended.content.pipeline\3.9.0-prerelease.4\tools\MonoGame.Extended.Content.Pipeline.dll
2. That then made it so the Editor could finally see the dll and would allow me to build, but it failed because the Tiled tsx file was also using ../../../ etc I fixed this the same way, by hard coding the c:/
   1. BROKEN: ../../../Users/username/Downloads/assets-6a3b3a06d9df585805d29f6f45628bcd/tiled/[Base]BaseChip_pipo.png
   2. WORKING: C:/Users/username/Downloads/assets-6a3b3a06d9df585805d29f6f45628bcd/tiled/[Base]BaseChip_pipo.png

[AristurtleDev]

Thanks for responding back @kaltinril

Unfortunately the relative pathing issue that's created in the Content.mgcb file is how the MGCB Editor choose to add the path. It's not something that can be managed from the MonoGame.Extended side.

The documentation needs to be updated to better inform about setting up a nuget.config file to get the package to download locally to the project instead of the obscure nuget global directory cache.

However, I have plans to automate this in 4.0 so I don't think it will be an issue in the future.

As for having to edit the tsx file, this is also a Tiled thing. I can think of a few ways to resolve it on the MonoGame.Extended side, but better documentation is needed for that.

I'm going to keep the issue open for now and mark it as documentation.

[kaltinril]

Yep, makes sense, I don't think it was ever clear that was a majority of the issue. It was also a bit confusing finding all the places things I needed to do to add the packages and references. Felt a bit scattered trying to find the steps amongst different pages. I'll have to play with it now that it's working. The issue stopped me from moving forward with my plans when I opened the ticket. I got sucked into the mind cycle process of "do I just write my own loader, or should I write my own file format, or should I use a simpler map format, or should I use a different tool". In the end I just gave up and went on to other things hehe. If I get it all working I'll trying to create my next video about using tiled + extended with monogame. Extended has so much it does that it's almost a waste not to use it's features. "why reinvent the wheel". So I want to use extended where it makes sense. Thanks for looking into it. Final thoughts: 1. What change was made in this dev version? 2. Is extended sticking around? 3. When's the plan for ditching the content pipeline? (or has that changed)

…

On Fri, Jun 7, 2024, 7:52 AM Christopher Whitley ***@***.***> wrote: Thanks for responding back @kaltinril <https://github.com/kaltinril> Unfortunately the relative pathing issue that's created in the Content.mgcb file is how the MGCB Editor choose to add the path. It's not something that can be managed from the MonoGame.Extended side. The documentation needs to be updated to better inform about setting up a nuget.config file to get the package to download locally to the project instead of the obscure nuget global directory cache. However, I have plans to automate this in 4.0 so I don't think it will be an issue in the future. As for having to edit the tsx file, this is also a Tiled thing. I can think of a few ways to resolve it on the MonoGame.Extended side, but better documentation is needed for that. I'm going to keep the issue open for now and mark it as documentation. — Reply to this email directly, view it on GitHub <#774 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGDTEHN6ZPIMHNWTUYXACTZGHJKTAVCNFSM6AAAAABIXIQIE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJVGEYDOMJVGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AristurtleDev]

To answer your questions

1. What change was made in this dev version?

There's been some changes made, mostly structural project changes, but also a few bug fixes. You can find all the information in the new change changelog as I'm working through things https://github.com/craftworkgames/MonoGame.Extended/blob/develop/CHANGELOG.md

2. Is extended sticking around?

Yea, extended is sticking around. The previous maintainer was unable to commit time to the project, and the backlog kinda pilled up. I've taken ownership of the project now and am working through the backlog of known issues and bugs to get a new release out so it's up-to-date with current MonoGame 3.8.1.303. You can track the progress for that here https://github.com/orgs/craftworkgames/projects/6/views/1

3. When's the plan for ditching the content pipeline? (or has that changed)

The content pipeline is a controversial topic within the MonoGame community in general. However, despite this, many users still use it and it's not going away in the main MonoGame repo as far as I know. So support for the pipeline will remain, however it will most likely move to being a second class citizen within MonoGame.Extended. What I mean by this is the functionality to load and/or preprocess various asset types should exist on its own, without the pipeline first and foremost.

This is something I've done in other MonoGame libraries I maintain, and allows users to choose if they want to incorporate the asset preprocessing into their own custom workflow or hook it into the MonoGame pipeline.