Quote:
Originally Posted by amagedon99
A post without evidence is just as questionable as the claims you're criticizing. Back up your accusations with facts, or they're just speculation.
Since the doors are open, it shouldnt take u to long to find it out, as u did before on many other scammers.
Seems u didnt do ur work correctly and wanted to lash out just.
|
I've done my homework. And since the old thread design has disappeared for whatever reason, here we go.
So, let's get started.
And just to clarify one thing:
I never called them scammers. I called them liars. (:
1. The "Official" GM Tool
Quote:
|
Regarding the GM Tool, the presentation literally says it's the official Entwell console. We just hooked up the leaked retail UI to our custom backend. Why waste hundreds of hours coding a new UI for Game Masters when the original one works perfectly?
|
Interesting, because your own presentation says something completely different:
Quote:
|
Official Entwell Game Master administration console compiled directly from retail source code for managing connected players, monitoring event states, spawning entities, item generation, and live server moderation.
|
So you're claiming that you compiled the GM tool directly from retail source code that you don't even have?
Nice. And trust me, I know you don't have it. :lul:
There's quite a difference between connecting an existing leaked tool to your backend and compiling something from the original source code.
But apparently, those are the same thing now.
2. The "Authentic Retail Source Code" Launcher
Quote:
Authentic Retail Source Code
Unlike private servers that rely on custom third-party wrappers, NTServer utilizes the official Entwell Delphi 2006 launcher compiled directly from authentic retail source code, preserving the 100% authentic NosTale launcher experience and official patch protocols.
|
Oh, look. The exact same claim again.
So you also managed to compile the official Entwell launcher from authentic retail source code?
Quite impressive, considering you don't have that source code either.
But whatever. :lul:
3. Your Claims About .dat Files
Now let's move on to your claims about .dat files.
How does parsing the original .dat files guarantee 100% client parity when BCard behavior, fairy scaling, and skill execution still depend on the server-side implementation?
Reading the correct values doesn't mean the underlying game mechanics are implemented correctly.
And why exactly would using JSON or YAML as an intermediary format cause data loss?
Could you explain which specific values or data types would be lost during a properly implemented conversion, considering that both formats can preserve the required data without any loss?
Parsing the original files doesn't magically give you the original server-side logic.
So, once again, just marketing buzzwords that mean absolutely nothing. (:
4. Your Thread Comparison
Let's ask a few more questions.
Why do you claim that having 58 threads is worse than having 8?
What actually matters is CPU utilization, scheduler behavior, actual parallelism, synchronization, and response times.
A server with 58 threads can certainly be more efficient than one with just 8 threads.
And then there's this masterpiece:
Quote:
|
This guarantees thread safety without race conditions.
|
That's technically incorrect.
Using modern C++ concurrency primitives does not automatically guarantee thread safety.
In fact, race conditions can occur precisely because these mechanisms are implemented or used incorrectly.
Using C++ doesn't magically make your code thread-safe.
But let's ignore a few more things, since the server doesn't even seem to have any real developers.
5. Your "100% Retail Exact" Damage Calculation
This one is especially funny.
Quote:
|
Formula & BCard Accuracy: 100% Retail Exact Binary Parity
|
Compared to:
Quote:
|
Manually approximated formulas & community guesswork
|
Nice.
So you somehow managed to obtain the complete original server-side damage calculation simply by reading .dat files?
:lul:
Did Entwell secretly include the entire server-side combat implementation inside those files?
Because parsing client data doesn't give you the original damage formulas, the exact calculation order, or the complete BCard execution logic.
Client data and server-side implementation are two completely different things.
And unless you have access to the original server source code or have independently verified every single mechanic, claiming 100% retail accuracy is nothing more than an unsupported marketing claim.
But sure, everyone else is apparently just guessing while your .dat parser magically knows everything. (:
6. Your "Authentic Retail C++ Core" and "Entwell NTServer"
Quote:
|
Authentic Retail C++ Core (100% accurate formulas and logic)
|
And let's not forget what you decided to call your server in the comparison:
Quote:
Wait, what? :lul:
Are you seriously presenting your custom C++ emulator as an authentic retail server core and even labeling it "Entwell NTServer"?
You literally stated that your server was built from the ground up in C++, yet you're using terminology that makes it sound like you're running an original Entwell server.
Since when did writing your own emulator make it an authentic retail core?
And why exactly are you putting "Entwell" in front of your server's name in a technical comparison?
Are you trying to imply that your server is officially associated with Entwell or that it's based on their original server technology?
Because unless you actually have access to the original Entwell server source code, it's still just a custom emulator.
And then there's your claim of "100% accurate formulas and logic."
How exactly did you verify that?
Did you somehow obtain the complete original Entwell server implementation, or are we back to your magical .dat parser again? :lul:
Reimplementing retail behavior doesn't turn your custom emulator into an authentic retail server core.
And calling it "Entwell NTServer" doesn't magically make it an official Entwell product either.
At this point, you're not just exaggerating technical features. You're using wording that could easily mislead people into believing your server has some kind of official connection to Entwell.
So which is it? A custom emulator built from scratch, or an authentic Entwell retail server?
Because your marketing seems to suggest both. (:
7. Your "Verified Live Production Telemetry"
And finally, my personal favorite:
Quote:
|
Verified Live Production Telemetry
|
Bro had 4 players online, managed to read a few statistics, and called it verified production telemetry.
Four players.
FOUR.
What exactly is that supposed to prove?
That your server can handle four connections without exploding?
You can't seriously present four active players as meaningful evidence of MMORPG server performance or scalability.
Please kill me. :lul:
Conclusion
At this point, the entire presentation seems to consist of technical buzzwords, misleading comparisons, and claims that aren't backed up by any meaningful evidence.
Claiming to have original Entwell source code, advertising 100% retail accuracy just because you parse .dat files, and presenting four players as a performance benchmark doesn't make your server technically superior.
It just makes your marketing look ridiculous.
Less AI generated marketing nonsense, more actual technical evidence, please. (: