Disable, Emulation by Default

[Aztek 2]

At the moment, ApexDC++ emulates DC++ for all hubs it does not have in it's favorites.

WHY, isn't apexdc the most popular dc++ application out there ?

disable it please !

[SHERIFA 0]

This option ( tick ) is set disabled by default. 1.2.0 Stable. When I go to edit or add new hub - there is no tick.

Or you want to disable mainly this function - to tick/untick "Emulate DC++ in this hub" ?

[Aztek 2]

if a hub is not in your favorites, apex WILL emulate dc++, when you do add it to favorites, it does NOT emulate dc++ unless you check emulate dc++ in this hub.

very silly IMO

[Mek 13]

It is not silly at all. Imagine a hub doesn't let you in because it does not recognize your tag. This way, by emulating DC++, the chances that you will be connected to the hub successfully, dramatically increase.

[Aztek 2]

It is not silly at all. Imagine a hub doesn't let you in because it does not recognize your tag. This way, by emulating DC++, the chances that you will be connected to the hub successfully, dramatically increase.

but, isn't apexdc++ the most popular dc++ client ?

[Guest Toast]

it is and discrimination only occurs on nmdc hubs in ADC is accepted as a normal client

[Lotus 0]

don't worry: soon DC++ will implement a new feature: "emulate ApexDC++"... :)

[RadoX 0]

Hubs that don´t allow ApexDC don´t deserve any users and should be closed. From the other hand hub owners who don´t allow ApexDC should have the right to choose what clients thay allow. From both points of view emulating sould not be in any client.

[Aztek 2]

Hubs that don´t allow ApexDC don´t deserve any users and should be closed. From the other hand hub owners who don´t allow ApexDC should have the right to choose what clients thay allow. From both points of view emulating sould not be in any client.

agree completely

[Aztek 2]

i'd like to bump this request, i think it's important and should be default.

even simply removing emulation completely would be even better...

as they say, hub owners should be allowed to say who can enter their hub and who can't, if they don't want apexdc++ that's their choice and i don't want to step on any toes...

example: I mean, i join a hub, it seems awesome, i add it to favs, BOOM apexdc not allowed so i NEED to emulate dc++ using a client the hubowner didn't want to allow in the hub in the first place, maybe even breaking rules and maybe even getting banned...

So ...

[Lee 84]

i'd like to bump this request, i think it's important and should be default.

even simply removing emulation completely would be even better...

as they say, hub owners should be allowed to say who can enter their hub and who can't, if they don't want apexdc++ that's their choice and i don't want to step on any toes...

example: I mean, i join a hub, it seems awesome, i add it to favs, BOOM apexdc not allowed so i NEED to emulate dc++ using a client the hubowner didn't want to allow in the hub in the first place, maybe even breaking rules and maybe even getting banned...

So ...

There are way too many hubs that don't allow ApexDC++, and that would cause problems for users who don't know how to enable emulation.

[Aztek 2]

There are way too many hubs that don't allow ApexDC++, and that would cause problems for users who don't know how to enable emulation.

that's their choice, right ? (hubowners)

plus, emulation goes off when you add a hub to fav's...

if hubs don't like apex, fine, then apex users can cheat and emulate OR join a better hub...

[Lotus 0]

There are way too many hubs that don't allow ApexDC++, and that would cause problems for users who don't know how to enable emulation.

Lol. So you do it for us... ApexDC++ users... Thank you very much. But I don't think so, because we can change the client and get access...

If a hub owner does not allow ApexDC++ client in his hub, his will should be respected. I don't say that ApexDC++ is inferior or the decision to ban ApexDC is a good decision. I say if this happens, you should respect it. Emulating is nothing more nothing less then cheating. You emulate DC++ and you enter that hub ILLEGALLY. This type of cheat does not have a direct bad influence on DC network (like fake share does), however it helps your client to become more popular, or at least this is it's purpose. Emulating is a fake option that help ApexDC++ to grow. But it does this by disregarding (and breaking) hub rules.

Each client that emulate other client is faking, in the behalf of his users, but ultimately for himself.

The alternative is to not emulate anything. If someone wants to ban this client, he should be allowed to do so. Doing this will have some repercussions over the client and/or the hub... For example, I don't like the "crash client" option that hex hubs implement. If a hub is not very well configured, you may be "crashed" often. Now, if I would have a client that has some anti-flood incorporated, like allowing max 5 private messages / second, probably I will enter hex hubs... but because I DON'T have such a client, I DON'T join hex hubs... So, who has to loose from this situation ? My client, or hex ? You get my point...

So basically, the current state is this: the hub is the master and the client is the slave. As long as you will accept this state of fact, emulating is your choice... when you will no longer allow emulation, probably this raport of forces (hub vs client) will be reversed...

And for the hub owners that wants to ban ApexDC++, I give you a small hint: just set min slot ratio to 1. Because more then 95% of the population use the default client settings, and because the default ApexDc++ settings is 2 slots and 0 slot ratio, you will get rid of 95% of ApexDc++ users, while in the same time improving the performance of your hub... :)

[Big Muscle 1]

Emulating is nothing more nothing less then cheating.

No, it's not. It depends on kind of emulation. Since ApexDC++ isn't anything more than DC++ with added features, it still has the right to identify itself as DC++.

[Lee 84]

No, it's not. It depends on kind of emulation. Since ApexDC++ isn't anything more than DC++ with added features, it still has the right to identify itself as DC++.

Furthermore, when emulated... these extra features are disabled.

Slot ratio will be change in next version.

[Guest Toast]

urgh why not simply just get rid of emulation if hubowners and ops do ban client they loose more then half the hub anyways then they will be forced to reconsider.

and p.s it shouldnt emulate per default.

Edited August 8, 2009 by Toast

[Big Muscle 1]

it is and discrimination only occurs on nmdc hubs in ADC is accepted as a normal client

Also, I don't agree with this opinion. It's true then nowadays there's small amount of ADC hubs. These are run by clever people which accept all clients. But in the future, when ADC extends more (if it ever happens), some ADC hubs will ban clients too. This has nothing to do with used protocol but with OPs/admins intelligence.

[Lee 84]

It's extremely difficult to persuade hub owners to allow clients in hubs too, they are too ignorant in many cases.

[adrian_007 0]

remove emulation at all in ADC - i did it

this way we'll get rid of emulation on new protocol. also ADC doesn't have problem "Turn on your tag" which in most cases forces me to use emulation [;

[Lotus 0]

Since ApexDC++ isn't anything more than DC++ with added features, it still has the right to identify itself as DC++.

If Apex *IS* DC, then how can Apex *EMULATE* DC ? You can not emulate yourself. And if APEX = DC + FEATURES, then let the name "Apex" as it is... because it means just this. Why use 2 names ? Why this option: emulate / not emulate ?

The question is: what is the purpose of emulation ? And I think this is clear for everyone.

If I am a hub owner and I don't want to allow ApexDC in my hub, you can override this with emulation. And you keep this option just because of this.

It's extremely difficult to persuade hub owners to allow clients in hubs too, they are too ignorant in many cases.

So, if they don't want to allow your client, you override their decision. Because they don't know what they are doing and they are ignorant.

The only problem is that it is their hub. Not your's. And they should be left to rule it as they want. Dumb or not dumb, ignorant or not, according to your criteria.

You can play with words as much as you like. As I said, emulating is cheating.

[Guest Toast]

i have to agree with BM on this ignorance on the networks is a problem for future development on client still i would love to see that it doesn't emulate per default rather enabled manually instead.

perhaps DHT is the way to go thus taking hubowners out of the equation..

[Big Muscle 1]

also ADC doesn't have problem "Turn on your tag" which in most cases forces me to use emulation [;

This is not a problem of any protocol. When someone writes hubsoft with condition "if VE<>++", it will write you "Turn on your tag" (or similar message) in ADC too and you will be forced to use emulation too.

OK, but one thing should have been done - rename "emulation" to "Send real core version to hub".

[Lotus 0]

this way we'll get rid of emulation on new protocol. also ADC doesn't have problem "Turn on your tag" which in most cases forces me to use emulation [;

I'm not expert at protocol and this, but I've noticed you send: "$MyINFO $ALL Nick <RSX++ 1.00> <++ V:0.707,...>" while StrongDC (and other clients) send: "$MyINFO $ALL Nick <StrgDC++ V:2.22,...>" in tag. I don't know what is the correct syntax, RSX looks better imho, because is sends both the "core" and the "rsx" version, however hubs have problems with it. For example: Verlihub ask you to turn on the tag, as you mentioned, YnHub lets you in but uses <RSX++ 1.0> as the nick description. Now, this may be mecause poor hubsoft implementation, as BM said. But until hubsofts will provide support for this tag format, why don't you use something like "$MyINFO $ALL Nick <RSX++ V:1.00,...>" ? Isn't this better then emulation ? One more time, this is more like a curiosity for me, I'm sure you have your reasons and as I mentioned before, my protocol knowledge is that of a beginner. Thank you.

[Crise 26]

If Apex *IS* DC, then how can Apex *EMULATE* DC ? You can not emulate yourself. And if APEX = DC + FEATURES, then let the name "Apex" as it is... because it means just this. Why use 2 names ? Why this option: emulate / not emulate ?

The question is: what is the purpose of emulation ? And I think this is clear for everyone.

If I am a hub owner and I don't want to allow ApexDC in my hub, you can override this with emulation. And you keep this option just because of this.

So, if they don't want to allow your client, you override their decision. Because they don't know what they are doing and they are ignorant.

The only problem is that it is their hub. Not your's. And they should be left to rule it as they want. Dumb or not dumb, ignorant or not, according to your criteria.

You can play with words as much as you like. As I said, emulating is cheating.

You know, Apex can be spotted even when emulating... and it will even more so when we merge some changes from SDC. If the hub owners are too lazy to figure out how, then sorry no cookie for them

You say emulating is cheating if that is the case then do something about it, don't expect us do it for you. Because we obviously do not think that emulation is cheating (since if we did that option would have been removed ages ago).

Anyways, could you perhaps give me a list of reasons why DC++ 0.75 (since that is the version we "emulate") should be allowed in a hub and Apex shouldn't... I am more than interested in hearing these reasons. If you are unable to do this then the whole discussion about emulation going on in here is pointless (since I don't even consider changing anything if the reasoning behind it is "just because").

I'm not expert at protocol and this, but I've noticed you send: "$MyINFO $ALL Nick <RSX++ 1.00> <++ V:0.707,...>" while StrongDC (and other clients) send: "$MyINFO $ALL Nick <StrgDC++ V:2.22,...>" in tag. I don't know what is the correct syntax, RSX looks better imho, because is sends both the "core" and the "rsx" version, however hubs have problems with it. For example: Verlihub ask you to turn on the tag, as you mentioned, YnHub lets you in but uses <RSX++ 1.0> as the nick description. Now, this may be mecause poor hubsoft implementation, as BM said. But until hubsofts will provide support for this tag format, why don't you use something like "$MyINFO $ALL Nick <RSX++ V:1.00,...>" ? Isn't this better then emulation ? One more time, this is more like a curiosity for me, I'm sure you have your reasons and as I mentioned before, my protocol knowledge is that of a beginner. Thank you.

Taking the RSX case when YnHub uses the "<RSX++ 1.00>" as description, it is doing the right thing... because that *is* the description (whether it is automatically added or manually typed is irrelevant).

[Big Muscle 1]

Also people should realize that there's no emulation. Since original NMDC client doesn't have any tag, it's a bug in NMDC hubsoft implementation if it detects clients by tag. Tag is only a part of description where user with original NMDC client can write what he wants.