51
MegaGlest / Re: Unable to see units during night.
« on: 10 April 2016, 12:16:44 »
I don't think it works with Mesa, just some of the proprietary drivers.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
52
Mods / Re: Requesting Offline Factions
« on: 5 April 2016, 20:58:46 »
....which is a shame IMO, since if work went into it, and it was meant to be made available to the general community, then those parts which were done would still have been a great contribution, and one others could evolve from (which IMO makes complete sense if you stop working on something).
That's one of the (admittedly many) reasons why open source software developers often make their creations available in public repositories from the very start. (Of course, there is also proprietary software which remains proprietary forever, and proprietary software which becomes open source only much later). If they ever stop developing it (and the licensing terms they chose and declared permit it) others can just fork it and make it become something great in the end (with original copyrights and / or credits retained). To me, that's a great way to make your work last (even if you decide to drive it further on your own).
That's one of the (admittedly many) reasons why open source software developers often make their creations available in public repositories from the very start. (Of course, there is also proprietary software which remains proprietary forever, and proprietary software which becomes open source only much later). If they ever stop developing it (and the licensing terms they chose and declared permit it) others can just fork it and make it become something great in the end (with original copyrights and / or credits retained). To me, that's a great way to make your work last (even if you decide to drive it further on your own).
53
Bug reports / Re: MG64 3.12 on Win 7 64 : functionality of windowskey gone
« on: 6 March 2016, 19:07:05 »
I reproduced this behaviour on MegaGlest 3.12.0 64-bit running on Windows 10 64-bit yesterday. It is non-standard, which is a reason to consider it an issue. Other than that I'm not sure I dislike it.
https://github.com/MegaGlest/megaglest-source/issues/118
https://github.com/MegaGlest/megaglest-source/issues/118
54
Closed bug reports / Re: MG64 3.12 crashes when changing language in optionscreen on Win7 64
« on: 5 March 2016, 13:52:08 »
Thanks, Nig. Titi re-posted it on the Github issue tracker.
55
Bug reports / Re: Cursor disappears in-game MG-3.12, linux-x64
« on: 14 February 2016, 23:48:13 »
Do you mean cursor or mouse pointer?
In case you are referring to the mouse pointer, did you possibly accidentally hit the / (slash) key? This may easily happen unintentionally while using the English keyboard layout.
Hitting this key when the mouse pointer has disappeared should restore it.
In case you are referring to the mouse pointer, did you possibly accidentally hit the / (slash) key? This may easily happen unintentionally while using the English keyboard layout.
Hitting this key when the mouse pointer has disappeared should restore it.
56
Closed bug reports / Re: Megaglest 3.11.1 fails to run on kubuntu 15.04+, debian 8.
« on: 13 February 2016, 08:43:32 »I was just thinking, for newbies, it might be better to recommend the playdeb repo, then they don't need to worry about the dependencies (this does assume newbies use selected debian-based OSes).
We already do so.
https://megaglest.org/linux-packages.html
And since we appreciate the work which mostly C. Korn spends on maintaining (and packaging for) PlayDeb we also host a mirror server for the joint GetDeb/PlayDeb project for a good while now.
57
Closed bug reports / Re: [fixed] Crash as game is won
« on: 27 January 2016, 08:34:47 »
Quoting Andy (from a personal message):
This bug can be moved to 'closed'.
58
MegaGlest / Re: Force maps to be CC-BY-SA ????
« on: 19 January 2016, 20:15:43 »
CC-BY-SA 4.0 International should be a good choice for newly released or re-/multi-licensed assets, i.e. for license declarations.
However, a restriction which makes a statement on positively accepted licenses should not be based on CC-BY-SA 4.0 International (or not only), since this license is not backwards compatible (to CC-BY-SA 3.0 Unported or ported licenses or earlier versions).
The CC-BY-SA license family is forward compatible, though. As such, a restriction stating that acceptable licenses "must be compatible to CC-BY-SA 3.0 Unported or any ported versions, or later versions (ported or not), or licenses declared to be compatible to this and later versions (ported and unported)" should work. This would effectively allow all CC-BY-SA 3.0 and 4.0 licenses as well as GNU GPL 3.0 and Free Art license 1.3.
However, a restriction which makes a statement on positively accepted licenses should not be based on CC-BY-SA 4.0 International (or not only), since this license is not backwards compatible (to CC-BY-SA 3.0 Unported or ported licenses or earlier versions).
The CC-BY-SA license family is forward compatible, though. As such, a restriction stating that acceptable licenses "must be compatible to CC-BY-SA 3.0 Unported or any ported versions, or later versions (ported or not), or licenses declared to be compatible to this and later versions (ported and unported)" should work. This would effectively allow all CC-BY-SA 3.0 and 4.0 licenses as well as GNU GPL 3.0 and Free Art license 1.3.
59
MegaGlest / Re: Force maps to be CC-BY-SA ????
« on: 18 January 2016, 19:08:50 »
I like the ideas of
- extending the map format to allow for a machine readable license declaration
(we will need to provide a GUI utility to allow for making these declarations) - to make the game require a machine readable license declaration
(we will need to facilitate this conversion for modders and players who wish to play existing non mod DB maps) - to (continue to) restrict the mod DB to a given set of liberal licenses
(it should be noted that this set of licenses may change in the future, and we need to provide instructions on how to make compatible maps)
60
Maps, tilesets and scenarios / Re: 4vs4 Map Labyrinth and possible scenario.
« on: 13 January 2016, 20:08:37 »
A backup copy is stored here: http://downloads.megaglest.org/maps/labyrinth.mgm
61
Feature requests / Re: game start count-down timer display
« on: 13 January 2016, 19:27:13 »
While this may seem a good idea at first, I am not sure it will work out. I know of several other games which tried this, and even introduced penalties for players not playing, but they still had this issue of players initially joining the game, then going to walk the dog, just forgetting about the game. In the end you end up with a game with five connected players of which 3 are actually around and willing to play. And those get frustrated by the fact the other two are missing.
Voting to disconnect inactive player can help there to a degree, but I'm not sure it solves this issue.
On the other hand making some attempt to solving this long standing issue (of how to get many players into a game at the same time) is definitely worth spending some energy on. Maybe tweaking this approach a little more will make it really good (but I'm not sure how, yet)?
Voting to disconnect inactive player can help there to a degree, but I'm not sure it solves this issue.
On the other hand making some attempt to solving this long standing issue (of how to get many players into a game at the same time) is definitely worth spending some energy on. Maybe tweaking this approach a little more will make it really good (but I'm not sure how, yet)?
63
Closed bug reports / Re: Megaglest 3.11.1 fails to run on kubuntu 15.04+, debian 8.
« on: 13 January 2016, 19:07:41 »
Thanks for trying and reporting back.
Unless we are going to craft packages for every Linux distribution and release, this is going to remain this way. With the (healthy) variety there is amongst Linux distributions, it is not possible to provide ready-made builds which work for everyone out of the box.
This is also discussed at https://megaglest.org/installation (a page the download page points to).
Unless we are going to craft packages for every Linux distribution and release, this is going to remain this way. With the (healthy) variety there is amongst Linux distributions, it is not possible to provide ready-made builds which work for everyone out of the box.
This is also discussed at https://megaglest.org/installation (a page the download page points to).
64
Feature requests / Re: recalling a marked spot on the map
« on: 13 January 2016, 00:06:08 »
Hmm, I don't think moving the camera to a 'bookmark' location is not supported, yet.
All you can do so far is to place flags on the map with a note attached to each, and to remove them later on.
You can also ping on the map by holding X and clicking. But I think that's it for now.
All you can do so far is to place flags on the map with a note attached to each, and to remove them later on.
You can also ping on the map by holding X and clicking. But I think that's it for now.
65
MegaGlest / Re: cmd arg to change default config directory
« on: 12 January 2016, 23:53:57 »
Hmm right that's not so great. But I guess it can be made to work.
Sorry for suggesting that you could use absolute paths there, I forgot this would not work.
Sorry for suggesting that you could use absolute paths there, I forgot this would not work.
66
Closed bug reports / Re: Megaglest 3.11.1 fails to run on kubuntu 15.04+, debian 8.
« on: 12 January 2016, 23:49:02 »
Do the latest snapshots work out of the box on Debian GNU/Linux 8 x86_64?
68
Tools / Re: Heightmap Exporter/Import (for gbm / mgm)
« on: 9 January 2016, 21:49:53 »
We currently have a wxgtk based editor and model viewer. Build ing this is not much fun since it depends on old libraries which are not available on newer systems. Baxsto wrote an editor in QT, which is already better than the old one, but as far as I know it is not completely done, yet (and could not replace the model viewer). Maybe things would be easier on the web after all. (Or maybe it would just add yet another incomplete option. 
)
)
69
MegaGlest / Re: cmd arg to change default config directory
« on: 8 January 2016, 19:51:44 »
So here's my take on this:
--ini-path should point to a directory where the game will look for configuration files of the system / global scope. This is glest.ini, glestkeys.ini etc.
glest.ini defines where to look for configuration files of the user / local scope, as configured in UserData_Root.
As such, you can do the following to run one installation with multiple configurations:
Instance 1:
Run megaglest with --ini-path=$HOME/megaglest-1-system
In $HOME/megaglest-ini-1 you store a modified copy of glest.ini, with UserData_Root=$HOME/megaglest-1-user
You also store copies of the other .ini files whose file name do not contain "user" in this directory.
In $HOME/megaglest-1-user you store glestuser.ini - configured to match your needs for this instance.
You (optionally) also store copies of the other .ini files whose file name does contain "user" in this directory.
Instance 2:
Run megaglest with --ini-path=$HOME/megaglest-2-system
In $HOME/megaglest-ini-2 you store a modified copy of glest.ini, with UserData_Root=$HOME/megaglest-2-user
You also store copies of the other .ini files whose file name do not contain "user" in this directory.
In $HOME/megaglest-2-user you store glestuser.ini - configured to match your needs for this instance.
You (optionally) also store copies of the other .ini files whose file name does contain "user" in this directory.
...
--ini-path should point to a directory where the game will look for configuration files of the system / global scope. This is glest.ini, glestkeys.ini etc.
glest.ini defines where to look for configuration files of the user / local scope, as configured in UserData_Root.
As such, you can do the following to run one installation with multiple configurations:
Instance 1:
Run megaglest with --ini-path=$HOME/megaglest-1-system
In $HOME/megaglest-ini-1 you store a modified copy of glest.ini, with UserData_Root=$HOME/megaglest-1-user
You also store copies of the other .ini files whose file name do not contain "user" in this directory.
In $HOME/megaglest-1-user you store glestuser.ini - configured to match your needs for this instance.
You (optionally) also store copies of the other .ini files whose file name does contain "user" in this directory.
Instance 2:
Run megaglest with --ini-path=$HOME/megaglest-2-system
In $HOME/megaglest-ini-2 you store a modified copy of glest.ini, with UserData_Root=$HOME/megaglest-2-user
You also store copies of the other .ini files whose file name do not contain "user" in this directory.
In $HOME/megaglest-2-user you store glestuser.ini - configured to match your needs for this instance.
You (optionally) also store copies of the other .ini files whose file name does contain "user" in this directory.
...
70
MegaGlest / Re: cmd arg to change default config directory
« on: 4 January 2016, 19:25:19 »Code: [Select]
$ ./megaglest --help | grep '^--[^ ]*path'
--data-path=x Sets the game data path to x
--ini-path=x Sets the game ini path to x
--log-path=x Sets the game logs path to x
--font-path=x Sets the game fonts path to x
--show-path-crc=x=y
You probably want to change the ini path, maybe log path, too.
71
Bug reports / Re: v.3.9.1, message with download progress = 100% on the beginning of download
« on: 3 January 2016, 02:25:04 »
This is due to the HTTP redirect involved in the downloads from Softcoders' website, how curl handles them and how MegaGlest interprets (lib)curls' output.
When curl encounters a HTTP redirect and follows it, it will report 100% download at the time it follows the redirect, then for the actual download it finishes the download and reports 100% again. What MG does there is that it displays the progress of the first "download" (the HTTP redirection), not the second one.
There are several ways to fix this:
When curl encounters a HTTP redirect and follows it, it will report 100% download at the time it follows the redirect, then for the actual download it finishes the download and reports 100% again. What MG does there is that it displays the progress of the first "download" (the HTTP redirection), not the second one.
There are several ways to fix this:
- Make MegaGlest notice that a HTTP redirection is taking place, effectively ignoring download progress for this "download", but reporting that of the next one (unless it is another redirection).
- Make MegaGlest's curl not follow redirections, and change the URLs in the mod database to point to the direct download locations (which would break Softcoders' download statistics script for these resources).
72
Closed bug reports / Re: "Load Game" and "Game Mods" buttons overlap on Main Menu
« on: 3 January 2016, 02:04:18 »
Glad it works for you now!
Just in case this was not clear from my previous post: removing all of these MainMenu_... entries off the file would give you the default buttons - the same buttons you have now (just with different positioning - all in one 'column'), plus you would not miss out in case the main menu will change in the future.
Just in case this was not clear from my previous post: removing all of these MainMenu_... entries off the file would give you the default buttons - the same buttons you have now (just with different positioning - all in one 'column'), plus you would not miss out in case the main menu will change in the future.
73
Closed bug reports / Re: "Load Game" and "Game Mods" buttons overlap on Main Menu
« on: 2 January 2016, 23:00:26 »
He did - now this is strange indeed. Did you maybe edit glestuser.ini manually, or copy it from a different installation?
Another explanation might be that you accidentally hit the hotkey which dumps all configuration into glestuser.ini (I forgot which on that is actually) while running an older version of the game, and that we have since changed the positioning of these menu buttons.
Either way, you should be able to fix it by either removing, in ~/.megaglest/glestuser.ini, all the lines where the word left of the equals character contains "menu". Alternatively, you can just delete ~/.megaglest/glestuser.ini, but this way you will also loose any configurations you may have made (usually those are easily reconfigured, though).
Another explanation might be that you accidentally hit the hotkey which dumps all configuration into glestuser.ini (I forgot which on that is actually) while running an older version of the game, and that we have since changed the positioning of these menu buttons.
Either way, you should be able to fix it by either removing, in ~/.megaglest/glestuser.ini, all the lines where the word left of the equals character contains "menu". Alternatively, you can just delete ~/.megaglest/glestuser.ini, but this way you will also loose any configurations you may have made (usually those are easily reconfigured, though).
74
Closed bug reports / Re: MegaGlest crashes in Ubuntu 15.10
« on: 2 January 2016, 22:46:36 »
This may have the same root cause as the one discussed at https://forum.megaglest.org/index.php?topic=9701.0 (for which a workaround exists).
I'm not able to reproduce this (not too thoroughly described) issue on 3.11.1 or the latest snapshots on Windows 10 or 8.1, so I assume this can be due to the incompatible (insufficient) graphics hardware Victor uses. I'll therefore close this report.
I'm not able to reproduce this (not too thoroughly described) issue on 3.11.1 or the latest snapshots on Windows 10 or 8.1, so I assume this can be due to the incompatible (insufficient) graphics hardware Victor uses. I'll therefore close this report.
75
Tools / Re: Heightmap Exporter/Import (for gbm / mgm)
« on: 2 January 2016, 22:43:26 »
Very nice indeed. 
This is not just a serverless heightmap editor, it also serves to 'document' the map format more (we could totally use proper descriptions of our file formats and network protocols on the wiki).
And it could lay the foundation to a HTML/Javascript map editor. If anyone is willing to implement this I'll sure be happy to add an upload backend.
This is not just a serverless heightmap editor, it also serves to 'document' the map format more (we could totally use proper descriptions of our file formats and network protocols on the wiki).
And it could lay the foundation to a HTML/Javascript map editor. If anyone is willing to implement this I'll sure be happy to add an upload backend.