| |
bepp
Registered: Jun 2010
Posts: 265 |
Suggestion: New release type "C64 Import"
Rough started a discussion a couple of years ago (see Adding the cracker group to import/trainer version), pin pointing a problem where a crack may be credited repeatedly for a group - due to the many imports that may exist.
Some attempts have been made to differentiate cracks from import by suffixing the entry with "[import]" - an approach that might not be appealing to all.
Discussions suggest that original crack group (pun intended) be credited only on *their* release, while imports only be credited to importing group, leaving a link to the original release.
My biggest concern is to be able to (quickly) identify and differentiate cracks from import, when checking for existence of a certain release for example. Although this can be partly solved by suffixing the name, I'm not sure it's the right approach. Cleaning up the credits list would partly solve the problem, but I still wouldn't be able to clearly see a difference between crack and import.
So I'm suggesting that we add a new release type. Let's call it "C64 Crack Import" or just "C64 Import" for short. It would be a fairly easy task to just "re-categorize" any imports stumbled upon, and to some extent it could probably be batch-made with an SQL query (Perff?).
It is often talked about that the DB is not designed to handle certain new features (tags for instance), while adding a new release type would make no harm to performance. Also, from a DB design perspective, it would make more sense since you can then do filtered searches where imports and cracks are differentiated. Also in release lists, it would be possible to see the difference.
...
Having import as a release type, it would furthermore be possible to have an option in listings to "Hide imports"... the result of which of course would depend on the quality of the entries, but it *would* be possible. Think future. =) |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
we have worked out something that will (also) cover this - its all a matter of perff actually finding some time to implement it - see here |
| |
bepp
Registered: Jun 2010
Posts: 265 |
While all that looks wonderful, I can appreciate the effort required to implement it. Introducing a new release type is done very quickly and it would be a good complement to the other suggestions. It would allow us to start using it right away, while Perff gets to work on the more thorough solution. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
and it piles more stuff on top that needs to be removed again and then somehow migrated to the new scheme - i'd rather see this done properly right away. |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
I suggest adding one distinction to this release type: Imported Crack
This makes it apparent that the release type started out as a crack and was imported. |
| |
Mason
Registered: Dec 2001
Posts: 462 |
Also it would be nice if the imports was splitted in legal imports and not |
| |
bepp
Registered: Jun 2010
Posts: 265 |
@The Shadow: Yes, Imported Crack would prolly be a better name.
@Groepaz: I've reviewed your suggestion again and if I understand it correctly, it would still have the release type of crack, with a "flag" property saying whether it is an import etc.
I'm a bit curious to know how this is intended to be presented in search results and release lists? At the end of the day I want to be able to distinguish cracks from imports in an easy way. It's all fine with this new meta data when looking at a specific entry, but when you have a list of entries, how would you present it (to be able to distinguish it)? |
| |
bugjam
Registered: Apr 2003
Posts: 2594 |
I would prefer only "import", which would also cover the (few) imported/fixed demos. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
bepp: how it is presented is secondary for the time being - and i am sure perff can easily add whatever filtering is required once its implemented. |
| |
Moloch
Registered: Jan 2002
Posts: 2929 |
Quoting bugjamI would prefer only "import", which would also cover the (few) imported/fixed demos.
Yeah and the imported tools |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
thats exactly why we want to make it a general flag and not add a releasetype for it :) |
| |
bepp
Registered: Jun 2010
Posts: 265 |
There's a special case that I wonder if you might have overlooked with this new system? :)
This is when one group make the crack and another group did the trainer. How to flag this in an appropriate way?
Examples:
A.R.G. +
Dead Zone +1H |
| |
Didi
Registered: Nov 2011
Posts: 488 |
This is simply crack in my eyes because it's just another unauthorized modification. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
re-crack to be exact :) |
| |
bepp
Registered: Jun 2010
Posts: 265 |
Re-crack flag is fine. But how to set proper credits? It wasn't released by the cracking group but rather the training group. Yet there should be some reference to the original crack. Will there be some kind of reference field maybe? Other options as I see it is to have both groups as releasers, but I don't think it's really right. I recall a very famous crack where Laxity did a trainer and released it as, what looked like a coop, when in fact it wasn't. Oh well we might not solve all cases with the new system but there should at least be clear guidelines on how to credit similar cases. This also applies to imports I believe (the group crediting issue). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
look at the textfile i linked above. recrack flag and reference to original crack :) |
| |
bepp
Registered: Jun 2010
Posts: 265 |
Quote: look at the textfile i linked above. recrack flag and reference to original crack :)
Great! Someone has given this some thought it seems ;-) And does that come with a rule that only the importing or the training group be credited in the import/re-crack? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
well, that should already be the case (although it often isnt, i know) |
| |
bepp
Registered: Jun 2010
Posts: 265 |
Maybe it's because there is no proper way of referencing the original crack yet...
Would it be a to narrow rule to say that: unless the game is marked as a coop (new flag perhaps?), there can only be one group credited. That way, we could have the system enforce the "one group" rule. So for re-cracks or imports, it would always be credited to the "last" group, with the original crack/group referenced.
Damn, it's gonna be a helluva job to update all existing entries with those flags O_O |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
you got it exactly right ... thats how it should be like :) (but we are not really enforcing it until we have these flags in place) and well, a "co-op" flag isnt needed, because if two groups are credited, then "co-op" is implied :) |
| |
Moloch
Registered: Jan 2002
Posts: 2929 |
Another group doing a trainer on a release is going to be flagged as a re-crack? O_o |
| |
Didi
Registered: Nov 2011
Posts: 488 |
If the training group gives proper credit to the group who did the crack I don't consider it as a recrack. Otherwise any import version would be a re-crack as well. |
| |
bepp
Registered: Jun 2010
Posts: 265 |
In this context, I believe re-crack should be considered more a technical term meaning "modifications to existing crack" - rather than a flag indicating something lame :)
And in that sense, all added trainers and imports are re-cracks, yes. But if the re-crack flag is intended for something else then the concept might need to be revised. |
| |
Jazzcat
Registered: Feb 2002
Posts: 1045 |
Most important is a FIRST RELEASE flag.
Please consult: http://www.atlantis-prophecy.org/recollection/?load=the_list |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
Quote:Most important is a FIRST RELEASE flag.
i wonder how many more suggestion before anyone reads the fucking textfile :=)
and yes, bepp got it right again :) |
| |
Jazzcat
Registered: Feb 2002
Posts: 1045 |
Quote: Quote:Most important is a FIRST RELEASE flag.
i wonder how many more suggestion before anyone reads the fucking textfile :=)
and yes, bepp got it right again :)
Like I give a fuck, just drive it to completion and get the shit implemented. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
Quote:Like I give a fuck
so why are you posting here then? |
| |
Jazzcat
Registered: Feb 2002
Posts: 1045 |
Quote: Quote:Like I give a fuck
so why are you posting here then?
Less blabla, get it implemented. Thanks. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
flags actually ARE implemented already, perff just has to fix a few more details before it can go live |
| |
Jazzcat
Registered: Feb 2002
Posts: 1045 |
Looking forward to it. |
| |
Moloch
Registered: Jan 2002
Posts: 2929 |
Quoting beppAnd in that sense, all added trainers and imports are re-cracks, yes. But if the re-crack flag is intended for something else then the concept might need to be revised.
Then a different term needs to be added because re-crack, as you know, does mean something lame database or not. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
yes, and "cracking", as you know, refers to removing copyprotections... |
| |
bepp
Registered: Jun 2010
Posts: 265 |
Since import have its own flag, they need not worry about being classified as re-cracks. I believe it's really only "lame re-cracks" and added trainers that fall into the re-crack category.
And the definition (referenced Groepaz file) of a re-crack is " not a genuine crack". I'd have to bend myself to tick this flag for a version with added trainers. At least if that's the definition..
Can this be made more clear in any way? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
maybe "genuine" is not the right word. its supposed to be a generic definition along the lines of how "crack" was defined. so if a crack is "an unauthorized modification of someones game", a recrack is "an unauthorized modification of someones crack". |
| |
Jazzcat
Registered: Feb 2002
Posts: 1045 |
Then you have "Re-Release" flag also, equally as lame. |
| |
bepp
Registered: Jun 2010
Posts: 265 |
Well I'd say that is of little importance, as it's only relevant for counting points [e.g. The List]. I'd say most of the existing entries would be re-releases then? And who's to judge? :) IMO, it doesn't add any value to the entry on CSDB really. Better keep that info elsewhere for those interested. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
re-release aka "mail version" aka lame. indeed =) you are right though, its of little importance - like many other of those flags are =P |
| |
Jazzcat
Registered: Feb 2002
Posts: 1045 |
True.
For me, first release and import flags are the most significunt. |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
""lame re-cracks" and added trainers that fall into the re-crack category."
I second Didi on that ("If the training group gives proper credit to the group who did the crack I don't consider it as a recrack.").
A recrack, to pass off another's crack for his own by removing the true cracker's intro and so on, is something completely different than improving other people's crack (bug-fixes, highscoresaver added) with giving credit to the crackers.
Noone in the old days would have called Ghostbusters II +27 a recrack, cause that term is definately for doing something LAME. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
i agree, the problem however is to find a simple and clear definition for what sets apart a "trainer" version from a "re-crack" is not giving credit to the original cracker enough?
and we need a different property flag (like "re-crack") to maintain backlinks to the original crack then - whats a less silly name for it than "crack of a crack" ? =D
that said, i guess we want a "fix" flag with backlink to another entry too, so we can maintain pal/ntsc fixes that way too? :)
mmmh and it should then probably be a dropdown box (select only one of) containing "recrack" "import" "improvement(?)" "fix" because it can be only one of them?
edit: mmmh or would it be a better idea to just have generic "based on another version" checkbox with backlink? mmh :) |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
"i agree, the problem however is to find a simple and clear definition for what sets apart a "trainer" version from a "re-crack"
Yep, some people added cheats and other extra stuff but "forgot" to mention the cracker.
"is not giving credit to the original cracker enough?"
Guess not. e.g. if credit is given inside the game like it used to be done a lot by changing game credits and highscores text and the trainer only points out something like "presents +4 trainer" in his intro/trainer screen without claiming to have it cracked, it's not a recrack.
Also: Removing the original cracker's intro wasn't always done to hide the crack's origin but for size reasons. |
| |
Didi
Registered: Nov 2011
Posts: 488 |
I don't remember if this has been discussed before, but how about implementing some kind of "release chain" feature for cracks in case a release was touched by several groups.
Game +x [pal/ntsc]
Release chain: Game (crack) by GroupA > Game (trainer) by GroupB
The current release needs to have a link to the release it's based on then.
Simpler might be just to add a "based on" link which may just direct to the release it was directly made of. It may direct to a previous crack or even a C64 Game entry if it is present on CSDb. Sometimes also Tools or Demos get fixed or developed further, so this may enable you to click through to previous versions.
Such entry may look like:
Current Release title
(Based on: <Backlink to base-release> by XYZ) |
| |
Didi
Registered: Nov 2011
Posts: 488 |
Quote:Also: Removing the original cracker's intro wasn't always done to hide the crack's origin but for size reasons. Sometimes the intro was also removed because it was incompatible to NTSC (or even PAL). There are several releases where I'd wish they had removed the intro because it's just bugging around.
It was mainly Euro-groups which removed the intros of the NTSC crackers while NTSC importers mostly just additionally linked their intro. This is interesting because NTSC compatibility of PAL code appears much more often than vice versa. |
| |
bepp
Registered: Jun 2010
Posts: 265 |
There will be a field to enter the id of the original crack (in case of re-crack or import). See http://hitmen.c02.at/temp/cracktags-draft.txt. |
| |
Didi
Registered: Nov 2011
Posts: 488 |
Might appear on Demos/Collections as well because e.g. Style fixed several of them.
Really looking forward to the changes to go live. |
