Converting huge project from Au3 to multiplatform GUI application

[ALIENQuake]

Hello everyone,

Finally I decide to ask hard question about one of the project which I currently maintain:

Big World Setup aka mod installer for infinity engine games like BG, IWD, PST etc

Project page: https://bitbucket.org/BigWorldSetup/bigworldsetup/overview

More screenshot: https://forums.beamdog.com/discussion/44476/tool-big-world-setup-bws-mod-manager-for-baldurs-gate-enhanced-edition-trilogy-for-windows/p1

General Features

• downloading mods (please see remarks!)
• easy mod installation
• correct install order of mods/components
• handle mod and components conflicts and auto solve them
• easy backup creation/restoring
• ability to add you own mods

Internal Features (every single feature which you see here is already working in autoit)

  Reveal hidden contents

Big World Setup features list for developing new version of it:

 

General guides:
- next version of Big World Setup should not be named "Big World Setup <something>"
- threat changing of the options by players as hacking of the pentagon
- ideally, next BWS should be developed using language which doesn't require compilation for rapid development/recreation of every important features of old BWS

 

What things next Big World Setup don't need:
- beautiful GUI:

 

Next BWS needs a GUI Framework which will be able to dynamically add/modify/remove mod components/provided values directly from the mod list in order to add new mod components directly via right-click at mod name > "Add new component"

 

Auto-Update of the main application:
- this should be the first feature which you should develop and test. Do not make the same mistake as 90% of application aka "we will develop auto-update later, now we will just point to archive download" - it will stay this way forever
- proper, best and flawless auto-update process, exactly the same which Spotify application has:

1. No popups, questions, confirmation dialog etc for auto-update
2. Application silently check for updates
3. when it finds it, it  silently download and extract new version of the application to update folder
4. at the next start of the application, it will check if there is a new folder with new version of the app
5. if yes, app will be launched from the new folder
6. exept when the installation process was stoped and the application will resume already ongoing weidu mods installation

- this way, users will always get latest version of the app without any interference and without possibility to break ongoing installation with changes made to install order

 

Main Features:
- support for single game: BG2, BG1EE, BG2EE, IWD1, IWD1EE, IWD2, PST, PSTEE
- support for multi games: BGT, EET
- auto-detection of the game paths ( registry, default location )
- detection of the proper game installations for games with different releases (BG1/BG2 CD's full installation)
- detection of the missing patches for classic version of the games
- verifying clean installation state of the games, no files inside overide + empty weidu log
- creating and restoring special backups of the games which skips Data\* files for much smaller size

- ability to choose multiple languages for available mods list: PO,EN,GE means 'give me all mods in polish and use it as main language, when there is no polish, choose english, if there is no polish or english, choose greman, dont show mods without atleast one of the selected language)

 

Compilation of mods aka Custom Mod Packs
- build-in compilation of the mods: minimal, recommended, standard, expert + few user-made compilation
- enabling expert components should be possible only by choosing expert compilation
- different colors/icons for different mods category (expert=red, recommended=green)

 

Downloading:
- multi-thread mods download from various filehosting
- some of the filehosting require workarounds

 

Extraction:
- proper extraction of the mods archive, including taking care of unnecessary duplicated folders
- hacking of the NSIS installers which doesn't provide a way to extract the mod files unless extracted
  (invoke exe, redirect and wait for extraction, kill NSIS process)
- OverwriteFiles function

Conflicts types:
- All mods/components depend another, so the mods will not be allowed to be installed alone. Only in a bunch of all mods.
- Multiple mods/components need another (to coexist). The mods X1, X2, [...Xn] need Y if installed together. Y is not needed if any of X is missing.
- One mod/component need multiple others. The mod X needs Y1, Y2, [...Yn] to be installed. This does not mean that Y1 needs Y2.

- One (or more) components need one of multiple possible components. So if any of the components on the right are installed, the dependency is solved.

- Advanced conflict - check Splits String by ':' (lets call it area). If one of the items is selected (or all of a group if '&' is used), it's displayed as a conflict. Advantage to normal conflicts: *Mods in an area are not treated as conflicts. *Mods can have conflicts in groups. So if two combined mods have a conflict with a third one, this is the ways to go.
The mods X1, X2, [...Xn] all have a conflict with Y. X1 and X2 do not have a conflict, so they can be installed without problems.

- One mod needs another - not opposite
- One or more mod has conflicts with another
- One or more component has conflicts with another. You can use combination of (-) and (number).

- Mods that depend on BGT/EET, a special language-selection or a version of the game are listed in the Game.ini's [Purge]-section. These are not shown in the selection-menu if the conditions are not matched, so people don't get confused.
- a connection for some specific fix for another mod but only for main language of the mods translation that is on top of "BWS Translation" section.

Conflicts Solve:
- automatically
- manually via GUI
 

Additional Logic:
- continue installation
- report errors
- pause when errors occur
- ignore errors and continue installation
- do not pause installation for skipped components

 

Saving and loading user chosen mod/component lists
- export/import of the mod selection along with custom user answers

 

Comandline hook:
- save all output without affecting performance
- detect certain events (weidu errors, weidu skipped components)
- providing answers to questions displayed inside commandline

 

Save game backups
- since every installation is different, next BWS should backup all save games

 

Logging/Debbuging
- log for checking if the mod packages are online
- log for mod extraction
- log for weidu installation

 

It look as simple GUI application but it has quite complicated logic regarding "handle mod and components conflicts and auto solve them" - this is most important feature of the app.

This app needs to be converted into multi-platform GUI application because Enhanced Editions of the game can be played on OSX and Linux also. But for the past 6 years, there wasn't a single gamer/developer who would try to convert this app using multi-platform language and GUI. 

This is the moment when I'm asking for help:

- Which language would suit the best for multi-platform GUI application?  c#,python,java or other?

- Is there any general approach for such conversion? 

- Does autoit community/developer have some experience with converting autoit GUI applications into multi-platform GUI app by using multi-platform language like c#,python,java

- Is there someone who isn't scared by looking at the source code of the application and feature list to help me with converting or even begin with creating multi-platform GUI app template which will just simply run the same commandline for every system ? 

If there is something else which you would know, pleas ask and I will try to answer my best.

 

Edited February 5, 2017 by ALIENQuake

[ALIENQuake]

One last thing: If we are talking about paid work, how much it would cost? It's hard to say how long it would take to recreate most important features but I would say it's minimum 3 months.

[Guest]

 

Maybe my suspended project may help

 

First start with running the exampels under

https://github.com/gileli121/CU3-Library/tree/master/Examples/main

The examples cover all the functions (https://github.com/gileli121/CU3-Library/blob/master/gui.h) I wrote.
use the examples and play with them in depth.

I do not have much time at the moment to give a lot of support. I checked the functions but that does not guarantee they are bug free. If you find a problem, please report it (inside github platform) 

 

I would note that I am not going to continue to develop these functions in the coming months. Feel free to implement any missing function you need.
please share the code of these missing functions so I'll add them later (of course, I will mention the name of author).
If you want me to add missing functions in my project page, follow the same  standard of organizing the code:

• If you make new function for GUI - The function must be inside gui.h under "CU3_NAMESPACE_START" .
• If the function have the same name of it's parallel function (in Autoit), the function must be the same also in it's parameters and behavior (as described in the Help file of Autoit)
• If the function is not exactly the same like in Autoit, The function name must end with "_C"
• Use the the standard retun type "CU3_CTRL" If necessary.  If you think to change this standard, do it after very careful thought.
  • Don't make any changes that will force you to change the functions I worte

 

 

EDIT:

Oops, I had a misunderstanding .. I thought you wanted to do this work yourself. I understand that you are asking someone else to do it .. I do not have time to perform such work. I am currently busy with other things. 

 

Edited February 5, 2017 by Guest

[Jos]

Currently locked and under review by the Mod team for:

• Check whether this is in conflict with our Forum rules.
• "rent-a-coder" type question.

Jos