So, when we will this this Mod Manager in full glory? I remeber you posted some screenshot quite a long time ago, but still don’t have chance to test it 
That screenshot was largely UI mock-up with some semi-testing code to see what I can use from Qt.
Right now launcher is mostly ready, I’m going to upload it to trunk in 1-2 days - cleaning out remaining bugs right now.
What I have right now is:
- Basic install/remove & enable/disable mod.
- Repository with all mods that were already updated to 0.94 (new mod.json fields), packaged into zip’s. Right now located in my Dropbox, will talk with Tow about moving it to vcmi.eu once launcher is out.
- Mod downloading functionality (obviously)
- Settings editor, for options that don’t have in-game UI.
What I still don’t have:
- Better support for dependencies like installing dependencies along with required mod.
- Error reporting - launcher should handle any errors but right now it won’t display any message on what’s wrong to user.
UPD: it looks that we need to add some restrictions on what characters are allowed in mod name. This is certainly easiest way to fix case-sensitivity issues I’m running into right now.
What about this:
- Only lower-case latin symbols + numbers
- space and/or minus sign to act as separator
Everything else is prohibited. Any objections/better propositions?
I think space better be prohibited too.
What’s about CRC sums?
Maybe if mod.json includes CRC sum of Content (zipped or not), mod manager must alert user that mod is modified?
CRC sum is for future multiplayer games (question we discussed earlier - how to understand that mods are the same.
Or it is useless to put it to mod.json? (mod.json is not covered by this sum and will be vulnerable to commenting some jsons in content).
CRC sum can be calculated on a run, no need to include it “in” a mod.
This sounds awesome 
Good job!
But the original CRC sum is needed to tell, was mod modified by someone else than author.
PS What is meant by install/remove? Remove folder physicaly from Mods?
Then this feature needs to be hardened to fight accidentally clicking matter.
Or else mods can be accidentally deleted to nowhere
Perhaps. My suggestion was based on currently present mods which quite often use spaces in names. Anyway - it seems I found a way to fix this issue so no need for mod name filtering at the moment.
Main idea is that zip file contains precalculated checksum for each file. Calculating checksum normally means reading whole file (which is slow). But in case of zip all we need to do is to check files outside of archive.
Checksum will be calculated each time VCMI starts and compared to:
- checksum from previous run, to detect changed mods for such features like validation.
- checksum from other players in multiplayer. Unless somebody will come up with better solution to detect any changes in game data including H3 files.
- checksum from repository to warn player that mod was modified at all (not necessary since last start)
Right now this is still not implemented (and not a priority frankly)
I most likely will do this as part of proper dependencies support - this would need confirmation dialog anyway (“To install/remove mod X you also need to install/remove mods A,B,C. Continue?”)
It is not like I can’t fix something later. Launcher committed to trunk. Feel free to test it after finishing “compile it on Windows” quest.
- Compiling requires Qt5, QtCore, QtWidgets and QtNetwork (HTTP support for mod downloading) to be precise.
- Directory launcher/icons should be copied into VCMI directory (for packaging only I think)
- Repository list is empty right now, you can use mine Dropbox repo for testing. Copy-paste this link into Repositories list in settings: dl.dropboxusercontent.com/u/223 … itory.json and restart launcher.
Damn… QT installer for Windows is over 500 MB and it gets only worse later -.-
Okay, almost there. Just asking about this one:
Error 30 error C1083: Cannot open include file: 'ui_csettingsview.h': No such file or directoryThese files (3 of them in total) should be generated by Qt from *.ui files using their “moc” tool. Check editor project - it already uses this tool.
I couldn’t compiled editor at all, so simply have it disabled. Someone could explain that earlier.
Good job, Ivan! Three points could be improved from my side:
- After adding your repository a restart was necessary (not really a problem, but no hint or sth. like thatdisplayed)
- I can’t disable nor uninstall the Cove town after installtion. (it’s more a technical issue, than sth. with Cove
) - Perhaps you could show the mod info shown at the right by default.
Following this tutorial, this is what I got so far:
1> Compiling mainwindow.ui using MOC
1> E:\Programowanie\VCMI\vcmi\launcher\mainwindow.ui(0): Note: No relevant classes found. No output generated.Actually ui_mainwindow.cpp file exists, but is empty.
Is editor ready at some point?
Maybe you should use moc on appropriate headers instead of ui files?
Frankly I don’t know much about how to use moc either - cmake hides all this magic nicely behind 1-2 macro calls. Perhaps Tow or Tow Dragon will be able to help with this.
List of auto-generated files on my system, none are empty (but some are close to it - 4-5 lines)
Right now - no. Current editor project is basically empty.
beegee, thanks for feedback, will look into this.
- the main problem right now is to detect when user ends input. Perhaps reload repository as soon as player switches back to mods tab?
- I think I found it. Will fix. User-visible error reporting is still not here
- By default (when you start launcher) no mod is selected so there is nothing to show. Perhaps select first available mod on start?
Ivan, it’s great to see this done!
I have one big request to ease VS compilation:
could you group all moc-dependent files in a single filesystem subtree? Eg. create moc/ subdirectory, put there (possible with further subfolders) all header files that needs moc’ing, along with their cpp/up files?
Then we can add build rule for all headers under moc/ folder to run moc.exe on them. Otherwise it is impossible to tell whether file should be moc’ed; and moc generates invalid files when called on file without Q_OBJECT.
You should not treat .ui with moc.exe but with uic.exe. Moc is for headers.
Yes, select first available mod on startup and show info. Essential actions like install / activate mod are somehow hidden and someone could possibly miss that. I tried to right-click on an mod entry in the list, but there was no context menu or sth. like that with further actions.
- How should these files be generated?
- Are they ever compiled at all? I can’t see any reference to files with such names.
More info: to link QT5 you will need this package, apparently 64-bit does not work.
Also, QTDIR enviromental variable should be set to QT root folder.
Also, I’m not convinced if asking all the people to install 500 MB library is a good idea, compared to what we had so far.
Right now moc is needed for more than half of headers. I’d rather avoid splitting source tree that much. Perhaps something else like several moc/ subfolders in current tree? Or some prefix/suffix to all moc-dependent files?
I’m OK with fully separate subtree but maybe there is some less intrusive solution?
Warmonger,
1.
All ui_*.h files are generated by running uic.exe on .ui files
All moc_.cpp files are generated by running moc.exe on appropriate *.h files
They do. These files contain some glue code necessary for Qt slots/signals system. cmake macro is smart enough to run moc only on files that need it so they are not referenced anywhere directly.
And how big is Visual Studio installer? Or boost? Those 500 Mb include documentation, multiple modules that we won’t use (e.g. webkit), most likely QtCreator IDE, huge (size-wise) examples.
Using Qt for GUI was proposed quite a while ago (somewhere in editor discussion). End-users only need several dynamic libraries which are nowhere near 500 Mb.