TOSEC Amiga Correction Help!!!

[PandMonium]

:S well at least it is now fixed :P

[mai]

Originally Posted by PandMonium

:S well at least it is now fixed :P

So i dont need to ask for removing.
i had to be a little bit sarcastic in my previous post.

[mai]

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]

[TKaos]

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.

[mai]

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.

[TCD]

Originally Posted by mai

Do you think, that it is an good idea to remove [cr] flag in such cases.

I think it's a great idea Always wondered if there is any modified content on those disks. Useful info for finding a working set of disks (either if it's set or not ).

[mai]

Thanks, TCD.
Any different opinion here?

[lilalurl]

Originally Posted by mai

Any different opinion here?

I share the same opinion as the both of you on this matter.

[demoniac]

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.

[mai]

Originally Posted by demoniac

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.

Ok, let me explain my point of view.

Current example:

Espana - The Games '92 (1992)(Ocean)(M6)(Disk 2 of 4)[cr CSL]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 2 of 4)[cr CSL][a]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 2 of 4)[cr CSL][a2]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 3 of 4)[cr CSL]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 3 of 4)[cr CSL][a]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 3 of 4)[cr CSL][a2]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 4 of 4)[cr CSL]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 4 of 4)[cr CSL][a]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 4 of 4)[cr CSL][a2]
Espana - The Games '92 (1992)(Ocean)(M6)(Disk 4 of 4)[cr CSL][a3]

I am about to remove [cr] flag from all disks 2 -4.
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.

[PandMonium]

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

[mai]

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.

[demoniac]

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.

[mai]

There are some sets, where it is really hard to rename succesfully.
The current example:

Dragon's Lair - Escape from Singe's Castle (1990)(ReadySoft)(Disk 1 of 5)[cr CLS][t +1 CLS][a]

This is not really true.
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?

[demoniac]

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?

[PandMonium]

lol what a mess, i think i didn't even understood correctly the entire story of the disk

[mai]

The story continues..
Another issue with the same game, but its relevant for other sets too.

Dragon's Lair - Escape from Singe's Castle (1990)(ReadySoft)(Disk 1 of 5)[cr QTX][h New Order]

When i would see this set, i would think, its cracked by "QTX" and later hacked by "New Order".
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!

[PandMonium]

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:

Dragon's Lair - Escape from Singe's Castle (1990)(ReadySoft)(Disk 1 of 5)[a][New Order]
Dragon's Lair - Escape from Singe's Castle (1990)(ReadySoft)(Disk 1 of 5)[cr QTX][t +1 CLS][a][New Order]

...or without the alt flag. This is just a suggestion, obviously

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! )

[rygar]

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...

[PandMonium]

No more opinions?? :P