Cannot login to Vortex

[Guest deleted34304850]

Even if that were true, it would be completely irrelevant. This is the Vortex support forum.

Besides, maybe others who had the same issues as me were just told "Lol it's your firewall not our problem" and gave up, mister Tuxedo.

what others? this is something that has never been reported previously - search the forum.

this is entirely unique and from the get go you have framed it as a program error when it absolutely isn't.

you can exclude as many things as you want from your "analysis" all that does is make it more difficult for you to understand the ACTUAL root cause which is, based on the limited information available, entirely local to you.

 

you keep framing it the way you want - the truth, and the root cause, is entirely different.

[KoelianTheSecond]

I'm sorry, but if your critical thinking skills and understanding of writings in the English language are stressed so much beyond their capabilities by this topic, you may want to bow out. I won't begrudge you for it, I promise you.

After all, you have provided absolutely nothing to help with the issue, Tuxedo, other than getting hung up on it being a network issue despite me having made it clear it wasn't from the very start.

 

There have been threads in the past for issues that seem similar to mine. You show up, tell them it's a network issue (which it most likely wasn't, this isn't the 90s anymore) and leave them in the famous creek without a paddle.

Edited May 10, 2022 by KoelianTheSecond

[Tannin42]

We would help you if we could but the reality is: your computer and your network is your problem, any help you receive is given voluntarily.

 

If you come out of the gate pointing fingers, "demanding" help as if you were entitled to it and attacking those that would try to help you if you don't like what they have to say, the willingness for people to invest their own time to fix your issues disappears rapidly.

You would be surprised how helpful people can be when you're not being a **** to them.

 

I can assure you, we do not have code in Vortex going

if (username is "Koelian" and directoryname is "Vortex" and (drive is not "C:" or now - installtime > 12 hours)) then { hack(apiserver).then(randomlyDropConnections()) }

Networking is more complex than you seem to realize. ECONNRESET doesn't mean Vortex couldn't reach the server, it means the connection was terminated on the TCP layer after being established.

but there is more stuff between application and TCP, e.g. SSL.

So for all I know the SSL layer in your OS does not agree with the SSL layer on the server and that causes the traffic to be interrupted.

Since it works for (just about?) everyone else that's still something obscure about your system, e.g. the network driver or windows version or some third party software taking over ssl handling.

 

My point is: There are thousands of moving parts between Vortex and the server, we know nothing about which one breaks.

The only thing we do know for a fact is that 99.99% of our users don't have this problem so for us to identify the issue we have to figure out what sets you apart from everyone else.

Once we know that, maybe there is something we can do. Maybe a driver update on your system helps, maybe you have malware you're not aware of.

Or heck, maybe there is something in Vortex we can do to make the connection more "forgiving" - increase some timeout, increase or reduce some buffer, allow for more connection retries than currently, ... - but before we can do anything, before I could even begin to guess whether anything anyone other than you could do would have any chance of helping, you need to figure out why your case is different from others.

 

I know the investigation has to start in your system, if you rule that out and refuse to even consider the option, there is nothing more to talk about. From the get-go you were rejecting the only sane course of action, which means all my time is likely wasted.

I want to help, I don't want to waste my time or anyone elses.

[KoelianTheSecond]

Mister Tuxedo is a very exhausting person to deal with. He has said his piece, that it's a "network issue" despite all evidence pointing to the contrary and refuses to entertain any opposing thought, blaming me instead.

That wouldn't be such a big issue if he said his piece and ceased there, but he keeps coming back repeating himself, providing absolutely nothing.

 

While I think you're also mistaken at least you're providing "something" to work off of.

 

I have not seen anything, other than the ECONNRESET error, that would point to this being a network issue. A network issue would either cause it to never work, or work sometimes randomly, or work for some time within a session and then randomly cut out.

When I install it to a new path it works without fail. As long as the program is open, it works perfectly. I downloaded a several GB texture mod and it performed perfectly. I was even watching a video during it, which could potentially cause issues to the connection. It didn't. It downloaded the mod (and everything else I tried) perfectly.

 

I know the investigation has to start in your system, if you rule that out and refuse to even consider the option

Perhaps you have mistaken me. I reject that it is a networking issue because there is no evidence pointing to this.

Non networking related issues though? Some file that's getting stuck and is somehow preventing the program from connecting for example. It would cause the program to give a connection error, without actually being a networking issue.

 

I don't know if some log could point to such a temporary file. Or if you know what temporary files I could try manually clearing (preferably without losing the data on installed mods).

Edited May 10, 2022 by KoelianTheSecond

[Tannin42]

I'm sorry, but if your critical thinking skills and understanding of writings in the English language are stressed so much beyond their capabilities by this topic, you may want to bow out. I won't begrudge you for it, I promise you.

After all, you have provided absolutely nothing to help with the issue, Tuxedo, other than getting hung up on it being a network issue despite me having made it clear it wasn't from the very start.

 

There have been threads in the past for issues that seem similar to mine. You show up, tell them it's a network issue (which it most likely wasn't, this isn't the 90s anymore) and leave them in the famous creek without a paddle.

 

Oh sweet summer child.

In the 90s, if a message got lost because of a bad copper connection you'd just repeat until it worked or a timeout occurred.

Today you have users using 10 year old windowses that haven't been maintained in 5 years trying to communicate with linux servers running 20 yo software with security fixes from last week patched into them - through layers of protocols that all revision updates, revisions being deprecated, supporting different feature sets so that they first have to figure out how to even communicate with each other and all needed to have security issues patched out of them on a regular basis.

That is then all built on top of the same protocols from the 90s and in many places on the planet going through the same copper wires just 30 years older.

[KoelianTheSecond]

My comment about the 90s was in reference to his insistence that somehow, without any concrete reasoning, my antivirus/firewall would decide "I'm going to block this program and this program alone now against my configuration, and not log it anywhere".

That's something software from the 90s might have done, not a modern antivirus on a modern operating system, interacting with a (presumably) modern software trying to speak to a (hopefully) modern server.

 

Having the first response to an issue of this type be "Must be the firewall blocking outgoing connections" is dated, modern home firewalls do not block outgoing connections and whatever they do is logged.

Doing it even though the very first post preemptively stated the firewall isn't an issue is frankly just demeaning and mocking.

Repeating it over and over despite all evidence is simply insulting.

[Tannin42]

I have not seen anything, other than the ECONNRESET error, that would point to this being a network issue.

You mean other than the only error message you got and the fact that network queries don't work?

This being a network issue is one of the very few things we do know.

 

A network issue would either cause it to never work, or work sometimes randomly,

That covers all the options, doesn't it? If it worked always it wouldn't be an issue...

 

When I install it to a new path it works without fail.

When you reinstall Vortex it literally just reinstalls the application files, those are non-mutable. It doesn't degrade and the installer doesn't change any data Vortex uses.

If this is true, if reinstalling Vortex without fail causes it to work temporarily, that is 100% proof, without the shadow of a doubt, this is *not* an issue in Vortex or the server

and that there is nothing we _could_ do to fix this.

In fact, it would proof that it also can't be anything outside your computer because no component outside your computer would even know that it's a new install, they couldn't

act upon that even if they wanted to.

 

 

Perhaps you have mistaken me. I reject that it is a networking issue because there is no evidence pointing to this.

Again: We know it's a networking issue, that is literally what ECONNRESET says.

 

Some file that's getting stuck and is somehow preventing the program from connecting for example. It would cause the program to give a connection error, without actually being a networking issue.

That is not how computers work...

Also, again: The connection isn't prevented. It is reset, probably after something else was sent.

This could be because some software on your system changes (as in: extends or corrupts) messages Vortex tries to send, maybe to a degree that Cloudflare then identifies as a DDOS attempt.

Maybe incorrectly.

 

 

I don't know if some log could point to such a temporary file. Or if you know what temporary files I could try manually clearing (preferably without losing the data on installed mods).

Again, it's not how computers work but also: The Vortex installer doesn't create or clear temporary files. Even if any kind of cache or temporary files could be involved, the fact reinstalling

Vortex temporarily fixes the problem has already disproven that theory.

[KoelianTheSecond]

You mean other than the only error message you got and the fact that network queries don't work?

The program's queries don't work. Doesn't mean it's a wider connection issue with the computer.

That's what's not supported by any evidence.

 

That covers all the options, doesn't it?

No? Doesn't cover the one that is happening, which is the program not working in an entirely repeatable and predictable manner.

 

When you reinstall Vortex it literally just reinstalls the application files, those are non-mutable. It doesn't degrade and the installer doesn't change any data Vortex uses.

If this is true, if reinstalling Vortex without fail causes it to work temporarily, that is 100% proof, without the shadow of a doubt, this is *not* an issue in Vortex or the server

and that there is nothing we _could_ do to fix this.

In fact, it would proof that it also can't be anything outside your computer because no component outside your computer would even know that it's a new install, they couldn't

act upon that even if they wanted to.

Vortex has no temporary files? No configuration files? Nothing outside of the static files inside the installation package? Really?

Where are all the user settings stored then, for example?

 

Again: We know it's a networking issue, that is literally what ECONNRESET says.

An issue that causes the program's connections to fail. Not a wider networking issue.

A locked temproary fail could potentially cause such an issue depending on how the program works, doesn't mean the networking itself has issues.

 

That is not how computers work...

Err, yes. If the program uses some temporary file for connections, and that file becomes stuck for whatever reason, it could cause connections to open and then fail because they can't deposit whatever data they're transmitting.

It might not apply to this specific program (I don't know, I didn't make it) but it's absolutely how some programs can work, in a broad sense.

 

This could be because some software on your system changes (as in: extends or corrupts) messages Vortex tries to send, maybe to a degree that Cloudflare then identifies as a DDOS attempt.

Do you want my IP to check the server logs? Do you want a Wireshark output to see if the packets look strange somehow?

But again, if this was the case why does the program work perfectly when installed to a new path?

 

Again, it's not how computers work

Yes, it is. Or can be, rather.

 

The Vortex installer doesn't create or clear temporary files

I didn't mean the installer, but the program running.

Install to a "clean" path -> Vortex Works -> Vortex creates some malignant temporary/configuration/lock/whatever files that then prevent it from working the following times the program is opened from that path.

 

Even if any kind of cache or temporary files could be involved, the fact reinstalling Vortex temporarily fixes the problem has already disproven that theory.

Has it though? How so? As I said above it looks to me it reinforces it.

Edited May 10, 2022 by KoelianTheSecond

[Tannin42]

My comment about the 90s was in reference to his insistence that somehow, without any concrete reasoning, my antivirus/firewall would decide "I'm going to block this program and this program alone now against my configuration, and not log it anywhere".

That's something software from the 90s might have done, not a modern antivirus on a modern operating system, interacting with a (presumably) modern software trying to speak to a (hopefully) modern server.

Nope, modern AVs are way worse in this regard (and any other really) than anything we had in the 90s.

 

Having the first response to an issue of this type be "Must be the firewall blocking outgoing connections" is dated

Nope, it was a very reasonable assumption.

 

modern home firewalls do not block outgoing connections and whatever they do is logged.

Most of them: no, not by default. How is anyone to know how you configured your firewalls though? Whether it's even you who maintains the firewall?

 

What Firewalls also do do is meddle with ssl encryption/certificates because (as far as I understand it) for a firewall to monitor traffic, it has

to hijack the encryption, otherwise it wouldn't be able to read the network traffic.

So very intrusive AVs, like Kaspersky, do that and then when you incorrectly remove the AV or stop updating it the certificates eventually expire and https connections start to fail.

In a browser you can ignore that, in api connections you can't.

 

That would, to my knowledge, always produce a different message than what you're seeing but it's not unreasonable for someone trying to help you to think in that direction.

 

Again: You're basing a lot of assumptions on very limited knowledge. You so very much underestimate the complexity of the topic.

Modern AVs and Firewalls are way more complex than blocking connections based on port TCP/UDP in/out because they needed to sell "features" for the last few decades.

And they sell "user friendliness" which usually means exposing less information to users.

 

Doing it even though the very first post preemptively stated the firewall isn't an issue is frankly just demeaning and mocking.

It's your decision to take it as demeaning but you have demonstrated thoroughly that you have very incomplete knowledge of the matter. I'm sorry, but we can't follow you down a path of

thinking that we know is incorrect, wasting everyone's time, just so we don't hurt your feelings telling you you're not as knowledgeable as you think you are and therefore your

conclusions aren't as trustworthy as you think.

[Guest deleted34304850]

a few pages ago, i said the only troll in the conversation was you. you're increasing tantrum posts only reinforce that assumption.

 

i'd like your analysis on how reinstalling the same program on the same system but in a different directory has a completely different effect on how you can "all of a sudden" connect to the server.

in your own time.

 

in the meantime - whether you like it, or don't (i really don't care) this stinks of a network issue. you have "analysed" the situation and concluded it isn't, here's the rub - your analysis is bullshit.

 

now, how does you installing the program in a different directory affect the way the program works? in your own time.