| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Please stop "cleaning" disk images
... or at least after you do so, test if the damn release still works after doing so. not seldomly there is other stuff on the disk that is needed - and its not necessarily obvious, or even visible in files. it really sucks to find those non working things when it is obviously the result of someone trying to "optimize" the image. ideally also attach the non cleaned image - that also keeps the context with the other games on the disk intact, which is sometimes kinda interesting to see.
thanks. |
|
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Yes: Make sure all files (can be rips, pics, docs, dirart) from the release you are uploading are there, and test the release before uploading. |
| |
Thierry
Registered: Oct 2009
Posts: 48 |
Good point, I have several releases that are not in CSDB, I'll be a good idea to load the image without cleaning, image.no clean.d64
retrocomputacion.com
Argentina |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
Great, bring them on! :-) |
| |
TheRyk
Registered: Mar 2009
Posts: 2241 |
yeah especially if download files are flagged "broken", upload the complete image in question as transferred, not only .prg and no modifications |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
I opt for both, though - a cleaned version, to make life for the SID checkers like Fred easier, and one original version. |
| |
Mr.Ammo
Account closed
Registered: Oct 2002
Posts: 228 |
Quoting TheRykyeah especially if download files are flagged "broken", upload the complete image in question as transferred, not only .prg and no modifications It seems that the broken property can only be used when the release concerns a crack. While it should also be used for other releases that break, people tend to use the corrupted files flag instead. Which is a no-no according to:
Quoting CSDb rulesThe "Goofs" field and "broken" tag is aimed at the scene release in question. A goof is meant to document bugs in the release; for a crack that means bugs inflicted by the cracking group - not bugs that is in the original game. The "Broken" tag is used for signalling a broken release, again inflicted by the crackers or coders for example. For demos "broken" can be used if a release crashes and a newer version that works exist. Don't confuse the "broken" tag with the corrupted files (a bad copy, where the disk is trashed), that is covered and tagged editing the file in question when uploading. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
No. these are two different flags. one is per file (and can be used on any file) and its for marking actually broken files (not broken releases). the other is for marking broken cracks, and that is for marking fucked up cracks, not broken files. |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
"For demos "broken" can be used if a release crashes and a newer version that works exist." That refers clearly to the "broken" tag (like for cracks), not the "corrupted" flag for the download.
Good point, in fact, although those cases are probably rather rare. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
Especially my dumb spread notes from '90ties :D |
| |
Fred
Registered: Feb 2003
Posts: 285 |
Quote: I opt for both, though - a cleaned version, to make life for the SID checkers like Fred easier, and one original version.
This is the wrong reason but thanks for adding cleaned disks :-)
The real reason for adding cleaned disks is of course that the release entry is about a release and not about a spreaded disk where the release was on. There are other sites for dumping disk images.
We have many comment fields for a release entry for preserving info that is found on a disk or on a release. No need to add uncleaned disks for this.
Anyway, always add a clean disk to a CSDb release entry. The uncleaned disk might be added but really not needed. It only makes the release entry 'dirty'.
Bottom line is that after cleaning a disk, always test the release and double check if all the files from the release are present. Also check for useful info on the uncleaned disk that can be added to CSDb.
If you're unsure that you missed something from a disk, you can always add a comment from which disk of which collection the release was found. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
The point is that you can hardly ever test multi-file releases properly (that is at least true for most games). And that means adding an unmodified disk is a must. "cleaning" also destroys the context of the release-disk, which really noone ever bothers to add to the entries. Also the release disks by themselves are artefacts worth preserving, including dir stamps, notefiles and what not. ripping out the releases and putting them on blank d64s just so emulamers can do clickyclickyautostart is simply lame. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: This is the wrong reason but thanks for adding cleaned disks :-)
The real reason for adding cleaned disks is of course that the release entry is about a release and not about a spreaded disk where the release was on. There are other sites for dumping disk images.
We have many comment fields for a release entry for preserving info that is found on a disk or on a release. No need to add uncleaned disks for this.
Anyway, always add a clean disk to a CSDb release entry. The uncleaned disk might be added but really not needed. It only makes the release entry 'dirty'.
Bottom line is that after cleaning a disk, always test the release and double check if all the files from the release are present. Also check for useful info on the uncleaned disk that can be added to CSDb.
If you're unsure that you missed something from a disk, you can always add a comment from which disk of which collection the release was found.
That is also my view. The entry is for a specific release and nothing else. If people are lazy and just add a whole disk with all kind of crap on it is harder to find the release and the rest of the content on the disk is considered noise. I understand Groepaz’ view on preserving the whole spreaddisk etc, as it puts the release in a context, but I do not agree this database is the right place for that. The collections that the release is part of are more important for that. If you are interested in the content context my view is that the collections available online are a better place to look.
That said, I agree completely on that the releases uploaded here must contain all files of the release in question, and that it must be tested prior upload. Sloppyness and lazyness can never be an excuse. Also: context can be added as info in various fields. And do not forget to add screenshot(s) and credits. Read intro scrolltexts, help your fellow researchers with info and trivia, and add sources for the added info. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Quote:The collections that the release is part of are more important for that.
unless there is a link to that disk in that collection right in the entry here, or adding all that info that gets lost when cleaning the disk becomes mandatory, thats just invalid blabla. (and there are also more than enough disks that dont come out of some "collection", none that is publicly available anyway) |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
Many releases appear on many different spread disks, should we add all of them to the entry then? |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: Many releases appear on many different spread disks, should we add all of them to the entry then?
Good point. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
the disk that the respective group made. there shouldnt be too many of them.
but yeah, i'd rather see some more d64s added than yet another stupid idea that removes info from the db for no good reason. what problem does this "cleaning" solve exactly? (dejavu >_<) |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: the disk that the respective group made. there shouldnt be too many of them.
but yeah, i'd rather see some more d64s added than yet another stupid idea that removes info from the db for no good reason. what problem does this "cleaning" solve exactly? (dejavu >_<)
Sorting out a release from a disk full of other stuff, is reducing redundant data, it saves space, and keeps away inconsistencies. Which I think is part of good database design - if what we mean with every entry here is an entry for the release in question, and nothing else.
For a "Scene Original Disk Database" it's bad however. Then we should feed cbm8bit.com and their 8bit Disk Image Search. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
It's removing useful info. period. It doesnt solve a problem either. It's almost as bad as creating a silly new release type for something that should be an additional tag, and removing info in the process.
And all that doesnt even matter - because STILL properly testing a multifile game is something that is close to impossible - and noone will bother doing so. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: It's removing useful info. period. It doesnt solve a problem either. It's almost as bad as creating a silly new release type for something that should be an additional tag, and removing info in the process.
And all that doesnt even matter - because STILL properly testing a multifile game is something that is close to impossible - and noone will bother doing so.
<Post edited by hedning on 24/3-2019 22:56>
We are a very small fraction of users filling the database. I'd say a vast majority of the users here don't bother to do shit at all to the database. They are not uploading, they are not adding info, they are not researching... That is the main problem.
And hell yes. Everyone should make sure that every release they upload is complete. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Even more important: they should make sure to not destroy the data they upload by "cleaning" it. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: Even more important: they should make sure to not destroy the data they upload by "cleaning" it.
Correct. They should make sure that the release they upload works. But I thought we already established that. The data we ask for is the release, and all credits etc. Nothing more.
I am sure that uploading full untouched disks instead of only the release in question never has been the common practice at any time here on CSDb. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
But as said, for a multiload game its practically impossible to make sure you didnt fuck it up by "cleaning". Hence not "cleaning" is the only reasonable thing to do. Noone will bother spending hours on playing through a game to make sure it still works like it should. Hell, i found more than one "cleaned" d64 where some genious obviously didnt even bother to press space in the crack intro (or he would have noticed it tries to load the actual game.... and fails)
There's no politically correct term for 'fucking idiot'. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Quote:I am sure that uploading full untouched disks instead of only the release in question never has been the common practice at any time here on CSDb.
it was the norm before some geniuses started the "cleaning" bs.
There's no politically correct term for 'fucking idiot'. |
| |
bugjam
Registered: Apr 2003
Posts: 2588 |
I had one instance where copying the release over to an empty image actually _fixed_ it. Just saying. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Fixing something that didnt work and not altering something to make sure it doesnt break are two entirely different and unrelated things however >_<
There's no politically correct term for 'fucking idiot'. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
I just want to point out now that noone adding "cleaned" out releases, or adding full disks for that matter, did anything wrong here according to the rules. We ask for files, not disks. And under 7.4 we also point out that people should TEST their files before adding them, as far they can. So that is already in the rules, and established. The fact that people ignore the rules is another question.
I put the question up for debate between the mods, however. I don't decide changes to the rules, and neither do herr Groepaz. We might have to clarify some guidelines at least. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Waiting for a proper rule that can be applied to all releases, mercyless. You are probably working on it :)
There's no politically correct term for 'fucking idiot'. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: Waiting for a proper rule that can be applied to all releases, mercyless. You are probably working on it :)
There's no politically correct term for 'fucking idiot'.
You know this is a hobby project right? And that most people help in their spare time, while working 100%? Some even have family and kids to tend to as well. ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
At least while you are working on it, you are not deleting more info from the database.
There's no politically correct term for 'fucking idiot'. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: At least while you are working on it, you are not deleting more info from the database.
There's no politically correct term for 'fucking idiot'.
Please stop spreading that bullshit about me. I'm dead tired of your attitude and your lack of civilized manners and communication. Bully. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
that some silly releasetype that was added did a) not solve any problem whatsoever and b) did remove info from the database is a _fact_. you'll have a hard time denying it. |
