Topics

26

Feature requests / [done] Allow mod / scenario images to have diff images for diff aspect ratios

« on: 9 February 2013, 06:02:13 »

Mods and recently scenarios have loading images (or background images in the case of scenarios) which are resolution independent: the same image is used for all aspect ratios, and is simply stretched or compressed as needed. I'd like to propose an optional alternative for modders to use (which is especially useful if their backgrounds contain elements that don't stretch or compress well, such as text).

In factions (for example), the loading image is simply an image named loading_screen.* in the root faction folder. I propose that if there are any files in the format loading_screen_#.* (where "#" is any number), they will instead be used. What does the number mean? It's the ratio of the width to the height (when height is equal to 1). So for example, the standard 16:9 ratio can be written as 1.78:1, so we'd name the file loading_screen_1.78.*. The file used as the loading image would be whatever number the used aspect ratio is closest to.

So for example, suppose I made loading screen images in the two most common formats, 16:9 and 4:3. The file names would then be loading_screen_1.78.jpg and loading_screen_1.33.jpg. If the player is using a resolution that has an aspect ratio of 8:5, the ratio of width to height is 1.6. This is closer to the 1.78 (from the 16:9 image), so loading_screen_1.78.jpg is used.

So why bother with this instead of just letting the game automatically compress or stretch images? Because the difference between a 4:3 aspect ratio and a 16:9 ratio is quite large. While a simple image of buildings might have some noticeable distortion, that's usually fine. But for things like text, fine shapes, things that should have obvious proportions (such as circles), etc, the distortion isn't so good. For the modder, this could be as simple as cropping the image and resaving it (20 seconds of work), although more complex images may need elements to be moved to properly fit the different aspect ratio. For the most part, an image for each of the two most common resolutions: 16:9 and 4:3 would be all modders would have to do (since other aspect ratios are generally rather close to one of these, and would just use whatever is closest).

27

Feature requests / Increase and/or allow modification of the shadow casting radius

« on: 29 January 2013, 20:16:26 »

It appears that shadows are only casted by objects close to the camera. I'm not sure if it's a box or radius or what, but it'd be nice if we had a way to expand this area which determines whether or not an object casts a shadow. As it stands, I shadows tend to flicker on and off and moving the camera a miniscule amount to the side could make a shadow appear or disappear in a very noticeable way. Obviously shadows are graphically intensive, so some people wouldn't benefit from an enhanced shadow casting radius, but I could argue that if such is the case, you should disable shadows anyway.

As it stands, shadows seem incredibly awkward because of that appearing and disappearing. Most modern machines should have no difficulty with, say, twice as much shadows, anyway.

28

Bug reports / rev 4065: Shadows and lighting issues on some resolutions; Win7 - 64 bit

« on: 29 January 2013, 20:08:47 »

This occurred in both version 3.7.1 and rev 4065 (currently Windows nightly build). The computer is running Windows 7 64-bit (service pack 1; all up to date). Graphics card is a GTX 560-Ti, latest drivers (310.70). This seems to be resolution dependent. One resolution I was able to reproduce this on was 1440 x 900 (which is neither 4:3 nor 16:9). Noteworthy that I chose this resolution in the settings menu; no INI changes were made. At the same time, though, I could not reproduce this in 1680 x 1050, which is also a non-standard resolution. The issue is also evident on a 1280 x 800 resolution (same aspect ratio; 8:5).

There seems to be two noticeable issues here. First of all, a "cut off area" that isn't lit creeps in at certain times of the day (such as around 9:00), as seen in the first image. It later creeps out at other times of the day (such as around 14:00). It can be more of less noticeable at different camera angles (images taken from default angle).




The other issue is more serious. When night falls, half of the screen is covered in a weird "veil" that is unlit. This is best illustrated with an image:



These screens from another game (different resolution, same issues) further highlight the strange effects (it's a really strange state, it's like the models textures are blanked out):



The above effect starts at nightfall, but leaves when the day begins again.

And another screenshot showing the severity of the first issue (visible at some parts of the day) at its peak:


Obviously a dirty solution would be to not use these resolutions (remove them from the options menu), but then anyone with a screen with a 1440 x 900 resolution (I've seen some laptops using this resolution) can't use an optimal resolution. There may be other resolutions affected, I didn't have time to check them all.

EDIT: Also, if it matters, all screenshots were done from the anarchy scenario, so the tileset is Winter Forest, the techtree is the MegaPack, and the map is Four Rivers. There are no logs available, as the game does not recognize any form of error.

29

Feature requests / [Dupe] Game should end when all buildings initiate their death animation

« on: 26 January 2013, 06:33:22 »

Currently, the game doesn't end until the death animation of the last building ends. So in other words, we have to wait for the ruins of the building to disappear. I think that the game should end the moment that building "dies" (when the death animation starts).

30

MegaGlest / MegaGlest aesthetics discussion

« on: 26 January 2013, 06:05:52 »

On a similar concept to the Graphics Improvements discussion, I think various aspects of the engine could be improved for aesthetic reasons.

[big]Drop down menus[/big]

I rather like the style of the buttons, but dislike using two arrows for lists. This has a few problems. First of all, the list items often overlap with the buttons, as is the case with the "capture the flag" scenario name (this one's an aesthetic issue). Secondly is the fact that we can't easily select items from large lists (this one's a functionality issue). For example, there are over a hundred maps by now (I've been keeping track), and selecting that map you want is very difficult if it's not early or late in the alphabetical list (note to map-makers: name all your maps "AAAA_[map name]" to ensure you get the top spot). A drop down menu would be better looking and much more functional.

[big]Mod center icons[/big]

I also really dislike the graphics in the mods center. I mean, how does a smirking face represent "available"? Even the check mark seems rigid. Would there be any opposition to me proposing new graphics there?

[big]Mod center frames and descriptions[/big]

I even dislikes the frames in the mods center. They remind me of web pages made in the ninety's. The graphics are warping due to the stretching and I'm not even sure what texture the vertical bar is using (although it certainly looks odd). At any rate, text overflows from the left side of the frames, instead of wrapping. The frames ultimately strike me as unnecessary. Rather, I'd prefer to see a background to the area with the description and picture. The text is difficult to read without a background, anyway. The description also seem to be poorly written. With all due respect, it doesn't sound very professional when the description for a map says, "Very nice 4 player map for 2v2 games!!". Heck, I'd even write descriptions for all the items in the download center if you need them, but that's something better done by the mod creators, as they understand their mod's story and layout best.

[big]Scrollbars[/big]

And then we have the scrollbars. Ugly and very out of place. I'd personally prefer to see them done very differently. Instead of one graphic for the entire bar and its handle, I'd give a small graphic (5 pixels?) for the top of the bar/handle and another for its bottom. Another graphic would be the middle, which would be simple (even 1 pixel?) and stretched. I've used this approach in web development, and it works well, since it allows the top and bottom to be of a definitive shape (as stretching would warp them) while still allowing the area to be resized. I can even supply graphics if anyone wants to take this approach.

[big]Saved games screen[/big]

Anyway, these progress bars and frames also apply to the saved games menu. In fact, do we need to be displaying a progress bar background if there's no need to be scrolling? And we could also hide the load and delete buttons when no saved game is detected.

[big]Faction image on custom game screen[/big]

I'm of the opinion that the faction image in the custom game screen is rather detrimental. It strikes me as useless (in its current form, at least) and looks out of place. If anything, it further cramps the crowded menu. But this one may be of a more personal opinion, since the picture was (presumably) added for aesthetic purposes in the first place. But that's an opinion coming from a minimalist anyway (I'd have tossed the custom game settings into a tabbed interface).

[big]Text in general[/big]

Anyway, text. Maybe it's just me, but the fonts are stretched, as proven by the image to the right. According to the INI, the font is Arial, and the example is supposed to be size 14 and size 12 respectively. Presumably they're also bolded. However, trying this in an image editor gets the results below the example. Notice how the text for "control" is obviously much longer in-game than it should be. However, I'm rather confused at what I'm seeing here. The "C" appears to be the right height, but the rest of the letters are not the same height. And for the word "human", the letters are obviously smaller than the 12 point font the INI suggests. I'm not sure if the INI settings are being used or not, but at any rate, the text is not as crisp in the top image as in the bottom image.

But even then, I wonder if the text would be better with a more contrasting background. Perhaps a dark grey outline or a feathered grey "shadow"? At any rate, I think the text issue is even worse in the internet game menu. The servers are purple text, which is ridiculously difficult to read on the grey background. Not to mention we can't assume the background is always grey (although total-conversion mods are pretty much forced to use a dark background, as anything light coloured makes any white text unreadable). And in the mod center, the text for the mod list is faded (it appears to be partially transparent), making it a bit more difficult to read against the low contrast background.

[small]Edit: Added "titles" to improve readability.[/small]

31

Off topic / If you had the choice to take down the cause of your demise, would you do it?

« on: 22 January 2013, 01:22:51 »

Just an off-topic discussion. In particular, I'm referring to the UK's letters of last resort (Wikipedia link if you're unfamiliar with them). Basically, you're in charge of a country (etc) and have the option of (at least attempting) to get revenge on whomever may destroy your country. If you were killed and your country destroyed, would you prefer to (attempt to) bring down those who caused your demise? No one would know of your choice unless it was ever executed. It's like pulling the trigger on your own killers.

If it was your choice, would you do it?

EDIT: A similar example of this capability was the Soviet era "Dead Hand". However, it differs in that it's not kept secret, as is the choice given in the UK's letters of last resort. The intent of the Dead Hand was as a nuclear deterrence and for revenge.

32

Feature requests / Allow upgrades & attack boosts to apply effects to different sets of units

« on: 2 January 2013, 02:36:56 »

As it stands, upgrades and attack boosts can only apply the same modifications to a set of units. So we could raise the HP of a swordman and a guard by 100 if we wanted. However, we can't, for example, raise the HP of the swordman by 100 and the armour of a guard by 10 in the same upgrade or attack boost.

Thus, I propose an alternative element, <enhancements>, which has children elements <enhancement>. Each of these children elements has the same <affects> and stats elements as the regular upgrade syntax. This is probably best explained with an example.

This here is the current syntax:

Code: [Select]

<upgrade>
<image path="images/image.bmp"/>
<image-cancel path="images/cancel.bmp"/>
<time value="300"/>
<unit-requirements />
<upgrade-requirements />
<resource-requirements />
<effects>
<unit name="unit_name" />
</effects>
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="0" />
<production-speed value="0" />
</upgrade>
My alternative would look more like this:

Code: [Select]

<upgrade>
<image path="images/image.bmp"/>
<image-cancel path="images/cancel.bmp"/>
<time value="300"/>
<unit-requirements />
<upgrade-requirements />
<resource-requirements />
<enhancements>
<enhancement>
<effects>
<unit name="unit_name" />
</effects>
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="0" />
<production-speed value="0" />
</enhancement>
<enhancement>
<effects>
<unit name="unit_name" />
</effects>
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="0" />
<production-speed value="0" />
</enhancement>
</enhancements>
</upgrade>
Attack boosts are similar. Here's the current code:

Code: [Select]

<attack-boost>
<allow-multiple-boosts value="false" />
<radius value="5" />
<target value="ally" />
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="0" />
<production-speed value="0" />
<particles value="false" />
</attack-boost>
With the enhancements element used:

Code: [Select]

<attack-boost>
<enhancements>
<enhancement>
<allow-multiple-boosts value="false" />
<radius value="5" />
<target value="ally" />
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="0" />
<production-speed value="0" />
<particles value="false" />
</enhancement>
<enhancement>
<allow-multiple-boosts value="false" />
<radius value="5" />
<target value="ally" />
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="0" />
<production-speed value="0" />
<particles value="false" />
</enhancement>
</enhancements>
</attack-boost>
A possibly easier way to do attack boosts would be to simply allow multiples of the attack boost element rather than using the enhancements element. Either way, the end result is the same: multiple attack boosts on a single skill.

33

Feature requests / [done] Make attack-boost parameters optional

« on: 20 December 2012, 13:52:43 »

According to current documentation, attack boosts cannot change the unit's HP regeneration or EP regeneration, meaning that it's impossible to make a healing attack boost (one of the most useful possibilities). Can such be implemented?

As well, I noticed that, at least in 3.7.1, attack boosts must have all the tags, even if they aren't using them. MegaGlest returns an error otherwise. Can the stat tags be made optional, defaulting to zero?

So in other words, this:

Code: [Select]

<attack-boost>
<allow-multiple-boosts value="false" />
<radius value="10" />
<target value="ally" />
<move-speed value="120" value-percent-multipler="true" />
<particles value="false" />
</attack-boost>
Should be the same as:

Code: [Select]

<attack-boost>
<allow-multiple-boosts value="false" />
<radius value="10" />
<target value="ally" include-self="false" />
<max-hp value="0" />
<max-ep value="0" />
<sight value="0" />
<attack-strenght value="0" />
<attack-range value="0" />
<armor value="0" />
<move-speed value="120" value-percent-multipler="true" />
<production-speed value="0" />
<particles value="false" />
</attack-boost>
The reason is legibility. It's much easier to glance at the XML code for the first example and know what it does than for the second example. We could even further that by setting allow-multiple-boosts and particles as optional (defaulting to false).

34

Closed feature requests / [Done] Allow mods to specify a starting HP and EP value

« on: 6 December 2012, 06:24:21 »

Proposed feature	Allow a unit's starting (when produced/built) HP and/or EP to be defined by the unit XML.
Purpose	The ability to set the starting EP is by the far the more useful. Currently, all units start with zero EP. This has some balance issues. For example, if you produce a fresh summoner, they won't have enough EP to perform a single attack for a little while. Long enough that producing a summoner in the heat of a battle will result in their death before they can use a single attack, even if the foe is a single archer. Tech doesn't have this issue as it doesn't use EP. Starting a unit with full (or perhaps half) EP would balance that out a bit without being overpowered. Another example is Magic's golem. It requires EP to move, so on production, it takes ten second to move a single step, or over a minute before it can take the maximum 10 steps (closer to 11 with regeneration) in a row. Starting with EP would make using the golem more convenient without overpowering it in any way. Specifying a starting HP would be a bit different, but could have its uses. Since HP and EP go hand in hand, if we're going to implement a starting EP, may as well do the same for HP. A good use would be for strategical purposes: you could make a building that is built at 4000 HP, but can be fortified (via a slow repair skill) to a higher HP. Or a unit that starts with a set amount of HP, but can be boosted considerably higher by attack boosts (so in other words, is stronger in a group). If MegaGlest gains support for emanations (basically an always on attack boost), they'd be more useful, as you could have a building for the sole purpose of buffing up a unit before battle (but you can do that with a repair skill as well).
Implementation	Such a feature would be toggled by modder on the max-hp and max-ep tags as an attribute (perhaps called "starting-hp" and "starting-ep" respectively). The input value is an absolute value of the HP or EP, not a percentage. Negative values are not allowed for starting HP or EP. However, provided it's reasonably possible, values greater than the maximum HP/EP should be allowed (as they open up the possibility of a unit only being "healable" to a certain amount or attacks that require so much EP that they can only be used once). However, since upgrades can change a unit's max HP/EP, having just an absolute value for the starting HP/EP would prevent us from always being able to give the unit full HP/EP. Thus, for values between 0 and 1 (a decimal), the starting HP/EP would be treated as a percentage. So a starting HP value of 0.5 would start with 50% of their max HP, while a starting HP value of 500 would start with 500 HP. The reason we support both absolute values and percentages is that it allows us to give a specific amount of HP/EP or full HP/EP when there is upgrades in place. Assigning a specific amount of EP, for example, could be used to ensure that the unit is capable of attacking once with a special attack that they don't normally have enough EP for. When a unit is built (with a build skill), it should be built up to this starting HP. To prevent the possibility of the building burning because it's within the "burnable" threshold, perhaps an optional value on the burnable property should be implemented as well, which would allow it to specify when the building starts burning, as an absolute value. Because burnable is specified with a property element instead of an optional element if its own, it may be cleaner to create a new element for burnable, with a value (boolean toggle for whether or not the unit can catch ablaze) and an option starting value (for at what amount of HP will burning begin). Having its own element would be more versatile as the properties element only has a single attribute, but is also used for things other than "burnable". Can be done either way, though.
Additional notes	If this feature is implemented, I proposal that all units in the MegaPack techtree are given starting EP values equal to their max EP (as a percentage).

35

General discussion / [Pretty sure, YES] Please read: Is the Glest Advanced Engine project dead?

« on: 8 November 2012, 06:28:15 »

It's no secret that this board has been quiet for a long time. The last official GAE release was December 2010, almost TWO YEARS ago. Even the beta for version 0.4 was last released in October 2011, over a year ago. Since then, there's been hardly any progress with the engine. Besides MoLAos's fork, which is developed on a different path than GAE, there isn't any active development on the fork. There have been no new mods recently, with constellus having been long since abandoned and my own apocalyptic dawn as well. There hasn't been a single commit since September, but even beyond that, commits are few and far between. In other words, the possibility of version 0.4 being released is looking very slim. With the exception of Hailstone, most of the devs no longer frequent the board often, having last visited the board over a month ago. Long story short, the project is looking pretty much dead.

If that is the case, I think we'd be best off to archive the GAE threads and convert the board to full on MegaGlest. There's just no point having another fork lying around if it's never going to be developed.

This topic is meant to ask the community if they agree that the GAE project should be closed down and the rest of the board adapted for MegaGlest use. If this is the case, then the Wiki can also be adapted to be solely for MegaGlest, which would make the development easier and less confusing for future MegaGlest modders. If this proposal passes, I'll personally modify the board and wiki myself. Beyond that of the community, I also would like to hear the GAE devs take on this. I understand that real life comes first, and it can be hard to find time to develop a freeware project. As well, since it's more or less "your" project, it's really the final say of the devs. With that being said, GAE's really looking in limbo, and the MegaGlest project could always use more coders.

So again, if the community is in agreement, we'll:

• Lock and archive the GAE category
• Adapt the board to be better for MegaGlest: move the childboards to be proper categories of their own (MegaGlest logo at the top corner?); set MG devs to universal moderators
• Archive the GAE portions of the wiki, making MegaGlest the dominant topic

Edit 2013-08-06 - Omega: Changed title
Edit 2016-12-31 - filux: Changed title, to all: please don't dare to say project is not dead until the time when source code (with history) will be available to download (again) ... and with at least one fresh commit

36

Off topic / A question to non-native English speakers

« on: 20 September 2012, 22:26:52 »

I'm just curious, those of you whom English is a second (or third, fourth, whatever) language, how prevalent is grammar mistakes in your native language, how is your language structured, and if it's common to see grammar mistakes in your language amongst native speakers. With English being one of the most common languages in the world, approximately 1.8 billion people can speak English to at least a reasonable degree, however, less than half of those are native English speakers (ie, as their first language).

As a native English speaker, I can't help but notice that many other native English speakers can't even grasp some of the most basic aspects of the language, case and punctuation. It's strangely common to see incorrect spacing around commas (it's always comma-space, the space is not optional). Likewise, sentences starting with lowercase characters, the absence of commas when they're necessary (let's eat, grandpa; let's eat grandpa), and commonly mixed up words (there, their, they're).

Obviously nobodies expecting non-native English speakers to have flawless English, although it makes me flinch at how often even native speakers who graduated from high school with mandatory English classes can make such simple mistakes. What common language-related flaws are prevalent in your native language (who knows, perhaps it'll keep us non-native speakers from making them)?

37

MegaGlest / Does MegaGlest support shaders? [A: No]

« on: 18 September 2012, 20:37:57 »

As per this quote:

Also does MG support shaders? my copy has a folder of shader files in core/data/shaders.

I don't seem to recall any mention of shaders recently. My very old version 3.6.0.3 has the same folder, and I was curious. If MegaGlest does support shaders, does it support (or plan to support) normal maps, specular maps, luminosity maps, etc?

38

Closed bug reports / [fixed] G3D Viewer issues

« on: 17 April 2012, 05:37:52 »

I didn't put this on the bug reports subforum as I'm uncertain if it's a bug or something wrong with the compiled windows version of the G3D viewer, my setup, etc. If it is a bug, feel free to move it to the bug reports subforum.

I've been having difficulty getting the G3D viewer to display a particle effect XML. While I can display any model fine, the unit particle systems have been giving me strange issues, and I've been unable to figure out a reason why. I'm using the G3D viewer that came bundled with the windows installer for 3.6.0.3, which is G3D Viewer 1.3.6. I can load the unit particle effects from the MegaPack fine (the specific file I tested was the bigtent's smoke_particles.xml), but for whatever reason, copying the file (and the particle bitmap, inside the same folder; fixing the relative link in the XML) to a working directory suddenly made it stop working. Even closing and reopening the program has no effect. When I copied this modified file back to its original directory (along with the particle bitmap file), the G3D viewer properly displayed it. Copying back into the original directory still had no effect.

The directory path has no foreign characters, and there are no spaces (though there are even spaces in the MegaPack path). The files were identical, and I've triple (quadruple, whatever) checked the relative link, and tried a number of alternative folder structures, including placing the bitmap image in a folder titled "images", adding "../" and "./" in front of the path to the particle image, yet, still nothing. The G3D viewer returns no errors, and the command line, even with verbose turned on, doesn't change at all when opening the file, although the window title changes to the name of the XML file.

The bitmap file is an exact copy of the one from the Indian's bigtent unit, and I even tried resaving it at different bit rates and tried converting it to PNG. The particle XML was a modified copy of bigtent's smoke, with just the filepath for the particle image modified, and even an unmodified version (with the particle image being moved into an "images" folder) had no avail. Even a more heavily modified version (cleaning up the bad XML formatting, removing an unnecessary comment, etc) didn't work in either location, even though the content of the XML wasn't modified, and the XML was valid (none of my attempts threw any error messages, nor anything in the command line).

I don't know if it's of any use, but here's the contents of --verbose (noting that all the output is written when the program is launched, not when loading the file):

Code: [Select]

C:\Program Files (x86)\MegaGlest>megaglest_g3dviewer --verbose
In [..\..\source\shared_lib\sources\util\util.cpp::Shared::Util::SystemFlags::ge
tSystemSettingType Line: 213]
In [..\..\source\shared_lib\sources\util\util.cpp::Shared::Util::SystemFlags::in
it Line: 233]
In [..\..\source\shared_lib\sources\util\util.cpp::Shared::Util::SystemFlags::in
it Line: 255]
In [..\..\source\shared_lib\sources\platform\common\simple_threads.cpp::Shared::
PlatformCommon::LogFileThread::execute Line: 466]
In [..\..\source\shared_lib\sources\util\util.cpp::Shared::Util::SystemFlags::in
it Line: 264]
In [..\..\source\shared_lib\sources\platform\common\simple_threads.cpp::Shared::
PlatformCommon::LogFileThread::execute Line: 474]
-=-=-=-=-=-=-= looking for file in possible location  [C:\Program Files (x86)\Me
gaGlest\]
-=-=-=-=-=-=-= looking for windows specific file in possible location  [C:\Progr
am Files (x86)\MegaGlest\windows_glest.ini]
-=-=-=-=-=-=-= About to load fileName.first = [C:\Program Files (x86)\MegaGlest\
glest.ini]
Property key [DataPath] now has value [C:\Program Files (x86)\MegaGlest\\]
Property key [LogPath] now has value [C:\Users\Mike\AppData\Roaming\megaglest\]
Property key [UserData_Root] now has value [C:\Users\Mike\AppData\Roaming\megagl
est\]
-=-=-=-=-=-=-= About to load fileName.second = [C:\Users\Mike\AppData\Roaming\me
gaglest\glestuser.ini]
OpenGL Extension [GL_EXT_framebuffer_object] supported status = 1
In [main.cpp::Shared::G3dViewer::MainWindow::loadProjectileParticle Line: 1331]
about to load [] particleProjectilePathList.size() = 0
In [main.cpp::Shared::G3dViewer::MainWindow::loadProjectileParticle Line: 1445]
after load []
In [main.cpp::Shared::G3dViewer::MainWindow::loadSplashParticle Line: 1449] abou
t to load [] particleSplashPathList.size() = 0
In [main.cpp::Shared::G3dViewer::MainWindow::loadSplashParticle Line: 1552] afte
r load [] particleSplashPathList.size() = 0
OpenGL Extension [GL_EXT_texture_filter_anisotropic] supported status = 1

The particle XML I was using is this:

Code: [Select]

<?xml version="1.0" standalone="yes"?>
<unit-particle-system>
       <texture value="true" path="images/particle.bmp" luminance="true"/>
   <mode value="black"/>
   <primitive value="quad"/>
   <offset x="0" y="-1.2" z="0"/>
   <direction x="0.3" y="1" z="0"/>
   <color red="0.1" green="0.1" blue="0.1" alpha="0.33" />
   <color-no-energy red="0.0" green="0.0" blue="0.0" alpha="0.0" />
       <radius value="0.9" />
       <size value="1" />
       <size-no-energy value="0.7" />
       <speed value="2.0" />
   <gravity value="0.001"/>
       <emission-rate value="3" />
       <energy-max value="200" />
       <energy-var value="0" />
   <relative value="true" />
   <relativeDirection value="false" />
       <fixed value="false" />
       <teamcolorNoEnergy value="false" />
       <teamcolorEnergy value="false" />

   <!--trajectory type="spiral">
      <speed value="14.0"/>
      <scale value="1"/>
      <frequency value="0.5"/>
   </trajectory-->
</unit-particle-system>
Even if I change the particle effect from a quad with an image to a line particle effect, nothing is displayed, but moving this exact file to C:\Program Files (x86)\MegaGlest\techs\megapack\factions\indian\units\bigtent, the particle works fine.

Code: [Select]

<?xml version="1.0" standalone="yes"?>
<unit-particle-system>
    <texture value="false" />
    <primitive value="line" />
    <offset x="0" y="-1.2" z="0" />
    <direction x="0.3" y="1" z="0" />
    <color red="0.1" green="0.1" blue="0.1" alpha="0.33" />
    <color-no-energy red="0.0" green="0.0" blue="0.0" alpha="0.0" />
    <radius value="0.9" />
    <size value="1" />
    <size-no-energy value="0.7" />
    <speed value="2.0" />
    <gravity value="0.001" />
    <emission-rate value="3" />
    <energy-max value="200" />
    <energy-var value="0" />
    <relative value="true" />
    <relativeDirection value="false" />
    <fixed value="false" />
    <teamcolorNoEnergy value="false" />
    <teamcolorEnergy value="false" />
</unit-particle-system>

Too long; didn't read: For whatever reason, having the particle XML in my documents folder is stopping the G3D viewer from displaying any unit particle effect, without any error messages, even if the particle effect is an exact copy from a MegaPack unit, which the G3D viewer does display properly.

I'd really like to see whatever the underlying issue is here fixed, as this is preventing me from doing some necessary work with particles (it would be far, far too difficult to reload the game every time to position particles on a unit). I don't see any reason why my system configuration would make a difference in this case, but for the record, it's a 64-bit Windows 7 operating system with service pack 1, with a Core 2 duo CPU T6600 running at 2.2GHz, an ATI Mobility Radeon HD 4650 graphics card running a 1600x900 resolution, 4 GB of DDR3 RAM, and a 500 GB 7200 RPM 3Gb/s HDD with 266 GB free, the computer is fully up-to-date, and it's the latest stable released version of MegaGlest.

Also should be noted that I have loaded particle effects into the G3D viewer in the past, without this problem (though that was quite a while ago, admittedly, there may have been several changes since then).

39

Feature requests / [done] XML option to hide a resource from the HUD

« on: 31 March 2012, 21:36:49 »

Resources, with an icon and current amount, are always displayed at the top of the screen. This is, of course, very useful for most resources, but if we were to use, say a "hero" resource, to ensure the player can only have one of a specific kind of unit (out of multiple choices; for example, you have three choices for hero units, but can only have one at a time, so we'd want to use a static resource that is recuperated upon the death of that unit).

Using a resource is the easiest way to do that, however, we don't really need it to be shown in the top HUD. The best approach would be to simply hide that resource in the HUD, toggled via an option XML tag, <display value="true|false"/>. If true, the resource is displayed as normal, if false, the resource is hidden from the top HUD. If the tag is omitted, the default is true.

The tag in question already exists in GAE as the above code, and is further documented here.

40

Feature requests / Revamped new game screen

« on: 27 January 2012, 20:24:24 »

This is an ambitious feature request, but one I believe we'll have to do (or some variant) at some point in the future, as we simply don't have enough room in the single-pane new game menu for a future 12 players, more options, etc. It's pretty limited as it is now. But a picture's worth a thousand words, so I put some thought into this proposal and came up with the following concept:


Firstly, we start by having the user pick the techtree. By having this an entirely separate screen, we don't pressure the user with too many options at once, and give space for us to add a short description, which will be found on each pane. We display a list of the factions inside the techtree to aid in choosing, not to mention those ambiguous cases ("ugh, what techtree did I put the dwarves in?).

There's also the ability to add a description to the techtree. This is done using the already existant, but unused, name element in the faction XML. Presumably, however, it will reference a language file key, so that we can have the description translated (for legacy reasons, if not found in the language file, fall back to the english language file. If not there either, display the value as is).

Finally, having a separate techtree also takes into aspect the potential future possibility of restrictions based on the techtree (eg, if annex had a GAE version, it might want to restrict itself to the specialty tilesets and maps that are bundled with it). Of course, such a feature doesn't exist anyway, and shouldn't be worried about.


Next, we have the player choose the map. The reason this is done before choosing the factions and players is because the map determines the number of players allowed. This ability to have a map preview is one of the biggest reasons for this proposal: there's a lot of maps. I got about 80 maps myself, all distributed with Apocalyptic Dawn. I can't claim to understand the technicals behind how a map preview would work. If a live snapshot (as in, render a single frame image of the whole map, then display it as a static image) can be rendered in a practical amount of time (under three seconds), that would be utterly godly (the tileset could be taken into aspect). If not, check for an image (TGA, BMP, PNG, or JPG) in the maps folder with the same name as the map. If none is found, display "no preview", like this alternative version here. I have images for nearly ever map, and could supply them easily. If live rendering is possible, it may be desirable to cache the images, preventing that wait time from having to be repeated.

The other awesome thing about the extra space we have is that we can display the title, author, and description, which are already stored in the map file (those values shown there are the actual values in the Wadi Nefud). If title is empty, display the name of the map.


And the final screen, naturally, lets use choose the players, their faction, their team, and their colour. This is basically the same as the player selection, but as shown in the image, can hold up to 12 players (these are 800x600 images, which should be the minimum resolution to run GAE).

And that's not necessarily everything. While I don't propose we add anything else yet, these panes could be expanded to also have another button on the last screen for an "advanced options" pane, which could give options for more advanced per-game settings, such as the end game action, observers, etc.

It'd also be rather useful to use our tooltips feature on this menu. So hovering over the faction drop down box could offer a short description of what a faction is. Hovering over the size attribute on a map could explain what the size means (as well as mention what size is a medium sized map, small, etc). That function is optional, and could also be applied to our current menu. The "x" at the top right corner of the window is supposed to "close" the new game menu, taking you back to the main menu, but without a tooltip, the only way to know that is to click it.

[small]Note: again, these are just images, I don't have the skill (yet) for anything like this. Just some mean image editing skills.[/small]

41

Feature requests / [DONE] Particle emission rate should be float

« on: 22 January 2012, 03:58:14 »

Blast, I could have sworn I brought this up before, but I'm either mistaken or lost the thread. As we know, GAE's particle emissions are an integer, meaning it must be a whole number. Particle emission is the number of particles let off each cycle. So a value of 20 would release 20 particles each cycle (a lot), while 1 would only release a single particle. However, that's as low as we can go. MegaGlest has, for quite some time, had the particle emission as a float (meaning decimals could be used). So a value of 0.1 would release 1 particle every 10 cycles.

The reason I think this is so urgent is the fact that we've had a few attempts to use MegaGlest mods on GAE that were halted because of only one inconsistency, this one. It's a reasonably small change that would allow many MegaGlest mods to function on GAE (well, Japanese, at least). At the very least, as a temporary measure, values below 1 could simply be rounded up to 1 (though we should support proper float values for particle emission).

42

Feature requests / Remove camera constraints in photomode

« on: 19 January 2012, 00:09:20 »

Photomode is primarily meant for taking photos without the user interface in the way. One common use is to take images of the entire map, as seen in game. However, photomode doesn't remove the camera's constraints: you not only cannot zoom out far enough to see the entire map, but cannot render the entire area that is seen. Optimally, the camera zoom distance and render distance will need to be increased (1024 should be plenty for both). If you want to take a screenshot of the entire map in GAE, you'd have to change both of those values in the INI (which has the downside that tilting the camera, even when not in photomode, will cause lag as much more needs to be drawn from the increased render distance). This increase would only affect photomode, so would not impact regular gameplay.

43

MegaGlest / AUTHORS.data.txt

« on: 2 January 2012, 23:53:31 »

It seems like all the credits for MegaGlest's data should be in docs/AUTHORS.data.txt, but I must ask, how accurate is that file, really? When making the wiki pages for the MegaPack factions, I hit a roadbump with the Egyptian faction. The authors text file states the only author is Titi, but the faction's thread has Assassin as the original creator, and lists contributions from Weedkiller and gAMeboy. Which brings me back to my question, how accurate is the authors file, and if inaccurate, what can be done to improve on that?

44

Off topic / Happy New Year 2012!

« on: 1 January 2012, 00:19:07 »

Wishing the Glest community all the best in the new year.

45

Feature requests / Experience-based leveling

« on: 20 December 2011, 22:47:33 »

This has definitely been requested in the past, but was unable to find a ticket nor a thread, so we'll repost for that purpose, along with beautiful elaboration.

As we all (should) know, units can be given levels, which they can access by reaching a certain number of kills. These levels allow you to raise stats by either multipliers or static amounts. We've long since filled up the bug with killing your own units for free kills.

However, the weakness with kill-count based leveling is that you could kill 5 pigs, or you could kill 5 airships to still count for the same level. This feature request specifies an optional system which would replace that, using a very simple experience based concept. Units would have a defined amount of experience rewarded for killing them. Levels would need a certain amount of experience to level up. However, working with both kill-count based leveling and experience based leveling at the same time is almost impossible. A unit can level up between one or the other, never both.

Currently, the XML syntax for levels is like this:

Code: (Current system) [Select]

<levels>
<level name="elite" kills="5"/>
</levels>
To state the type of leveling system, either experience or kill-count based, we'd add a new parameter to <levels>, system (either kills or experience, with kills being the default system), and the <level /> tag would replace the kills attribute with a more accurate experience attribute:

Code: (Syntax) [Select]

<levels system="experience">
<level name="elite" experience="4000"/>
</levels>
For better accuracy, units could also be given a new <experience /> tag, which would define how much experience the killer gets. If an experience tag is not specified, the max-HP of the killed unit becomes the experience (so a swordman would be worth 700 experience, and by default, an archmage would be worth 450, though you could use the <experience /> tag to up the archmage to, say, 1000).

Code: (Syntax) [Select]

<experience amount="1000" />
As it is, the unit who gets the last hit gets the kill. That's fine for a basic implementation, but a refined method I'd like to see is the kill going to whichever unit did the most damage to the killed unit. So if my horseman took of 90% of the foe's health and my swordman just happened to get the last, killing blow, the horseman will get the kill/experience, not the swordman, as it currently is. If the unit who did the most damage is dead, it would go to the one that dealt the second most. If it's dead too, well, we know how that works. This would ideally apply to both the kill and experience based leveling systems, as it would not break any mods nor have any major impact on gameplay. Of course, it could be a lot more work, since the engine would have to keep tabs on who did every hit to a unit.

Edit 2012-05-23: Experience would be gained as a percentage of damage dealt, rather than based on who got that "killing blow". So if a unit's attack knocks off 50% of their foe's health, they'd gain 50% of that foe's experience value.

On a side note, the kill based and experience based systems are not meant to function together. It's one or the other. If you use the experience based system, you'd have to use it for every unit that has a <level /> tag. Trying to get them to play nice with each other at the same time would be unnecessary and a headache. I'm not even wasting time proposing a workaround for such instances, just throw an error so the modder won't distribute their bad version.

Advantages of an experience based system:

• More accurate in terms of effort: killing an airship is vastly more difficult than killing a pig. In an experience based system, a pig might only be worth 100 experience, but an airship could be 2000, 20 times more valuable, despite being the same in a kill based system.
• Experience points and leveling go hand in hand. Sure first person shooters might use kill based systems, but many RPGs, RTSs, etc, would use experience. Players are used to it, and know exactly how it works.

Advantages of a kill based system:

• Simplicity, easier to remember; "I have to kill two more dudes to level up".
• No extra work for modders (on a rebuttal, you'd need, at a bare minimum, to add 20 characters to each unit XML, find and replace friendly).

Disadvantages of giving a choice:

• None.

46

Feature requests / Attack location

« on: 19 December 2011, 06:28:27 »

I could have sworn there was a feature request, or at least a small discussion, of this concept before, but alas, I cannot find it. The concept is straightforward and simple, yet highly useful. With a projectile attack, attacks actually are aimed at a location (namely where the unit is standing). So if the unit moves, they can avoid the attack. Thus, the concept being attacking a location is already in the engine.

What I want to see is a separate command which would use the same parameters as a regular attack command (in fact, almost exactly the same command overall), but instead of supplying a unit to attack, you supply a location (if you select a unit though, it would attack the location the unit was in when the command was issued). Thus, the attack is aimed at a specific cell on the map instead of a unit's location. The use for this is apparent with "superweapons", such as UNATF's nuke attack, which deals damage in a large area, and is meant to be aimed at the foe's base, not any specific unit. In fact, as it stands, you have to send a scout into the foe's base in order to "see" a unit to attack the base. With an attack-location command, you'd be able to just point the nuke at the location of the player's base as you rightfully should be able to.

It would also be useful with other large splash attacks, allowing you to aim in front of a moving foe, minimizing misses (for an advanced player).

47

General discussion / GAE Website

« on: 13 December 2011, 00:14:01 »

GAE does have some nice webhosting courtesy of sourceforge available here. Once upon a time, there was a rather barebones webpage on a different host (which at one point had a shiny intro), but now all we have is merely to a single page containing the GAE logo and two links (the page also redirects to the sourceforge project page after five seconds).

I'd like to propose we take advantage of this useful web space to make a webpage in the same concept that MG has with it's webpage. The webpage would (most importantly) provide a central place stating just what exactly GAE is (let's be honest here, the two sentence description on the project page doesn't give users any real reason to download GAE). As well, the images on the sourceforge project page are not the least bit enticing to players, as they show GAE's debugging abilities, a menu test, and a basic unit particles test. It paints the engine as something for developers and advanced users only, instead of a fully capable game engine easy for new players to dive in.

When practicability is the concern (eg, finding the latest download link), the sourceforge project page is great, but when it comes to showcasing the engine and getting players to download it, GAE falls short. Should we add a proper webpage, it's intent would be more like a poster: it would showcase just what GAE is, with a page describing the engine and its capabilities (we'll leave the documentation of these features for the wiki, which is better suited with its "anyone can edit" abilities), a page showing images of the engine (when downloading games, I tend to place a fair deal of judgement on the screenshots of the game, not necessarily for graphics alone, but since they can show the gameplay), and of course, a page listing the download links for the latest versions.

Should we decide to utilize a website (I for one, think GAE could really benefit from it), I would like to volunteer to design the page, but would need to know what capabilities this free sourceforge hosting has (eg, can PHP or MySQL be used?). I can't see any downsides to having a proper webpage (which again, has the primary function of aesthetics, showing off the product), and the way I see it, the only reason we don't already have a site is simply because there's nobody to make it, which I could remedy easily enough.

48

Feature requests / Concept: Auto-update

« on: 9 December 2011, 02:40:32 »

Many programs these days (actually most of mine, probably) have an auto-update function, meaning they are capable of checking for updates and potentially downloading the update automatically. I feel that such a future feature could make updating MegaGlest easier. I realize that the chat can check the version, but to my knowledge, it can't automatically update.

Ideally, there'd be a setting to toggle between three options:

• Automatically update - The simplest option, would check for updates and if one is found, commence downloading and installing it automatically.
• Semi-automatic update - Checks for updates, and if one is found, asks the user if they want to update. If the user agrees, the game automatically updates. This would ideally be the default setting. If the player declines the update, it should not be shown again until the next version is available (storing a line in the configuration INI to remember that), but should have a button to download the update in the settings menu in-game, in case they decline at one point, but change their mind later.
• Manual only - The game does not check for updates nor alerts the user an update is available.

I don't claim to know how other programs perform their automatic updates, though I do realize that finding a way to overwrite the MegaGlest binary and files while they're in use could be problematic. The simplest solution would be to have the automatic updater be its own program, which would be run by MegaGlest for a moment at the start of the game, sending the version number and operating system to check for an update, and if up to date, would close immediately. The fact it's a separate program means that if there is an update, the main executable could be closed to allow the updater to overwrite files that would otherwise be in use (unless there is a better way to overwrite files in use? I wouldn't know).

When updates are available, ideally there would be three kinds of updates stored online. The data and binary would be in separate packages. For a normal user, this could save a lot of bandwidth, but would be too complex. For the automatic updater, it would eliminate the complexity of updating while allowing everyone to benefit from "differential updates". Firstly, there'd be an upgrade package from the last official release, which would only contain the files added/changed in the last release, which would be used only if the user is using the last version. Next would be an upgrade package from three releases back, which would contain the files added/changed in the past three releases, and would be used if the user missed a version, such as an infrequent MegaGlest player. Since only so much is changed in the releases, we can expect it would still be a massive improvement over downloading the full package again. But of course, for those running a MegaGlest older than three releases, the automatic updater would have to download the full package. Linux users have a console command for making folder diffs, while windows users could use WinMerge (WinMerge 3 will support Linux).

The binary would be distributed separately (DLLs would also be bundled with the windows binary), and would be updated every time.

Ideally, the updater would check if both the data and binary packs are available for the specific operating system before notifying the user a new download is available. If there is a missing package (eg, they're using an operating system that we don't make binaries for), they would simply be told there is a new version of MegaGlest available and a link from which they could download it. The option to automatically update would not be displayed.

I realize that many people might not want to use an automatic updater, and for those with technical experience, you could potentially get better performance by compiling the binary yourself, not to mention there's those who use unreleased revisions, and some may simply prefer the manual method. However, the feature would be fully opt-out, and would not replace the chat message stating your version is outdated. Rather, the feature is largely aimed at the (often overlooked) majority of users, many who struggle to even install a mod. MegaGlest is pretty easy to install, but for "not computer people", the bloated installer is often the only reasonable way to update. This would open the ability to have differential downloads -- just the files that have been changed -- for users, while still maintaining support for those which we cannot offer binaries for (for them, there would be pretty much no change).

Admittedly, this feature wouldn't help the devs at all, nor most of the large members of the community, who are more than capable of doing the manual work, but could be a big difference in helping the unspoken majority. Keeping MegaGlest up to date is necessary for online play, so ensuring that keeping it up to date is as easy and manageable as possible should be an objective.

49

Maps, tilesets and scenarios / Lua comparison of the engines

« on: 20 November 2011, 19:33:03 »

The wiki now hosts a full comparison list showing which functions and events the three engines support:

[big][big]Lua scripting comparison[/big][/big]

MegaGlest is ahead in the numbers game. Sadly, the table also goes to show how many functions we have that do the same thing between two engines, yet use different syntax. For example, MegaGlest has giveAttackStoppedCommand() while GAE uses giveStopCommand() (for both stop and attack stopped), and so on...

Code: [Select]

[center][url=https://docs.megaglest.org/Engines#Lua_scripting][IMG]http://img254.imageshack.us/img254/8481/66401305.jpg[/img][/url][/center]

50

MegaGlest / Documentation

« on: 18 November 2011, 18:12:48 »

This is the initial list, and may be prone to missing many features. Please feel free to mention them below.

Well, it looks like MegaGlest's documentation on the Glest Wiki is starting to fall behind, so I'll be trying to bring it back up to date, with many of the new features. MegaGlest does have a Features page like GAE, but only has one "in-depth" feature page, whereas GAE has 24. MegaGlest has more than one feature that can be described in depth (eg, cliffs), and if we fail to document the syntax and usage of new features, they may end up lost, and future MegaGlest mods may not be able to utilize features simply because they don't know about them, or may have to waste time trying to get help in their usage simply because there's no "instruction manual".

As well, it's especially helpful for existing modders to have a reference, as our new features are scattered across the feature request and megaglest board, with some even hidden away in side mentions on unrelated threads. Thus, this topic will be a list so we can keep track of the pages that still need to be created, the pages that have already been created (for reference), and related to-do for MegaGlest on the wiki.

[big][big]Pages to be created[/big][/big]
[small]Features here link to the forum post detailing their installation, if it exists. Note that not all features listed here will get a "dedicated page", generally just those that would benefit from examples and an in depth explanation. For example, Lua features go on MG/Scripted Scenarios.[/small]

• Team switching
  
• Voting to pause multiplayer games
  
• Loading a scenario inside another
  
• Rotated climb
  
• Maximum number of a unit
  

[big][big]Pages already created[/big][/big]
[small]Features here link to the wiki page the feature is described on (the detailed page if it has one, the XML documentation if it does not)[/small]

• AI control
  
• Attack-boost
  
• Lua
  

[big][big]To do list[/big][/big]
[small]Other stuff that should be done[/small]

• Make redirects for pages. A detailed features page should always be named "MG/Features/Feature_name", so to ensure searchers can easily find pages, the page named "feature_name" and similar names should be redirects. Note that a redirect that could apply to either an MG or a GAE feature should be a disambiguation page.
  
• Verify the integrity of MG/INI.
  
• Ensure that features that only work in an unreleased version of MG (ie, from the SVN) detail the revision the feature was added.
• Ensure that pages are in the category Detailed feature pages and MG.
  
• A page should be created for the MG tray application

As with all lists, this will grow outdated as individuals create pages, new features are added, etc, so feel free to post on missing features or errors.