23 December 2009, 22:49 | #41 |
Registered User
Join Date: Sep 2008
Location: Portugal
Posts: 408
|
:S well at least it is now fixed :P
|
23 December 2009, 23:00 | #42 |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
|
05 April 2010, 14:51 | #43 |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
Is there any valid reason to have "AMOS" as [more info] flag?
Is it really needed for any reason? Example: Charlie Chimp (1993)(Europress)[AMOS] |
06 April 2010, 17:05 | #44 |
Registered User
|
If someone want to have a list of all games created with AMOS then it's easy to search for them in TOSEC, I can't think of a better reason.
|
11 May 2010, 08:54 | #45 |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
I want your opinion again.
In current TOSEC dat are many disks 2 disks 3 and so on marked as cracked, but in real a lot of this disks are untouched. I am about to remove [cr] and also [t] and [h] flag from many disks 2, disks 3 and so on. I am carefully check and compare every single disk. Do you think, that it is an good idea to remove [cr] flag in such cases. An current example: Espana - The Games '92 (1992)(Ocean)(M6)(Disk 1 of 4)[cr CSL] of course needs [cr] flag. Espana - The Games '92 (1992)(Ocean)(M6)(Disk 2 of 4)[cr CSL] Espana - The Games '92 (1992)(Ocean)(M6)(Disk 3 of 4)[cr CSL] Espana - The Games '92 (1992)(Ocean)(M6)(Disk 4 of 4)[cr CSL] Here i am about to remove [cr] flag, because the sets are exactly the same as the converted IPF. |
11 May 2010, 09:01 | #46 |
HOL/FTP busy bee
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,057
|
|
11 May 2010, 09:04 | #47 |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
Thanks, TCD.
Any different opinion here? |
11 May 2010, 19:11 | #48 |
Global Moderator
|
|
11 May 2010, 19:17 | #49 |
Registered User
Join Date: Jul 2005
Location: -
Posts: 1,698
|
I'd only doing it if the CRC matches IPF converted. However, it may lead to confusion when people thinks Disk X is missing from Crack Y.
|
11 May 2010, 19:38 | #50 | ||
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
Quote:
Current example: Quote:
Reason: There are differences only in unused area of the disks. the disks are DOS, so i was able to compare file by file on disk(thanks to "Felzkrone" for great ADF Compare Tool), all files (on disk) have same crc32, also same datestamp and all compared against the IPF, so i think there is no reason to have [cr] flag here. Of course i have also scanned the unused area of the disk, but no trace, that there was anything modified by crackers. |
||
11 May 2010, 19:50 | #51 |
Registered User
Join Date: Sep 2008
Location: Portugal
Posts: 408
|
I think you should change it too, i've already discussed it with you i think :P
IMO the solution is something natural and logic. If we have a bunch of images, one of them has been hacked and is different from the original then it should be identified accordingly. If the rest is just 100% similar to what can be achieved by dumping original media, then there is no reason to mark them in ways that they aren't. Of course all guys around here know a bit more about technical stuff and Amiga than i do, i barely know what an IPF is (:P). Nonetheless, the answer to this is something logical and easy to understand. What if we have a 2 disks game, spread around by different guys. For example, 2 versions: group A, group B where only the 1st disk was cracked, and a 3rd version with 100% original dumps. In the end we will have 3 different versions of disk1 (disk1 original, cracked by GroupA, cracked by GroupB) that should be renamed and added accordingly. A single version of disk2, equal between the 3 releases. In this case, this set is the original, unmodified dump and should be renamed accordingly. Should not be related with something they are not. I understand this is tricky / complicated and maybe will apply to other flags too like trains and so on, it may also be hard to know when just one disk was modified but imho is the right way to do it. We are identifying correctly what the disks are. And yes, like demoniac pointed out, noobs may look at that and think there are sets missing, with only few cracked disks and the rest being original. I would thought that too if i wasn't told by mai and others :P but that's something we can't fix, people needs to keep complaining and learning about the desired system as usual |
11 May 2010, 20:06 | #52 |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
Thanks for further explanation, PandMonium.
Of course, as i have said before, also many [t], and [h] flags in current dat needs removing(needs carefully checking of course). There are very rare cases, where [t] flag is really needed for any further disk 1, 2 and so on. |
12 May 2010, 22:03 | #53 |
Registered User
Join Date: Jul 2005
Location: -
Posts: 1,698
|
I agree w/ what you are trying to do, mai. Just pointing out that some people will probably get confused that's all. I guess if they can't figure it out, that's tough luck.
|
07 June 2010, 19:11 | #54 | |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
There are some sets, where it is really hard to rename succesfully.
The current example: Quote:
You have to know the history of this scene release. Original release was by a group called "New Order", but they released it uncracked, then different groups released crack fixes (CLS, QTX, ESI), which you had to apply to the uncracked version by "New Order" or to the original. Sure, maybe full cracked game(all disks) has been also spreaded on different BBS by the mentioned groups. But current example is confusing, the fix was not correct applied, there is the cracktro by "CLS" on disk, but someone forgot to copy also the cracked EXE to the disk. I should note, that the mentioned disk is truely the release by "New Order", because intro of this group is still on disk! So, any suggestions? Last edited by mai; 07 June 2010 at 19:19. |
|
07 June 2010, 20:41 | #55 |
Registered User
Join Date: Jul 2005
Location: -
Posts: 1,698
|
I think what happened there is that someone had the New Order version. Saw the Classic trainer, downloaded and added it without thinking/knowing about removing the protection.
Maybe show it as either modified or hacked by New Order (with protection) and t +1 CLS? |
07 June 2010, 21:13 | #56 |
Registered User
Join Date: Sep 2008
Location: Portugal
Posts: 408
|
lol what a mess, i think i didn't even understood correctly the entire story of the disk
|
07 June 2010, 21:41 | #57 | |
Registered User
Join Date: Feb 2008
Location: Federativnaya Respublika Germaniya
Posts: 4,994
|
The story continues..
Another issue with the same game, but its relevant for other sets too. Quote:
But this is also not really true as i have said. Its really nearly impossible to rename properly. I can not use: Dragon's Lair - Escape from Singe's Castle (1990)(ReadySoft)(Disk 1 of 5)[cr New Order][f crack QTX] because it would be also not really true, its not cracked by "New Order", it was released uncracked. Thats why i have suggested before to create another flag [r] = released. Then you could always choose between [cr] and [r]. Then you could use order [r New Order][f crack QTX], [h New Order][f crack QTX] is not possible. I am not aware until now, if creating [r] flag would causes any problems/conflicts! |
|
08 June 2010, 02:36 | #58 | |
Registered User
Join Date: Sep 2008
Location: Portugal
Posts: 408
|
AFAIK there is no conflict.
The problem is that we should not create a new flag for every problem we face. TNC is already a really complex set of rules (some not well designed or defined) and make it even more complex would not help. IMHO we have to assume that there are limits in what can be stored using the setname and use just that. There are more info that could be added there, for example it would be cool to distinguish between the developer and the publisher name and probably store both. Store not only the crack group but the group members involved would also be interesting but again and like i said it can't be all entered in the setnames. That kind of info would serve as a complement in (a more complex format) datfile and/or database. It's just my opinion off course and i'm all for making the project better and fix our current rules as you know Nonetheless, adding the flag released has a number of drawbacks that i can remember: * A new flag so solve a (+-) rare problem, don't think it worth's the extra complexity * Backwards compatibility - Adding a new flag to catalog something that wasn't done before will result in a good number or older sets that probably would fit well with the flag and don't have it. It would add inconsistency between sets. * I would need to update my tools and documents :P (this one is not really important obviously ) * The most important one IMHO is the entire concept of "released". What would it mean? Many sets were released by someone, the cracked ones and so on were always released by someone i guess. Mainly by the person/group that cracked/fixed/hacked it (would duplicate flags) i guess, sometimes by other groups. There were spread groups and supply teams and such but, sometimes there is no point in identifying that. Other crucial point is, if someone released something completely untouched, then it is the original set and the good dump from the original media will match the CRC, there is no point in adding a flag saying that it was released by X group when that is not true. The possibility of similar releases by different persons also exists right? I dumping something and X dumping it too somewhere else and both releasing it. If, on the other hand, the file was different from the original then it means something was modified or hacked and the correct flag should be added. In this New Order case, the version is different from the original right? Because the crack only works with it. Then i assume that a) it is a different version/release/revision/prototype/dump(from a different disk?)/something and the cracks take advantage on something available only on that version or were done based on that, for example to patch some specific bytes that are on different addresses on other dumps. Indeed it is complicated to store more info in that case. If it is really uncracked/unedited i guess it is an alternate version (why? we don't know, right?), would put it with an extra [a][New Order] or [New Order release] in more info. If it was half cracked i guess we could use flags [cr New Order] , [b crack]. If we don't know much i would just add the more info about it. In the other sets, they were already applied right? You're trying to rename the patches or the complete already patched sets? Will guess it is the 2nd... In this case i would just classify/rename the setname, it is "Dragon's Lair - Escape from Singe's Castle", cracked and trained by QTX. Was NOT hacked by anyone previously so the hack flag is not well applied, right? Is there a better option? Like using the fix flag? Clearly, if the info is relevant i would also add the more info flag discussed before, possibly the alt flag too if the case was confirmed (or better yet was to discover why it is different and the crack only works in this set, the alt descriptor, or the version or something). So the sets would be +- similar: Quote:
Summarizing, my main point against release flag is that, looking deeply to what it does, it won't classify any detail about the image/setfile itself. It's just saying that it was dumped or it passed by someone or some group at a given time, right? With crack, trained, translated, fixed and other dump flags they are indeed telling us something about the image and why it differs from an original good dump for example. This set is different from that and has this crc because it was hacked by XPTO and a fix was added by OTPX. The release flag IMHO would not add any value / proper information about the software and would possibly cause more bad than good. So, what do you guys think of it? Please discuss! :P Want to read well documented / well-founded opinions from guys with proper knowledge about the sets/systems in this case. (END OF SPAM! ) |
|
08 June 2010, 17:31 | #59 |
Registered User
Join Date: Nov 2007
Location: Poland
Posts: 1,391
|
I wonder why do not use "scene rules" for such cases. I mean that today we have tags in scene releases like:
PROPER, CRACKFIX, REPACK etc... and i'm sure that in 90' there were also similiar rules so old sceners should tell us how to proper name such releases... |
10 June 2010, 16:35 | #60 |
Registered User
Join Date: Sep 2008
Location: Portugal
Posts: 408
|
No more opinions?? :P
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
TOSEC Amiga Correction Thread | BippyM | project.TOSEC (amiga only) | 2642 | 17 June 2024 17:47 |
Old TOSEC Amiga Correction Thread | [idoru] | project.TOSEC (amiga only) | 668 | 24 March 2009 12:17 |
tosec.amiga.me (Your New TOSEC Source) is open! | Magix | News | 31 | 19 March 2009 18:03 |
HUE correction [was colour correction] | Marcuz | request.UAE Wishlist | 6 | 17 September 2008 22:13 |
hol correction | Ray Norrish | HOL suggestions and feedback | 4 | 12 June 2005 21:25 |
|
|