Support <Link> content in MGCB and Pipeline tool

[tomspilman]

In XNA you could do the following in a content project:

    <Compile Include="..\..\..\art\gfx\wood.PNG">
      <Link>gfx\wood.PNG</Link>
      <Name>wood</Name>
      <Importer>TextureImporter</Importer>
      <Processor>TextureProcessor</Processor>
    </Compile>

With this the content pipeline reads the source content from the ..\..\..\art\gfx\wood.PNG path then writes it out to gfx\wood.PNG in the output folder.

When importing this .contentproj into the Pipeline tool we get this:

#begin ../../../art/gfx/wood.PNG
/importer:TextureImporter
/processor:TextureProcessor
/build:../../../art/gfx/wood.PNG

This produces both the wrong output path when building content, but also looks wrong in the Pipeline tool which shows folders for .. which it should never do.

There are multiple things to do to fix this:

1. Add support for links/rename of content on processing.
2. Correctly visualize these links in the Pipeline tool.
3. Support adding linked content in the Pipeline tool.
4. Support importing linked content from .contentproj.

This issue is similar to #4724, #4846, and #4980.

[tomspilman]

As for support in the .MGCB file I think we should do something like this:

/build:../../../art/gfx/wood.PNG;gfx/wood.PNG

... or maybe....

/build:../../../art/gfx/wood.PNG>gfx/wood.PNG

We then just use string.Split() to break the build argument into the two different paths. The source file path and the optional link file path.

[KonajuGames]

I was thinking along the lines of /link:gfx/wood.png /build:../../wood.png The link parameter, if present, would be used for the treeview and intermediate file output. But either option would work.

[tomspilman]

Yeah /link:gfx/wood.png is the most obvious way to do it. For some reason I was thinking this could conflict with other processor parameters, but clearly it would not.

[KonajuGames]

As long as it is before the /build parameter, it should be fine.

[nkast]

We must not forget that mgcb always applies the last parameters. A separate /Link will not be consisted with how other parameters work. Although the pipeline tool generate a verbose .mgcb file, mgcb.exe can support things like:

/importer:TextureImporter
/processor:TextureProcessor
/build:/img/img01.PNG
/build:/img/img02.PNG
/build:/img/img03.PNG

A file like the following implies all 4 files should become wood.xnb,wood0.xnb,wood1.xnb,wood2.xnb

/importer:TextureImporter
/processor:TextureProcessor
/link:gfx/wood.png
/build:../../wood.png
/build:/img/img01.PNG
/build:/img/img02.PNG
/build:/img/img03.PNG

The mbcg will behave strange, we get /clear command that clears all parameters, while /build clears /link parameters. Also the following hand-edit file will be wrong (The user should comment both /link & /Build.)

/importer:TextureImporter
/processor:TextureProcessor
/link:gfx/wood.png
#/build:../../wood.png
/build:/img/img01.PNG
/build:/img/img02.PNG
/build:/img/img03.PNG

IMO, having the link in the /build parameter is better. It's clear that /link should always be paired with the corresponding /build parameter.

[tomspilman]

@nkast That is a good point. Adding the link into the '/build' command avoids all sorts of potential bugs and issues.

[KonajuGames]

That makes sense.

[KakCAT]

I did a modification some time ago which matches Tom's first request modification for the MGCB.exe (build input.png > output.png). Unfortunately I can't use github because of my metered connection.

Here are my changes, just in case somebody finds them useful as starting point:

modified BuildContent.cs: http://pastebin.com/BnvJLSds
diff BuildContent.cs: http://pastebin.com/1vn0HhJT

[tomspilman]

@KakCAT - That seems like a good starting point. Thanks!

[vchelaru]

I'm currently working on this. My solution will allow loading and saving of files with the link appended to the build property as suggested above, plus modifications to the builder to properly build to the right folder.

I don't think I'll get to making changes to the UI tool to allow setting the link property - for this pass it will work if the .mgcb is edited manually.

[harry-cpp]

I'm working on this, it will probably take me till the end of the day to rework some parts of logic inside the Pipeline Tool.

[Phrenotopia]

Has this issue been solved? I'm trying a workaround, but it's not really working yet...

I have problems installing the MonoGame.Content.Builder nuget package into my central project, because the craftworkgames.com server is apparently down?

[harry-cpp]

Has this issue been solved? I'm trying a workaround, but it's not really working yet...

Yes, it has been solved and is included in MonoGame 3.7. You can either manually add 2 filepaths in the build statement separated by : or use the Pipeline Tool and select link option.

I have problems installing the MonoGame.Content.Builder nuget package into my central project, because the craftworkgames.com server is apparently down?

That has nothing to do with us. MonoGame.Extended in general has nothing to do with MonoGame, except its using it. Really unfortunate name choosing tho.