Adam's Lair Forum

game development and casual madness
It is currently 2020/02/23, 22:19

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: 2014/10/29, 11:41 
Forum Addict
Forum Addict
User avatar

Joined: 2013/09/19, 14:31
Posts: 883
Location: Italy
Role: Hobbyist
... and it was not as difficult as I thought - for now.

Everything seems to be working properly, except for a couple of things that irk me (and I can't understand where I should look).

as you can see
Image

I added some resources with their nice icon and stuff, but unfortunately when I create them via drag&drop (stuff, test), they appear in the Project View as "unknown" files (even though they look all right in the Object Inspector), while if I create them using the context menu they appear correct (XmlData).

As I said, unfortunately I can't understand what's going on :D

Besides this, I will try to add a custom property editor for the new Resources, in order to display a bigger portion of the content, or maybe add a button that will open a small dialog with a textarea.

Lastly, I let myself introduce all these new things directly in the editor, trying to follow your coding style as much as possible. I think they are generic enough that might be useful to other people as well (I'm thinking translations, dialogs, structured and unstructured data - xml, csv, ...). If you feel like it, I could commit them to a branch and let you check if you want to merge them into the main one.

_________________
Come on Duality's Discord channel. We have cookies! :mrgreen:


Top
 Profile  
 
PostPosted: 2014/10/29, 21:06 
Site Admin
Site Admin
User avatar

Joined: 2013/05/11, 22:30
Posts: 2073
Location: Germany
Role: Professional
SirePi wrote:
I added some resources with their nice icon and stuff, but unfortunately when I create them via drag&drop (stuff, test), they appear in the Project View as "unknown" files (even though they look all right in the Object Inspector), while if I create them using the context menu they appear correct (XmlData).


As you can see here, the editor determines the Type of not-yet-loaded Resources via file name, which works like this. In short: All Resources file names need to have a .X.res pattern, where X is the name of the Resource class. Make sure you name those Resources correctly when importing and saving them!

SirePi wrote:
Besides this, I will try to add a custom property editor for the new Resources, in order to display a bigger portion of the content, or maybe add a button that will open a small dialog with a textarea.


Just one suggestion from me, as a user: I will probably never edit the XML from within Duality and it will be overwritten on ReImport anyway. Consider entirely hiding the XML Resources content instead: Just apply an [EditorHintFlags(MemberFlags.Invisible)] to the Property :)

SirePi wrote:
Lastly, I let myself introduce all these new things directly in the editor, trying to follow your coding style as much as possible. I think they are generic enough that might be useful to other people as well (I'm thinking translations, dialogs, structured and unstructured data - xml, csv, ...). If you feel like it, I could commit them to a branch and let you check if you want to merge them into the main one.


I agree that this may be useful to a lot of others, but it's already getting hard for me alone to manage all those default plugins and examples in the one main repository. So while I indeed think that this has potential as a useful Duality plugin, I would prefer not to be the one responsible for maintaining it :)

So here's a suggestion:

  1. Create an all-new and shiny GitHub repository distinctly for this plugin bundle (Core + Editor), and just reference the required Duality Assemblies via NuGet. That's where the Package Manager pulls all of its packages from, so you'll be building against the latest public binary release.
  2. Create NuGet packages for your plugin bundle (One package for Core, one for Editor) similar to the default Duality packages.
  3. Push that NuGet package and everyone can easily download / add your plugins to play around with. You can set your GitHub repository as a website and documentation link for these packages so others can get back to you.

Feel free to take a look at the package specifications for Duality's default packages for reference.

Hope this helps.

PS: I know, I'm usually the first one to answer most questions here, but can you maybe not address me directly in the topic description? :D I mean.. at least give everyone else a chance to help :D

_________________
Blog | GitHub | Twitter (@Adams_Lair)


Top
 Profile  
 
PostPosted: 2014/10/29, 21:24 
Forum Addict
Forum Addict
User avatar

Joined: 2013/09/19, 14:31
Posts: 883
Location: Italy
Role: Hobbyist
Adam wrote:
As you can see here, the editor determines the Type of not-yet-loaded Resources via file name, which works like this. In short: All Resources file names need to have a .X.res pattern, where X is the name of the Resource class. Make sure you name those Resources correctly when importing and saving them!

Just one suggestion from me, as a user: I will probably never edit the XML from within Duality and it will be overwritten on ReImport anyway. Consider entirely hiding the XML Resources content instead: Just apply an [EditorHintFlags(MemberFlags.Invisible)] to the Property :)


Thanks, I'll give a look at that

Adam wrote:
I agree that this may be useful to a lot of others, but it's already getting hard for me alone to manage all those default plugins and examples in the one main repository. So while I indeed think that this has potential as a useful Duality plugin, I would prefer not to be the one responsible for maintaining it :)

Ah, didn't think of that.. sorry :redface:

Adam wrote:
PS: I know, I'm usually the first one to answer most questions here, but can you maybe not address me directly in the topic description? :D I mean.. at least give everyone else a chance to help :D

Sorry again :redface: :redface:

_________________
Come on Duality's Discord channel. We have cookies! :mrgreen:


Top
 Profile  
 
PostPosted: 2014/10/29, 21:32 
Site Admin
Site Admin
User avatar

Joined: 2013/05/11, 22:30
Posts: 2073
Location: Germany
Role: Professional
SirePi wrote:
Adam wrote:
I agree that this may be useful to a lot of others, but it's already getting hard for me alone to manage all those default plugins and examples in the one main repository. So while I indeed think that this has potential as a useful Duality plugin, I would prefer not to be the one responsible for maintaining it :)

Ah, didn't think of that.. sorry :redface:

Adam wrote:
PS: I know, I'm usually the first one to answer most questions here, but can you maybe not address me directly in the topic description? :D I mean.. at least give everyone else a chance to help :D

Sorry again :redface: :redface:


np :D

_________________
Blog | GitHub | Twitter (@Adams_Lair)


Top
 Profile  
 
PostPosted: 2014/10/30, 12:37 
Forum Addict
Forum Addict
User avatar

Joined: 2013/09/19, 14:31
Posts: 883
Location: Italy
Role: Hobbyist
Adam wrote:
As you can see here, the editor determines the Type of not-yet-loaded Resources via file name, which works like this. In short: All Resources file names need to have a .X.res pattern, where X is the name of the Resource class. Make sure you name those Resources correctly when importing and saving them!


Thanks, that fixed it.

But I was wondering, in this case wouldn't it be easier/safer to simply have a property inside Resource.cs like this:

Code:
public string FileExt
{
  get { return String.Format(".{0}.res", this.GetType().Name); }
}


instead of having to redefine FileExt for each Resource type?

_________________
Come on Duality's Discord channel. We have cookies! :mrgreen:


Top
 Profile  
 
PostPosted: 2014/10/30, 14:03 
Site Admin
Site Admin
User avatar

Joined: 2013/05/11, 22:30
Posts: 2073
Location: Germany
Role: Professional
You're right that the ideal solution would be a Property that uses Reflection to determine the name automatically according to this scheme. The problem however, it that this requires an object instance, but I sometimes want to know a Resources file extension without having an instance. So that leaves me with only static and const members and without the option to implement this easily in the base class.

Still, I have replaced the existing const Fields with static readonly Fields that invoke a base class method to determine the correct exstension. So instead of this:

Code:
public new const string FileExt = ".AudioData" + Resource.FileExt;


The default way to do so is this:

Code:
public new static readonly string FileExt = Resource.GetFileExtByType(typeof(AudioData));


Although the method was already existing, it wasn't yet used for the static file extension info fields. Also, readonly fields are more flexible with regard to forward compatibility, because those constants will simply be copied into every plugin compiling against a certain Duality version, while readonly fields will "auto-update" because of the runtime access.

Thanks for pointing this out!

_________________
Blog | GitHub | Twitter (@Adams_Lair)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group