Metin2 Patcher with Electron

[Karbust 6710]

7 hours ago, FNCX said:

what's the point of running a browser that consumes memory a lot compared to other drawing guis for patcher lmao

I made it in electron for 2 reasons, I wanted to learn how to use for a long time, and because I could use React to do it, like a website.

I agree electron uses a lot of memory and the bundle size is big, because it bundles the entire chromium browser.

 

I have seen an alternative that uses the system browser API instead of bundling an entire browser, however, it is made in Rust, it is Tauri, I'm not interested in learning it.

Quote

WRY is a cross-platform WebView rendering library in Rust that supports all major desktop platforms like Windows, macOS, and Linux. Tauri uses WRY as the abstract layer responsible to determine which webview is used (and how interactions are made).

You are more than welcome to explore it, if you already know Rust then it should be pretty straightforward.

 

5 hours ago, b6d4a82c15 said:

Nowadays computers are much more powerful and so electron/CEF apps have become the norm. It's also easier to develop and maintain.

Slack, MS teams, discord, whats, spotify, battle.net client, Adobe Illustrator and many others are running inside embedded browsers.

It is easy to maintain a electron application because you can have it use the same code base as the main website (if that is something the developer wants to do), just needs to add some abstraction layers to determine what API to use, if the electron, or the browser, other than that, it just works.

And by the way, Adobe software is written in C++ (Qt), as far as I know.

MS Teams used to use Electron but changed to WebView2: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/microsoft-teams-advantages-of-the-new-architecture/ba-p/3775704

But yeah, many companies use Electron for their applications because if makes deploying a product fast and easy.

[b6d4a82c15 298]

18 minutes ago, Karbust said:

I made it in electron for 2 reasons, I wanted to learn how to use for a long time, and because I could use React to do it, like a website.

I agree electron uses a lot of memory and the bundle size is big, because it bundles the entire chromium browser.

 

I have seen an alternative that uses the system browser API instead of bundling an entire browser, however, it is made in Rust, it is Tauri, I'm not interested in learning it.

You are more than welcome to explore it, if you already know Rust then it should be pretty straightforward.

 

It is easy to maintain a electron application because you can have it use the same code base as the main website (if that is something the developer wants to do), just needs to add some abstraction layers to determine what API to use, if the electron, or the browser, other than that, it just works.

And by the way, Adobe software is written in C++ (Qt), as far as I know.

MS Teams used to use Electron but changed to WebView2: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/microsoft-teams-advantages-of-the-new-architecture/ba-p/3775704

But yeah, many companies use Electron for their applications because if makes deploying a product fast and easy.

Not all Adobe products are written in qt, and surely not all their components. Either way, its cost-effective and easy deployment like you said. Javascript developers are also much cheaper to employ hehe

[FNCX 0]

i didn't say electron is useless, i said what is the point of making metin2 patcher with electron. 
 

Quote

I wanted to learn how to use for a long time

That explains

[Karbust 6710]

15 minutes ago, FNCX said:

i didn't say electron is useless, i said what is the point of making metin2 patcher with electron. 
 

That explains

And what is the problem of having a patcher made in electron? It is still good for a metin2 patcher, my services are even based on it.

 

Also, is this a lot of memory?

Could be lower using something like Tauri or even full C# or C++, but it is actually not that bad.

Edited November 14, 2023 by Metin2 Dev International
Core X - External 2 Internal

[FNCX 0]

25 minutes ago, Karbust said:

And what is the problem of having a patcher made in electron? It is still good for a metin2 patcher, my services are even based on it.

 

Also, is this a lot of memory?

Could be lower using something like Tauri or even full C# or C++, but it is actually not that bad.

Unless you're gonna develop this thing to become not just a patcher, I think it's just waste of resources, and it's not just about the ram which is plenty these days, it also creates lots of junk files inside AppData and other locations, file size is much bigger. Again, just for a patcher.

Edited November 14, 2023 by FNCX

[Karbust 6710]

5 minutes ago, FNCX said:

Sorry, but all of your statements are just excuses. You can even make a patcher via bat using curl, we're not talking about if patcher is working or not, because, as I told you before, you can code a patcher using bat files. That's not the case.

Do you really care about the memory at this point? I mean would you take a shit if it's consuming 500MB ram? 

You coded an app that streams files over internet and it's usage takes 95MB, is that fine? 

We both know that it will increase whenever you add new stuff such as Discord app.

Not even mentioning it's instance bullshit thanks to Chromium browser.

 

Also, your code will always be visible and people will always manage to unpack your packer, steal everything.


Default Hello World electron app takes 45-46MB file-size, how much yours take?


The thing is that I'm saying these in Metin2 forum, a forum that developers have knowledge in Python and C++, while I'm JS developer, I say electron is the worst thing you could use for this project and you say no, it's not.

Edited: Usually JS developers claim Electron is the best thing you can manage a web app etc, that's why I said this.


I'm not saying Electron is useless, I'm saying Electron is not suits for this kind of project.

I have no problem with all you are saying because those are all valid points, except about the unpack part, code wise it can be obfuscated, by that order of ideas then C# apps also have their code always visible, that is a useless point to make.

 

The patcher compressed with electron-builder on the normal compression mode occupies around 94MB to 98MB.

Also, when needed I can write a node C++ package, had to do it for something to access the Windows API in more than one occasion.

 

I use electron because I can use whatever I want to do the frontend, and electron is also extremely popular, I could be using MAUI, Avalonia, Qt, Tauri, and many others, but from all of them, only Electron and Tauri are well supported and can use web frontend technologies to develop the UI, for me that is a great and a trade I'm willing to make in memory usage. There is also Electron.NET, that uses Electron behind the scenes with a C# backend instead of Node.js but isn't very popular. And, like I already said, I'm not willing to learn Rust to use Tauri.

I'm a web developer and I'm not locked to JavaScript/TypeScript, in fact on the backend I use ASP.NET C#, with React frontends.

(Another thing, I hate Python, so not even dead I would even think of using it for anything other than the metin2 GUI.)

 

And, to finalize, please contribute something useful to the community, 3 out of your 6 posts are complaining about Electron, pick a tool and do a patcher for the community, or share something else.

It's because of minds like that that the metin2 scene doesn't evolve, always using the same thing for everything.

[FNCX 0]

1 hour ago, Karbust said:

And what is the problem of having a patcher made in electron? It is still good for a metin2 patcher, my services are even based on it.

 

Also, is this a lot of memory?

Could be lower using something like Tauri or even full C# or C++, but it is actually not that bad.

 

Quote

The patcher compressed with electron-builder on the normal compression mode occupies around 94MB to 98MB.

If that's normal for you for a patcher that should took 2MB at first place, then OK.

 

Quote

Also, your code will always be visible and people will always manage to unpack your packer, steal everything.

No, if you code it with C++ and protect your binary, all they could do is dump the binary which they won't for stealing UI

Edited November 14, 2023 by FNCX

[Koray 3334]

Maybe it was acceptable in 2021, but these days, there is no reason to stick with Electron when Tauri provides many more advantages in every aspect. It's extremely lightweight, faster, and more memory-friendly. In addition to React, there are many 'modern' alternatives for the frontend, such as Svelte, Yew, and Next.js. 

[bacatamaduitorul 1]

On 4/5/2021 at 11:47 PM, Karbust said:

M2 Download Center

 

Hidden Content

• Give reaction to this post to see the hidden content.

( Internal )

 

 

GitHub Repository: 

Hidden Content

• Give reaction to this post to see the hidden content.

 

            The tutorial bellow is also available on the repository.

  

Metin2-Patcher-Electron

A simple metin2 patcher made in Electron with React and TypeScript. The file verification is made with SHA256.

Getting Started

Install NodeJS: https://nodejs.org/en/download/

Install Yarn: https://yarnpkg.com/getting-started/install

Clone the repository:

git clone https://github.com/Karbust/Metin2-Patcher-Electron

Install the dependencies:

yarn install

Edit src/config.ts with your own values. Change resources/icon.png with your own logo (should be at least 256x256).

Available Commands

Command	Purpose
yarn run start	Starts the React App (aka Frontend) in development mode.
yarn run build	Builds a production ready React bundle.
yarn run electron-start	Starts the Electron App.
yarn run electron-pack	Builds a production package of the app.
yarn run lint	Check for linting errors.
yarn run lint-fix	Fixing some linting errors.

About the Patcher

This project was made with the intend of learn more about Electron, something I wanted to do for a while.

If the folders don't exist, they'll be created. If the files don't exist they will be downloaded.

The patcher checks the local files and if their checksum mismatches the remote checksum, they will get downloaded.

This patcher runs the downloads asynchronously, this means it will download multiple files at the same time.

The entire project is made in React and Electron both with TypeScript. For CSS was used TailwindCSS.

Deploying

After editing everything you must use the command yarn run electron-pack to build the application.

It will build 2 files inside the release folder:

• Metin2 Patcher Electron-X.X.X-win.zip
• metin2_patcher_electron.exe

The first file is the full bundle zipped that can be extracted to the client folder (after removing the 2 unnecessary LINCENSE files). DON'T USE THIS IF YOU ALREADY HAVE THE CEF BROWSER ON THE CLIENT.

The second file is also zipped but will be extract to a temporary folder during runtime (takes about 3 seconds to fully open) and clean after itself when it closes. This is the way if you can't perform the first option.

Development Testing

In case there isn't the possibility to use a local webserver (like Apache with Xampp, or Wampp) it may be necessary update the CORS on your remote server.

For NGINX

Go to the configuration file for the patcher host and add this line:

add_header 'Access-Control-Allow-Origin' 'http://localhost:3000';

For Apache

Go to the configuration file for the patcher host and add this line:

Header set Access-Control-Allow-Origin "http://localhost:3000"

It may also be needed to activate the headers module:

a2enmod headers

Web Server

Using

Hidden Content

• Give reaction to this post to see the hidden content.

, you shall place the client files inside a folder called files and run the script.

 

It will generate the JSON file with the names, sizes and checksum hash of the files.

 

Issues

If you have any issues, post here or open an issue on the repository: 

Hidden Content

• Give reaction to this post to see the hidden content.

 

Have any ideea how to fix the types error? 
../node_modules/@types/react/ts5.0/index.d.ts(4495,13): error TS2717: Subsequent property declarations must have the same type.  Property 'polyline' must be of type 'SVGProps<SVGPolylineElement>', but here has type 'SVGProps<SVGPolylineElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4496,13): error TS2717: Subsequent property declarations must have the same type.  Property 'radialGradient' must be of type 'SVGProps<SVGRadialGradientElement>', but here has type 'SVGProps<SVGRadialGradientElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4497,13): error TS2717: Subsequent property declarations must have the same type.  Property 'rect' must be of type 'SVGProps<SVGRectElement>', but here has type 'SVGProps<SVGRectElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4499,13): error TS2717: Subsequent property declarations must have the same type.  Property 'stop' must be of type 'SVGProps<SVGStopElement>', but here has type 'SVGProps<SVGStopElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4500,13): error TS2717: Subsequent property declarations must have the same type.  Property 'switch' must be of type 'SVGProps<SVGSwitchElement>', but here has type 'SVGProps<SVGSwitchElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4501,13): error TS2717: Subsequent property declarations must have the same type.  Property 'symbol' must be of type 'SVGProps<SVGSymbolElement>', but here has type 'SVGProps<SVGSymbolElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4502,13): error TS2717: Subsequent property declarations must have the same type.  Property 'text' must be of type 'SVGTextElementAttributes<SVGTextElement>', but here has type 'SVGTextElementAttributes<SVGTextElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4503,13): error TS2717: Subsequent property declarations must have the same type.  Property 'textPath' must be of type 'SVGProps<SVGTextPathElement>', but here has type 'SVGProps<SVGTextPathElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4504,13): error TS2717: Subsequent property declarations must have the same type.  Property 'tspan' must be of type 'SVGProps<SVGTSpanElement>', but here has type 'SVGProps<SVGTSpanElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4505,13): error TS2717: Subsequent property declarations must have the same type.  Property 'use' must be of type 'SVGProps<SVGUseElement>', but here has type 'SVGProps<SVGUseElement>'.
../node_modules/@types/react/ts5.0/index.d.ts(4506,13): error TS2717: Subsequent property declarations must have the same type.  Property 'view' must be of type 'SVGProps<SVGViewElement>', but here has type 'SVGProps<SVGViewElement>'.
error Command failed with exit code 2.