I got several eMails, which were requesting a Ident Feature for the Sim Tools. Since this is a controversial issue, and would cause some work, I would like to get your Opinion about this.

The Idea is seperated in two general parts:

1. Metadata:
Normal Object clones have a Catalog Description (CTSS), which creators can use to add some Descriptions or an URL/eMail people can use to get in touch with the creator (for Bug Reports, donations whatever).
Problem until now is, that this CTSS is not available for Recolor, Hacks, or Skins.
We would like to build a common standard here (maybe even together with Maxis), that would allow us to add CTSS Informations to Recolors and stuff. And (maybe) extend the default Information stored in a CTSS by Creator name, homepage and email (so far only title and descriptions are supported).

This Information could be used by our Sim Tools to have a standardised way of reading package Informations, as well as by download repositiries (as the Exchange or the Downloads Section here at MTS2).

2. The Ident:
This means, that a Creator can add a little Code to each package created with SimPE (and if Team Datgen would like to join us of course with it as well), which would identify her/him as the first one to create the package.

When trying to clone a package with SimPe, that has an Ident which is not the one of the current user, SimPE will warn the User, and ask him to get permission from the creator.
Since the ident is a waek protection, SimPE will not forbid you to Clone without the permission of the original Author, it will only be a Popup Window. Plus: any Author allways has the choice wether or not to add an Ident to the package.

So, let me know what you think

I think it's a wonderful idea Quaxi. There are a lot times where I have objects that I have downloaded and had a problem. Most of the time I forget where I got them from and just have to delete them. So this would be really useful to contact creators about their content.

Sounds like a great idea, though I think the metadata would be more useful than the ident. As you said, users wouldn't not be able to export the stuff anyways. The metadata would be especially useful when creating full sims with custom content, recolors, and skins from meshes that a person downloaded 6 months ago and has no idea who originally created it.

A suggestion for SimPE integration, a plugin to export this CTSS info into html or text, so that creators can paste it into descriptions. I'm not experienced with .NET (my schooling was in unix-style C/C++), but if I get time (I hate mandatory overtime) I'll look over the source code/tutorials on the SimPE site and see what I can do for a plugin, should either of these pursuits come to fruition.

Well, this is actually just a plan on the Shelf, but i was discussing a Plugin with some site owners, that would allow creators to upload their .packages to the Web.
One could add a php-based WebService to the site, and SimPE would be able to contact it in order to upload the File.

In this context "upload" would mean, that SimPE would not only send the .package/.rar File, but also the MetaData and maybe a Preview Image.

That's another cool idea, though if the webservice offers ftp/sftp, then the php side wouldn't really be necessary, as the plugin could make the necessary upload connections, even allowing uploading to a specific folder. The user could then do whatever changes are necessary to "activate" the uploaded content, be it build the static html, add it to their database, or let a scripting language (such as php) dynamically generate the pages based on the content in their upload folder.

Back to the back burner/shelf/wherever you're storing the idea in this thread, I was wondering, is the idea to include the metadata/ident/thumbnail with or within the .package? By "whitin", I mean "injecting" the extra content into the package its self. End-users (downloaders) could then extract the data themselves. And to tie in with the upload plugin idea, SimPE could extract the metadata/thumbnail prior to uploading, and send them as seperate files. This could increase the overall size of a package, but it would definately keep all the information in one place.

If this was the original idea expressed, do forgive me, I must not have caught the full drift.

The only problem with the metadata, as Quaxi said, is that MAxis would have to implement it.

@TheJim01
That was the Idea. Using the generated MetaData together with the Plugin, in order to simplify the content Uploads.
How the Data would be sent has to be decided if the detailed planing of the Plugin starts. However, not all Webmasters can add a Folder Watch or Cornjob, so some might prefer a complete php based Solution. So far I can say, if the Plugin get's reality, the upload System is gonna be Plugin based, so it will be possible to implement diffrent approaches for diffrent sites.

@mod_bv:
Basically I agree. Best thing would be, if Maxis would include it in their implementation. This would help with a Problem we had from day one. People prefer Clones over Recolors, because they can add their Name in a Clone, but not to a Recolor. If Maxis would allow us to have CTSS in Recolors, it would solve this Problem. However, I guess this is not easy to implement for the game.

Anyway, even without Maxis including this, we can benefit from this, as all Sim Tools/Sites could use a default procedure to describe the content of a .package

I am currently working with some people here to come up with an initial draft first, then we can work with the modding community to hammer it out. Things are going a bit slow, but they are moving along.

MaxiodTom, could you maybe make a thread where you can keep us in the zone with progress?

Great Idea! That will make Sims player's life much easier...
Here is my suggestions / requirement on the information that will be
included in the meta data / unique ID

I think that ...

- meta data has machine-readable part and human-readable part. (XML?)
- meta data has part intended for edited by content creator / modder /recolor and part intended for edited by end user (to help ordinary Sims player to manage his/her files in Downloads folder) and part that may helpful to Sims custom contents web owner like MTS2 or TSR.
- meta data format should have flexibility and extensibility. Various tool can add its own meta data in it without compatibility/interoperability problems with other programs that uses meta data. But some basic/common information should be standardized to prevent prolification of duplicate data.
- Adding / updating meta data should not update system file time of the package file. (But user may choose to force update system file time)

Information I would like to see in the meta data.

1) size and MD5 hash of package file *EXCLUDING* the meta data.
This is used to identify actual contents of the package which is not changed even if meta data is edited or changed. It is content invariant info.
If only meta data is edited, normal file MD5 hash will be changed but we can still identify that actual contents by this hashing file except meta data.If user has two duplicate package file which has same actual package contents but different meta data, we can determine they are so.
I prefer normal MD5 to MAXIS CRC, because MD5 algorithm is public and readily available.

2) Optionally, 128 bit UUID of actual content for same purpose with MD5 hash.
It will be updated for each content revision. But not updated for meta data only change.

3) original maxis hexa CRC as string
Because it is used for file names in Downloads folder. It will help to find file even when the player renamed the hexa named file to more readable file name manually.
If there are two identical package file in the Downloads folder, one with meta data and the other that has no meta data but with MAXIS hexa CRC name, we can identify that they are same contents except meta data. Adding /editing meta data should not change maxis hexa CRC value.

4) Date/time of creation and date of last change of actual *contents*, not file or meta data.
This date should be set/changed only when actual content is changed. If meta data is edited only, this date/time should be preserved.

5) Date/time of last change of meta data itself.
Set to date of meta information change.

6) Installation key (32 bit number)
An index will be assigned when a package file is installed to Downloads folder. May be automatically assigned during browsing if file has meta data already. It is temporary handle for content browser. It is advised to preserve file modification date even if this key is newly assigned or modified. It will help content browser to identify files regardless of manual file renaming or copy.

7) Installation date/time
the time this file is installed to this download folder.
It is good information that user infers what/where the package file belongs to.

8) Content identifier (String + UUID)
Name of the object/hack which will not changed over update/revision.
like "Flamingo of DOOM", "Merola's Magic Mirror"
similar to Object UID, it should be unique across given installation.
"Ident" info which Quaxi suggested may be belong to this.
Quaxi's UUID will serve this purpose. It is only generated on NEW content
authoring, and will not be updated on later revision (preserved across all version)

9) content revision version number
This is release version number of content. like 1.01, 2.03.
It should be changed only when the actual content is updated/ revised by author or modder and release in public. Recoloring object or meta data editing should *NOT* change this number.

10) Recolor or variation version.
It is kinda sub version number of content version number.
It may be number or text string like "red" "my recolor"
For original object or hack mod this may be empty.
So full version name is like "Merola's Magic Mirror 1.3.red-recolor"

11) Content type
one or two-level content classification like
"clothing / female-adult-everyday-top"
"makeup/eyebrow", "makeup/eye color", "skin / male-teen", "hairstyle",
"object/living room" "floor tile/exterior", "house/community"

Top level classification should be able to automatically determined by software easily. So there should be strict set of content type classification scheme
for all possible type of custom contents. Making such standard will require quite a work and great cooperation. But it is important job and worth the endeavor , I think.

12) Author info
author name, team name, copyright owner info, distributor name (like MTS2 or TSR), contact info like e-mail or author web page.
They are all optional info. But the format should be standardized to help search or classification and single-click web browser navigation.

13) File information URL
(like http://forums.modthesims2.com/showthread.php?t=35518). It is not file download URL but thread/article/web page URL related to this object!

14) Content archive info
For content distribution web site owner like TSR. This may be used for web site content management. May be DB index key number or directory path name string.

15) Digital Copyright info.
For DRM(digital right management). format may be dependent on specific DRM used.

16) README info
Optional copy of README info or file path string

17) Screen shot
Optional screen shot info. It may contain TGI(type group instance) of PNG image file.. or file name in separate screenshot folder or web URL of screenshot image
or meta data itself may contain screen shot image data in JPG, PNG, GIF.
There may be multiple screen shot info of different source.
This may be controversial for its size problem, but it will greatly help user to figure out what it is. But some user may choose to include image to meta data in expense of (ever getting cheaper by day) disk cost.

18) Comment string intended for ordinary player, not content author/modder.
Sims player can add/change short free-form comment about this file to help manage files in their Downloads folder. Adding/changing this comment will not change system file modification time.

19) Virtual folder / file name.
As you know, all the skin /clothing file should be put to single "Downloads" folder, not its sub-folder. and file name is long cryptic hexa string. They make file management quite hard and confusing.
So, let user can assign "virtual folder/ file name" to each file.
For supporting sims content browser, the pcakage files will be classified according to their virtual folder and can moved between different virtual folder by user.
This virtual folder has no need to be hierarchical.
Multiple virtual folder can be assigned to single file. For example, one for classified folder by author name, and one folder by type (clothing, make-up, hack, object etc)
There should be standard classification (virtual) folder set scheme by object type to avoid prolification of similar but different folder names.

20) Required Sims Expansion /Compatibility info.
Like Orignal, University, and something like that.

21) Extracted from: or part of:
Normally package file is not downloaded as standalone. They are part of Sims2pack, or ZIP, or Some skin file bundle... This field may be used for name of original zip file Sims2 pack or collection of packages that costitutes specific relased "Content Set" (like Dining room set / Bath room set)


---
And my last suggestion to Maxis. How about to release the Maxis CRC hash algorithm info to aid sims2 content management tool maker?

Any comment will be welcomed...

I don't think we need all the info zx1111 suggested, but basically i don't care about extra Informations, as long as the basic ones are available

Any results on the Draft so far Tom?

We had one, but things have been pretty crazy on this side because of the patch(es). The draft is pretty simple thus far, just a property set with a bunch of descriptors--probably nothing near as complex as some of the suggestions here. I think it should be as simple as possible, but we can always have a core set of properties that are required and the rest optional as well.

Couldn't agree more

I'm just wondering what the current state of this proposal is.

Well, I voted on only the ident. And the poll shows only one vote for "ident only". So much for state secrets.
The ident idea I have is similar to the invisible watermarks that are used in a lot of intellectual property.
And I would propose it be placed, like a serial number, only once in a package, by the creator, at their discretion. And, like a defective gene, it would move from copy to copy, if people are basing their work on other people's efforts.
In other words, you have "create ident" and "see ident" possibilities only. I know of a lot of ways extra data can be placed in a package file that wouldn't disrupt the game and would take a "hacker" to figure out how to remove it. And I'm sure you know some of these places, too.
This would at least allow those that are concerned about people 'stealing' their work to be able to offer proof.
<* Wes *>