Zelda classic source code- Please read.

[Anarchy_Balsac]

Well, if you want to contribute, I imagine that, like in most communities, your have to become a well respected member whom the staff feels they can trust first, but I hear ya.

[Gleeok]

I totally agree. The source code needs to be hosted publicly; indeed, we we are way overdue for that. To be completely honest (in all fairness to the community), the only reason it's not done yet is because of the notion of keeping password protection on password-protected quests, and being open source at the same time. Those are two very different things, and to be even more honest about it: I sort of don't work on trying to make these two things possible because in the back of my mind I know that someone's just going to fork the repository and put in all the encryption stuff anyway, so it would be like painting my house during a sandstorm (or some other analogy, you get my point)... I guess you could say that motivation for it does not exceed the minimum requirements to overcome laziness.

But it really does need to get done.

[edit] Also, there's nothing really stopping it from being released I guess, minus the fact that ZC cannot load quests, and the license is basically GPL.

[_Mitch]

Nice to meet you Gleeok, I've heard a lot about you.

Wow, I didn't expect to get so many replies, thanks.
I realise nobody should trust me, that's why I don't expect to get access to the source before release.

Ah, I know the password thing is a big hurdle; you want the old quests to work, and their security to still matter.
Perhaps you could just remove support for passworded quests, and their authors can would have to open them up for other people to use?

Was there ever a contract that said "armageddon games reserves the right to remove your password with future versions of ZC/ZQ"?
That would have been great, then it could just disregard the passwords which will be labeled "deprecated" (although that may offend some).

Unfortunately that really does sound hard to fix. It's either everyone's quests become editable, or are not available any more (unless converted).

[EDIT]
It's just that these days nobody has much free time to spend on these projects. Free projects like these need the community to survive and thrive.
So the faster it gets opened up, the sooner everyone can benefit from it! I'm sure that once it's opened more quest makers will pile up and start making levels!
Even if it means losing compatibility with the old quests, it'll get more over time. Besides open source projects get a lot more publicity.

And perhaps a closed-source app can be made that you input a password and outputs a converted quest?
Still an application like that needs special security measures, because the hacking community would probably be lurking.

[ZoriaRPG]

I totally agree. The source code needs to be hosted publicly; indeed, we we are way overdue for that. To be completely honest (in all fairness to the community), the only reason it's not done yet is because of the notion of keeping password protection on password-protected quests, and being open source at the same time. Those are two very different things, and to be even more honest about it: I sort of don't work on trying to make these two things possible because in the back of my mind I know that someone's just going to fork the repository and put in all the encryption stuff anyway, so it would be like painting my house during a sandstorm (or some other analogy, you get my point)... I guess you could say that motivation for it does not exceed the minimum requirements to overcome laziness.

But it really does need to get done.

[edit] Also, there's nothing really stopping it from being released I guess, minus the fact that ZC cannot load quests, and the license is basically GPL.

I hadn't mentioned this in the past, but how about supplying a pre-compiled password library file, as a separate download, for compatibility concerns?

Using that, a person could compile ZC, drop in the lib, and load quests; or write their own encryption protocol; or use no encryption, all at their discretion. The library would be user-end, so if it exists, ZC uses it. if it isn't in the path, ZC uses either (A) no encryption, or (B) user-defined encryption.

Forking will happen, no-matter what you do. It's an inevitable fact of open-source projects, and often, vital to their evolution.

[_Mitch]

@ZoriaRPG That actually sounds like a great solution. Good idea actually.
But I bet someone would reverse engineer it eventually (the lib).
Perhaps if it's designed cleverly enough though, that could pose a challenge.

[Tamamo]

rewrite the encryption complety again and write a password updater that opens with the ol and saves with the new

[Anarchy_Balsac]

That also wouldn't work if it were open source. It might make it a llittle harder for people to dig through the code and figure things out, but they could still do it.

The best approach is to bury the encryption deep within some random place of the source code, with no comments dictating what it is or how it works, but it could still be found even then.

[_Mitch]

Actually Anarchy_Balsac, if you are talking about ZoriaRPG's post, it could work -but you are probably talking to Tamamo.

ZoriaRPG is saying that you could compile the password code into a static library that gets linked into the main program.
Also, an dynamic link library would work. But still, this could be reverse engineered, but pretty much anything can be so.

Burying the encryption in the code and releasing it online would most definitely get found eventually.
If the encryption is ever changed a closed source tool could be useful in converting maps, but that could just be implemented in an external compiled library for ZQ as well.

[Isana]

@ZoriaRPG That actually sounds like a great solution. Good idea actually.
But I bet someone would reverse engineer it eventually (the lib).
Perhaps if it's designed cleverly enough though, that could pose a challenge.

The only difference between reversing ZC as it is now and reversing a library is that, assuming the library's sole purpose is encryption, there would be a lot less code to look through.
You could throw a bunch of junk code in there with it and use a few other tricks to change that though.

I think the external library is a fine idea.

To be honest, though, all these arguments about someone still being able to screw around with the code to do something like open password protected
quests are pointless. If everyone thought like this literally nothing would ever get released...
Aside from that, as you're all already aware, it's already possible to open password protected quests.

These are useless without knowing where to apply the patches, but this is all it takes to make ZQuest disregard passwords in the latest release of Zelda Classic...
E9 58 FF FF FF - Linux
E9 57 FF FF FF - Windows

[_Mitch]

That's why I said someone would probably reverse engineer it, simply because it has less code and would be easier to do.
Yeah, but voiding or disregarding the passwords would be disregarding the user that created the quest some might say.

Are you saying all it takes is overwriting a few bytes in the quest file to open a passworded quest?
If so, that's kinda sad, and poor design- and that is only 5 bytes! But why is it different in the windows and linux version?

By posting those 5 bytes, could anyone with basic knowledge on file comparison and a hex editor could search for that string in a non-passworded quest,
overwriting it at the same location in a passworded quest- likely opening it right up (assuming the offsets are the same)?
It sounds like there was not much security to begin with really.