better standalone/total conversion options

[John.d.h]

Scripts would be much better than executables.  If somebody you don't know posts an executable file on a forum, it's better not to run it.   At least you can see what scripts are.

[Mr War]

I favor the pop up menu before loading MG as that way the intro sequence and menu models etc could be customized for each mod which is a pretty bug deal.

Also wrapped up in this topic is specifying maps and tile sets that are allowed with a mod since not all tile sets look good with all mods and some maps imply certain tile set. Cold war and scifi packs are good examples of that issue

[Omega]

2. Start-up-scripts/executables: Should be shipped with mods; scripts should be very easy (just call megaglest with mod specific parameters), executables same as scripts, but compiled (forces diverences between OS's)

Batch and shell files can already be done.

[MuwuM]

Batch and shell files can already be done.

I know, I just liked to give a complete list.

[titi]

I think not all things are solved by this.
Maps, tilesets and techtrees are maybe completely seperated now, but what about the masterserver? There needs to be a column(visible or not ) for the current ( or installed ) mods and you can only join those games if you use (or have installed) the mod.
And there is a similar problem with the Mod menu. How to handle it?

[treba]

maybe we should do a step in the direction of classical modding games.
for example half-life.
there was a clean borderline between different mods (each had it's own content like maps etc.) and each mod reported it's name to the masterserver when opening a game so you could just filter by it.
the currently used mod was the standard filter of course.

i personally would like megaglest to have a clean mod system like this as it would hopefully lead to more "planned out" mods like annex, and less mixing up of things that don't really fit together.

[titi]

no I don't agree with this. We need both possibilities! Extension of megaglest itself and full conversion like annex.
Full conversions need a a very seperated way, while normal extensions like maps and so on should stay where they are!

[will]

My glest_mod_pack.py script tried to use the following structure to know what goes where:
https://github.com/williame/GlestTools/blob/master/glest_mod_pack.py

The name is made of elements separated by periods.
The name of a mod containing a tech-tree is the first name, e.g. Military
The version of the mod then follows e.g. Military.1.2
If this is an extension and does not contain a tech-tree, then
the name of the extension follows e.g. Military.1.2.CyberStorm
These extensions also need version numbers e.g. Military.1.2.CyberStorm.0.3
Extensions can themselves be extended...

[Omega]

My glest_mod_pack.py script tried to use the following structure to know what goes where:
https://github.com/williame/GlestTools/blob/master/glest_mod_pack.py

The name is made of elements separated by periods.
The name of a mod containing a tech-tree is the first name, e.g. Military
The version of the mod then follows e.g. Military.1.2
If this is an extension and does not contain a tech-tree, then
the name of the extension follows e.g. Military.1.2.CyberStorm
These extensions also need version numbers e.g. Military.1.2.CyberStorm.0.3
Extensions can themselves be extended...

I like. Technically, you could do the same with specifying that information in an XML, but having it in the filename may make it cleaner. Only issue I see is that you'd still have to specify if it's a total conversion mod or just a regular techtree to install. I do like the idea of stating a dependency easily, however.

[tomreyn]

I agree with what Titi said, we need to support both options: extensions to MegaGlest (which the mod menu already provides now) and also full conversions.

For total conversions, what's needed is a solution which is both

• user friendly (GUI access to installation, uninstallation, running full conversions)

• technically clean (should install to standard locations in terms of OS design, must not impact MegaGlest's installation, ...)

I can think of two ways to handle this:

• Separate total conversions management application (a bit like those Spring frontends, but nice ;-) ), allowing for downloading/installing/removing and starting total conversions. This software could be shipped with MegaGlest, and could be started by means of an application menu entry (which is seperate to the one starting MegaGlest).

• Windows+Linux installers/uninstallers, Linux distribution packages, OS X applications which install one total conversion, add a shortcut to the application menu/Desktop as well as all extra data, and come with a way for removal.

Technically the first option is much preferrable, but it requires someone to contribute the total conversions management software (which can be somewhat simplistic since it doesn't need to do very much).

Any total conversion should be installed to a separate directory (possibly below the MegaGlest application directory, since it depends on it, e.g. megaglest/conversions/myconversion/), this directory would act as the data and ini path, which is passed to the MegaGlest executable when it is run. As such, every total conversion should also come with a custom glest.ini (which should, for example, point to a separate masterserver etc.).

Total conversion authors who wish to make users issue a single command to get their conbersion going (i.e. not make users install MegaGlest separately), could do so by making use of package dependencies (i.e package megaglest-conversion-myconversion1 depends on package megaglest but not necessarily megaglest-data on Linux) or installer chainloading (on Windows) to achieve this.

The alternative to this approach would be to make total conversion authors distribute the MegaGlest binaries with their game, and to have fully independant installations. This, however, would make packaging more complex for total conversion authors, and they would take on the responsibility of helping users manage (and update) their software. The support overhead of this option may be relevant, and it means data duplication and possibly bad software manegment (users keeping known insecure versions of MegaGlest installed without being aware, for example), so I would not recommend it.

[Coldfusionstorm]

technically clean (should install to standard locations in terms of OS design, must not impact MegaGlest's installation, ...)

I REALLY Hate that programs install data into my %appdata%
ESPECIALLY!, Because its a user folder. And is hidden by default, and get filled with crap data from uninstalled programs. Even the ones you have no savegame, no modifications to the original game,ect,ect

[will]

I prefer the solution where total conversions are selected from the main menu, so they can be downloaded from inside MG and do not need people to download or run anything.  It can also turn into a way of bringing attention to total conversions and such.

Seeing as how installing MG/GAE/Glest is a major source of people asking for help, hoping people getting it working once is optimistic.  Expecting them to successfully install any number of them is fanciful.

[Omega]

technically clean (should install to standard locations in terms of OS design, must not impact MegaGlest's installation, ...)

I REALLY Hate that programs install data into my %appdata%
ESPECIALLY!, Because its a user folder. And is hidden by default, and get filled with crap data from uninstalled programs. Even the ones you have no savegame, no modifications to the original game,ect,ect

We had a fight about that a while ago, it's pretty much here to stay, sadly (do the devs use windows, though?).

I agree that total conversions should use a different folder, but disagree that it should be below the megaglest folder. Inside the megaglest folder would work much better in my opinion.

Example:

Code: [Select]

[installation directory]/conversions/[mod name]/techs
                                               /maps
                                               /tilesets[small](etc, etc)[/small]

Edit ninja'd: As mentioned (multiple times), I agree with Will on selecting it from the main menu, but having an option of passing it to the executable as it starts is also useful for advanced users. Let's be honest though, not every user is advanced. Some can't even find where MegaGlest is installed.

[Mr War]

I prefer the solution where total conversions are selected from the main menu, so they can be downloaded from inside MG and do not need people to download or run anything.  It can also turn into a way of bringing attention to total conversions and such.

Seeing as how installing MG/GAE/Glest is a major source of people asking for help, hoping people getting it working once is optimistic.  Expecting them to successfully install any number of them is fanciful.

The total conversions need to be selected before launch as they affect menu models and buttons

[softcoder]

I'm not sure everything brought out of this subject is being recalled here. Some critical things to notice that 'users' often do not think about:

#1. All user data (that should remain when upgrading or uninstalling) needs to be placed in a) a folder that is universally accessible and b) outside of the root Game folder so that it can be kept 'safe' from accidental removal and modification by average users.

#2. The windows version of Megaglest Includes a shortcut to the user data folder in the Mega Glest menu which should be sufficient for average users wanting to find this data. (For modders etc. nothing stops you from creating a shortcut to the userdata folder in the root MG folder for quick access)

Remember we are looking for solutions that work in Windows XP --> Windows 7 as well as other platforms (like Linux and Mac). To customize behaviour differently for every platform adds more complexity to the code so this route is often frowned upon.

[Mr War]

Lol. Ubderstood but to voice the view of a user, appdata folder is a pain in the backside. It's a hidden folder in most windows setups etc. I save all my mods in main megaglest folder and backup when redownloading MG versions.

It's a sign of the times. There was a time when I used dos and was pissed off that it disappeared with, I think, windows 95. Now if I use command prompt I cannot remember any syntax and my attention spam is about 10 seconds

[will]

I prefer the solution where total conversions are selected from the main menu

The total conversions need to be selected before launch as they affect menu models and buttons

MG starts in the same "total conversion" as it was last exited with, but you can change to another total conversion at any time from the mod menu, where you can also download and update them.

The moment you have multiple exes floating around and you want users to be run them and so on, you have an update and distribution nightmare.

MG has a very good bit of working code for doing distribution and updates from within MG, and this should be used, even for total conversions; that's my strong conviction.

[Omega]

#1. All user data (that should remain when upgrading or uninstalling) needs to be placed in a) a folder that is universally accessible and b) outside of the root Game folder so that it can be kept 'safe' from accidental removal and modification by average users.

Oops, forgot to take that into aspect, since, like Mr War, I save mods into the installation directory. In which case, the paths suggested could still be used, but relative to the "data folder". Of course, like techs, you could still use the installation directory.

Code: [Select]

[data folder]/conversions/[mod name]/techs
                                    /maps
                                    /tilesets

#2. The windows version of Megaglest Includes a shortcut to the user data folder in the Mega Glest menu which should be sufficient for average users wanting to find this data. (For modders etc. nothing stops you from creating a shortcut to the userdata folder in the root MG folder for quick access)

Remember we are looking for solutions that work in Windows XP --> Windows 7 as well as other platforms (like Linux and Mac). To customize behaviour differently for every platform adds more complexity to the code so this route is often frowned upon.

If we're really going to get into that conversation again, %USERPROFILE% works on Windows 2000, XP, Vista, 7, etc. It directs to the user's personal folder (C:\Documents and Settings\[user name] on Windows 2000 and XP; C:\Users\[user name] on Windows Vista and 7). This is where most games save on windows.

In %USERPROFILE%, I several programs create folders to store their data, including GAE (which has not had a single issue with that folder location, and is just as cross platform as MG), scorched3D, the GIMP (you all use that one), and Jagex preferences. Under %USERPROFILE%/My Documents, I have a Bioware folder for Mass Effect and Dragon Age, a Battlefield folder, Witcher 2, Need for Speed Most Wanted, Visual Studio, Warzone 2100, Sony Vegas Movie Studio, and of course, a "My games" folder which contains subfolders for Dirt2, Halo, Oblivion, Skyrim, and Civilization 4. That many programs can't be wrong.

Oh, and yeah, for the "other side", we have a quite a few folders in app data, sure, but I can't find a use for them. Opening a random one (Ashampoo), I got nothing but a few log files. Oh, and there's a dropbox folder here, wierd, I uninstalled that months ago. It contains a single installation log and a bunch of useless files without extensions. The microsoft folder is pretty full, but it's mostly temporary files that aren't used anymore, empty folders (huh?), and a few "no-touchy" files, such as settings stored in binary (meant to be changed from the application itself). In other words, programs (and games) that are supposed to be modified or expanded keep their stuff in the user folder (well, except skyrim, it wants its mods in the installation directory, but the INIs (loads of settings can only be changed in the INI) are in the personal folder, go figure). App data is for storing stuff you don't touch. Mods and INIs, keep out.

[Mr War]

One approach may be to put the menu models / buttons etc in the tech tree folders, or at least a pointer to use default ones.

Then when you start MG, before the intro etc, the a popup menu asks you to select the tech tree to load, with magitech as default. This affects things like buttons, menu models etc and even which maps/tile sets are available. But you can still select a different tech tree in the regular way afterwards, you'll just have a button mussmatch etc.

[Coldfusionstorm]

Allright, First look at the word "Total Conversion"

This means the game has NOTHING to do with Megaglest.

THE ONLY thing a TC, have in common with Megaglest, is the Megaglest engine.

now based on that two lines, how you you place a TC?

In %appdata%?

Inside /megaglest

or /Programs/TC
just like /Programs/Megaglest.

thats why i said a launcher, a launcher would use the appdata folder(however little i like it)

So that the appdata contains a folder stucture as follows

%appdata%/Megaglest-engine/TC
%appdata%/Megaglest-engine/Megaglest

i still totally hate/and like appdata, but the fact its in the %appdata% folder annoys me to no end, as that folder is encrypted with your password key, so that there is a risk of losing data during a system crash, even if you have the password it will be difficult.

[will]

If you want to distribute your own free-standing program that is based on MG but with other stuff, you can of course do that today.  Its even been done, and called a "total conversion".

Of course building for all the various platforms and targets is non-trivial, as is redistributing every time there are updates etc.  Someone is right now making MacOS builds of MG but the sci-fi TC will never run on a Mac because nobody will do the non-trivial effort to make it so

The thing that you want with a TC is to have custom skin for main menu, perhaps a splash screen, but mostly to divide your tilesets and maps.  In return for this, you have to pay the distribution price.

The way forward I want to see is where a user who has MG installed can easily download mods that don't just augment a techtree, they provide a new one, complete with the tilesets and maps that are specific to that techtree and also the UI theme.

The way I imagine it is that the top level of modding menu is split by techtree, showing those online as well as stored locally.  And the user can drill into those techtrees to also see the mods that extend it.

The UI takes its look&feel from the last-selected techtree (even between restarts).  The maps and tilesets and scenarios etc have moved into the techtree and are specific to it etc.

By selecting another techtree when creating a game or selecting a scenario etc will change the techtree, and retheme the UI immediately.

That's just how I imagine the UI.

The key thing is to first decide if TCs get distributed - outside MG mod menu so its up to the user to download and install, or inside MG?

[Coldfusionstorm]

The problem here is that in MG the engine and the techtree is the same.

My suggestion is to seperate those, so that The engines is Called "MegaEngine"
And the techtree called Megaglest.

Visually, The Main menu would be Cogs, and Gears, And buttons be yellow and under construction like.

Then you can enter mods, and install whatever "mods" or entire games there would be in that section.

This solution provides the best off all imo. and requires little to no changes.

The changes i see by this is
Main menu.
Changes to allow the game to run with no data, play game,Internet games those sort of things would be disabled untill at least one game/mod is installed

Aaand thats pretty much it, and il glady provide the main menu, animated and all.

This is one damn good idea    If i am so shameless to say it myself!