ShaderInfoDialog

[greebo]

I just committed a new dialog to the DarkRadiant SVN repository, showing the reference count of each shader in the map:

 

 

Maybe this helps finding some solitary textures in the Saintlucia map.

[SneaksieDave]

Great idea.

[Komag]

YES! That is quite awesome!

[greebo]

I'm also planning to do the same for models and merge all three (Map info, shader info and model info) into one dialog with tabs.

[OrbWeaver]

I'm also planning to do the same for models and merge all three (Map info, shader info and model info) into one dialog with tabs.

 

That's an excellent idea; all of these categories of info logically fall under the "map info" umbrella.

 

Now all that's needed is a way to identify all of the associated resources and automagically extract them into a standalone PK4...

[Komag]

Could DR handle selecting/highlighting all those surfaces and patches for a selected texture? It would texture "replacement" a very user friendly affair

[greebo]

Now all that's needed is a way to identify all of the associated resources and automagically extract them into a standalone PK4...

While this would be possible, it wouldn't be enough to create a working FM package out of it. But it would at least be a start - once Tels has finished his package script algorithm, one could take that, move to C++ and incorporate it as a DarkRadiant packaging plug-in. Not a small task, but I'd love to see that.

 

Could DR handle selecting/highlighting all those surfaces and patches for a selected texture? It would texture "replacement" a very user friendly affair

Hm. Yes, I think this would be possible and very similar to Lightwave's Surface Statistics dialog.

 

But first steps first, I'll look into the Model Info first.

[OrbWeaver]

While this would be possible, it wouldn't be enough to create a working FM package out of it. But it would at least be a start - once Tels has finished his package script algorithm, one could take that, move to C++ and incorporate it as a DarkRadiant packaging plug-in. Not a small task, but I'd love to see that.

 

It certainly would be a mammoth task, not least because it's the kind of feature that is completely useless unless it is 100% reliable (similar to code refactoring tools). I can imagine it being hugely popular with mappers though, particularly if it was presented in a sufficiently useable way: maybe a wizard, that allowed you to select multiple maps to package into a single PK4, choose which resources to export (for example, package only models that are found on the disk, while ignoring those in standard PK4 archives), and generate the associated FM stuff automatically.

[sparhawk]

Question is, wether this would be necessary. Standard models, textures, sounds, etc. shouldn't be packaged with an FM later on. Only the ones which are not in the official release.

[Tels]

That's an excellent idea; all of these categories of info logically fall under the "map info" umbrella.

 

Now all that's needed is a way to identify all of the associated resources and automagically extract them into a standalone PK4...

 

perl devel/extract-assets.pl can (could) this.

[Tels]

It certainly would be a mammoth task, not least because it's the kind of feature that is completely useless unless it is 100% reliable (similar to code refactoring tools). I can imagine it being hugely popular with mappers though, particularly if it was presented in a sufficiently useable way: maybe a wizard, that allowed you to select multiple maps to package into a single PK4, choose which resources to export (for example, package only models that are found on the disk, while ignoring those in standard PK4 archives), and generate the associated FM stuff automatically.

 

Somehow I get the impression you have managed to overlook my work of the last months.... *sigh*

[New Horizon]

Somehow I get the impression you have managed to overlook my work of the last months.... *sigh*

 

Have you implemented these features in C++ within DR? I am pretty sure that's what they're talking about.

[Tels]

Have you implemented these features in C++ within DR? I am pretty sure that's what they're talking about.

 

No, but in what language and in what framework it is implemented is a "technical detail". First and foremost we need to solve the "make a diff between a base and a (multiple) FM" and find out what all needs to be packaged up.

 

Without that problem solved 100% (and not just 99% as Sparhawk rightfully noted), it doesn't really matter where and how we implement it, as it would be useless.

 

Also, as someone else noted, that feature isn't really useful for FM authors, anyway, as they will rarely add or modify resources and can package these manually into their PK4 file. (heh, it worked for Thief's Den

[OrbWeaver]

Have you implemented these features in C++ within DR? I am pretty sure that's what they're talking about.

 

Indeed.

 

First and foremost we need to solve the "make a diff between a base and a (multiple) FM" and find out what all needs to be packaged up.

Without that problem solved 100% (and not just 99% as Sparhawk rightfully noted), it doesn't really matter where and how we implement it, as it would be useless.

 

Which is exactly what I said, so it seems we agree.