Messages

101

Feature requests / Re: Tags

« on: 4 August 2014, 05:19:54 »

I used sets to simplify the handling of duplicates (no need to manually check for duplicates -- sets ignore those). The original implementation found all unit types with a tag and threw them in the affects vector. Now that tags are separate from the affects, I guess it's not so needed. Still a strange issue, though.

Regarding `for_each`, I've never really cared for it. I'd love to use the C++11's range based for loops, but they require MSVS 2012 or later and I'm not sure if that's supported, yet. Although I'd have to check with Softcoder regarding the use of newer language features, anyway. Wouldn't want to break the build on some platform.

At any rate, the solution I used was a conditional to check if the set of unit tags is empty. Although I still don't understand why the inner for loop was even entered. The issue boiled down to `tags.empty()` being true while `tags.begin() != tags.end()` is also true (but it shouldn't be!).

102

Feature requests / Re: Tags

« on: 3 August 2014, 03:07:57 »

So, tags have been implemented, but I'm trying to improve the change so that in the list of affected units, you'll just see the tag name instead of the numerous units that have that tag. Thus, we have a set of units affected by the upgrade and a set of tags that are affected by the upgrades. Unfortunately, I'm faced with a strange bug that I'm not able to work around.

It's summed up in this StackOverflow post, but someone here may have a better idea of what could be wrong. For context, the changes up till this are on GitHub.

I don't see anything that should have gone out of scope and there's no undefined behavior that I'm aware of (unfortunately, the nature of undefined behavior in C++ makes it difficult to be sure). Compiler isn't warning me about anything. I haven't had any success with a debugger, mostly due to not being used to debugging C++ (the STL classes are almost unreadable).

Any help would be appreciated.

103

Feature requests / Re: Tags

« on: 2 August 2014, 01:46:05 »

and maybe even techtrees so you can move factions form other techtrees in and out if they work with the same tags

Since tags are merely strings, yes, they can be moved into other factions. Of course, this does have the downside of no "type checking" (if you typo a tag, you won't be warned), but this is a useful tradeoff (and not the only thing that isn't checked).

104

MegaGlest / Re: General view on new features

« on: 30 July 2014, 19:01:03 »

I disagree with the use of an "experimental" branch, by the way. I think that would actually make the problem worse. The only way to know for sure that we don't break a feature (since we don't have automated tests for this) is by using the feature. Putting features in experimental branches could lead to the feature never being used. Especially if we associate "experimental" with "unstable" (which isn't necessarily the case).

105

MegaGlest / Re: General view on new features

« on: 30 July 2014, 01:21:54 »

Long post -- if short on time, see the bottom of the post for a summary

Now, I have a feeling this thread is partly due to some of my recent changes...

It's a good point that unused features are dangerous. Normally, I strongly desire to remove unused code. However, one major issue that hasn't been pointed out so far is that these features require mods to use them, and it's difficult to say whether a mod will use a feature or not. In other words, if we implement some feature, will a modder use it? This is hard to say. I don't think we should limit ourselves to features that modders request. After all, people certainly have used features that were unsolicited. It's very easy to not realize that you could incorporate some feature until it already exists.

Back when I was actively making mods, I got a lot of ideas by just looking through GAE's feature list. I realized a number of places where I could use features in interesting ways. I'm pretty sure some of those ideas wouldn't have come up if the feature was not already in the engine. Long story short: possibilities breed creation.

Regarding the issue of content, I'd like to point out that I think the MegaPack is rather disappointing in terms of using features. I think the MegaPack has no overarching goal and nobody has any intention of actively developing it. We did have a topic some time back about revamping a new MegaPack, and it met a great deal of discussion. Ultimately, though, it fell short because (1) not enough modder interest (I've lost interest in modeling and texturing, and prefer to code) and (2) no guarantee of working out (it was very ambitious and there never was any guarantee it would even replace the MegaPack).

So, really, why don't we utilize features in the MegaPack (the kinds that don't require art, anyway)? Are we too scared of breaking the existing balance? For example, I'd like to again propose that we utilize the start-ep change to allow all units to start with full EP (rather than have to regenerate their EP). I propose we use more attack boosts (mostly on the late game units). Last time I checked, only the Roman General has an attack boost. Why not make some unit shoot its projectiles in groups of three (multiple projectiles)? Create an upgrade that boosts attack speed (I created a pull request for this, but not sure if this one is merged, yet)? Allow looting of resources from buildings (helps subsidize the extreme costs of attacking a base)?

In other words, why don't we actually use some of our features?

With that said, I do worry that being very restrictive about accepting features will hurt freelance contributions. When I started creating small features, I purposely cherry picked changes that I believed were very doable. After all, a new system (especially one so terrible documented as MG is) is a huge barrier. You can't do complicated changes right off the bat. Small, simple changes are a necessity for someone unfamiliar with the system (and this applies no matter how good of a programmer they are).

I spent quite a bit of time going through the feature requests board (and wish we could use a better medium for tracking feature requests and bugs). I did not see a whole lot of choices for features that could be doable by someone still learning the engine. I suspect this may be in part due to MG's small size. There's just not a whole lot of tiny little changes needed (programs like Firefox tend to have thousands of little issues which aren't severe enough for anyone to have bothered dealing with, but are very simple to fix).

Another note is that our documentation sucks. It's very difficult to use features when there's no single, organized place to find details about the features. The wiki is the place for this. Unfortunately, it's very outdated. Admittedly, this is partly my fault -- I keep telling myself to update the site, but never have the time or bother. Also, errors on the wiki can go unnoticed for a long time. Just last week, I fixed a big mistake on the attack-boost page that went unnoticed for a year and a half! And attack-boosts are one of MG's biggest features.

Finally, I'd like to point out that our modding is at what may be an all time low. There seems to be very few active modders at the moment. I suspect that this will hinder adoption of new features.

Quick summary of this post:

• Modders may use features simply because they already exist
• The MegaPack isn't using new MG features despite so many possibilities!
• Developers unfamiliar with the engine need simple features to implement while they learn the engine
• Our documentation blows
• Active mod development is very quiet right now -- few people to utilize features

106

Feature requests / Re: Tags

« on: 29 July 2014, 04:19:46 »

Molas brings up some additional ideas on how tags could be useful. A Lua function could provide access to tags (so you could, eg, have an area that damages humanoid units).

With that said, I do think tags simplify the process of assigned affected units. Many types of upgrades affect categories of units. Used consistently, assigning units to a category ("tag") in one place (their unit XML) removes the worry of creating inconsistencies (by failing to change every other place that requires this change). It's fairly well established that the more places that have to be updated to fully implement a change, the more complicated it is to create the change (evolutionary coupling aka logical coupling).

107

Feature requests / Re: Tags

« on: 27 July 2014, 20:08:46 »

At the moment I'm having build errors on the current develop branch (without any changes) and have not been able to get any assistance with these.

So I'm putting this on the backburner for now. It's no fun to develop for a program that I can't even reasonably get to compile. If I'm able to get the code to work with me in in the future instead of against me, I'll take another look at implementing this. But in the meantime, this is just a major pain in the ass. Thus, I will not be making any more changes to MegaGlest's game code.

EDIT: Got it working now. As per the advice of titi, the build folder (in mk/linux) has to be removed. It seems that the issue is related to CMake.

108

MegaGlest / Re: alternative way to setup MG in eclipse

« on: 25 July 2014, 05:28:42 »

I actually started typing up how I eventually "figured out" how to get rid of the various errors Eclipse thought I had. It was caused by the SDL_types include in shared_lib/include/platform/sdl/data_types.h. The file has a line:

Code: [Select]

#include <SDL_types.h>
which had to be changed to

Code: [Select]

#include <SDL/SDL_types.h>
But now I've got yet more errors (I'm leaving what I already typed in case it's useful for anyone else).

Honestly, getting MG to work in Eclipse has been nothing but a complete disaster for me. I've spent more than 5 hours trying to get the errors to go away. I've tried every Stackoverflow answer I could find, advice from the IRC, and more. So now I've just disabled all code analysis in Eclipse. I hope those CMake files are well configured in regard to warnings.

If anyone else needs to do this, for Eclipse 4.4 Luna, go to Project > Properties > C/C++ General > Code Analysis and switch to "Use project settings", then uncheck every box. Then go to the "Launching" subcategory and make sure both boxes are unchecked.

This keeps the index intact, so you can still use the call hierarchy (etc), but completely removes all warnings and errors in Eclipse. You'll have to compile to find warnings and errors.

109

Tools / Re: How to setup a fork on github for develop

« on: 25 July 2014, 04:38:09 »

theres a better way to do that but i know this one and it works

git push -u origin develop. If I recall correctly, if you try and push without setting the remote branch to push to, you should get a message that details the command to use(this one).

110

Feature requests / Re: Tags

« on: 22 July 2014, 15:44:49 »

That's simple enough on its own, but because it affects the AI, it's a bit more complicated.

Might be something worth looking into in the future (although at the time, I have little experience with AI).

111

Feature requests / Re: Tags

« on: 22 July 2014, 14:55:52 »

This feature is so nessesary, and should work for targeting too.

Could you elaborate on what you mean by "targeting"?

112

Feature requests / Rename attack boosts

« on: 22 July 2014, 01:44:11 »

I'd like to suggest that attack boosts be renamed. The name is inaccurate and very misleading. Until you read the documentation, it's not clear that it can boost stats besides attacks or be associated with skills other than attacks. If I recall correctly, the name is a hold-over from older times.

So I propose that we depreciate the `attack-boost` element (in the same way that `attack-strenhgt` (or however they spelled it) is depreciated). We can support both `attack-boost` and some new name (the XML parser has simple means of doing this, which are already used for `attack-strength`.

I think we should use the name `emanation` to describe attack boosts. This is the term that GAE used. MG's attack boosts and GAE's emanations are roughly the same thing. Dictionary-wise, emanation is also more accurate: "an abstract but perceptible thing that issues or originates from a source". Alternatives include "aura", "automatic-effect", or simply "boost" (using one of these would allow our terminology to be distinct from GAE -- I can think of pros and cons to this). "Boost" is what the English transformation is already using in-game.

If we do rename attack boosts, we should consider doing so in the source code, too (very easy to do with a bit of find and replace).

113

Feature requests / [Please Test] Tags

« on: 22 July 2014, 01:22:13 »

I intend to re-implement a feature of GAE that I believe was useful: tags.

Tags are just a label (or multiple labels) that can be given to a unit type. Then we can make changes that only apply to units that have certain tags. For example, instead of listing all the units that an upgrade is applied to, we could instead use tags to assign some custom property (eg, "warrior" or "mage") and then apply the upgrade to all units with that property. These are more useful with attack boosts, since attack boosts can affect multiple factions.

Tags are most effective if they are used consistently throughout the entire techtree. They make it easy to apply attack boosts to a group of units based on some property (such as whether they're a building, a sword user, etc).

Tags also have future potential in being used with other features. For example, looting could be improved by assigning a list of tags for units that can loot (perhaps normal units can loot, but buildings (like the defense tower) cannot). In fact, I intend to extend looting in this way after tags are implemented.

I intend to use the same syntax as GAE did. As an aside, the feature does seem redundant when first using it, but it's actually quite a please to use (speaking from experience) when used consistently throughout the techtree. It works best for mods that use attack-boosts (emanations in GAE) heavily. It's a pain in the ass to keep adding units to the various affects lists of attack-boosts every time you create a unit. Easier to add a tag in one spot.

For a real example of how a tag is useful, consider some zombie warrior that inflicts a disease (using an attack boost) on nearby units (in GAE, this would be better done with an effect, which is essentially an attack boost that is applied to the target of an attack). Anyway, it doesn't make sense to apply a disease to a building, so naturally we're going to limit this attack boost to only effect humanoid units. How do we do this? Do we keep an affects-list of every humanoid unit in this attack boost (and bear in mind we have to manage all these affects-lists)? Tags provide an alternative by simply saying that the attack boost affects "humanoids", and then each humanoid can be given a "humanoid" tag. Thus, we localize the unit properties (being humanoid) to the location that they are relevant.

It's going to be a few days (or perhaps until the weekend) until I can get started with this, so feel free to discuss this idea.

114

MegaGlest / Re: Managing MegaGlest's code

« on: 20 July 2014, 19:03:01 »

Ok, given that I'm the one making the complaints, it seems that I should also be "putting my money where my mouth is".

So I've started an attempt to begin documenting the code. I've summed it up [in this pull request](https://github.com/MegaGlest/megaglest-source/pull/20). I hope to add more documentation over time (although it's going to be a long term thing). Due to this, I'd like to suggest that documentation changes are merged periodically. I'll make sure that the documentation branch contains no code changes, so it should be safe to merge at any time. Although, if time allows, it'd be a good idea to skim over the documentation before merging it, to catch any potential errors (I didn't write the original code, after all, so can only make educated guesses towards its intent).

I'd also like to propose that all future code is documented along the same lines of verbosity (and if you check the change request, you'll see that isn't much). It may also be a good idea to document complicated parts of the code as you make changes to them, as you'd be in a good position to understand that part of the code.

EDIT: I've further added documentation to another file. I've found, however, that I'm not sure how to handle potential easy refactorings that come up while documenting. For example, Upgrade has a factionIndex field that I believe is unnecessary. As far as I can tell, it's only used for checking that the Unit we're applying UpgradeManager::computeTotalUpgrade to is in this faction. However, I don't see an circumstances when it wouldn't be (since the UpgradeManager already an aggregate of a Faction and Unit directly gets the UpgradeManager from this Faction. Thus, it must have the same Faction as the Upgrades in the UpgradeManager).

For another example, the enum UpgradeState has an unnecessary value for the length of the enum (I never understood why arrays and enums in C++ didn't store their length, like every other language does), but the value is unused and there's no reason to iterate over the states.

For now, I'm just adding TODO notes in the comments (I don't want to mix potentially unsafe refactoring changes with the safe documentation changes). They can probably be done after the documentation changes (this particular one is very easy -- remove the field, change the constructor to not use that field, and change the implementation of UpgradeManager::computeTotalUpgrade to not bother checking that).

115

Closed feature requests / Re: Multi shots

« on: 20 July 2014, 15:41:03 »

Sounds good to me. And if the damage is not specified, we can assume a uniform distribution.

116

MegaGlest / Re: Managing MegaGlest's code

« on: 20 July 2014, 15:38:53 »

This is something I really want. I think softcoder and me use eclipse ( maybe you should try too ) to build. With this formatting can be done very comfortable! But this breaks the whole history so the point where we can do it must be choosen very carefully.

I actually use Eclipse as my dominant IDE for work and school. A current project of mine uses an on-save auto formatter. Although I think the Windows project needs some heavy tweaking to get it to work with Eclipse.

Documentation ... 
Well, I try to comment at least a bit, but original code nearly had nothing commented. Documentation in general is something whats not too fun to do, especially giving a system overview of something you did not do yourself and where you don't know the details.  And I  still have problems to understand the code in many places ( especially OpenGL parts ). But if there is "someone" out there who wants to start with it ....

I can try and add documentation to portions of the code. I don't really have any experience with graphics programming, though, so probably won't be able to touch that stuff (perhaps that'll change in the future -- taking a course on computer graphics next term).

Well its old code, no wonder its in there. The problem is, if you start with something else you have a mixture of different coding styles making it even harder to understand the code in the end. GAE did this and it was really hard for me to understand the code mixture there.

Good point.

Unit tests:
Well softcoder started a bit with unit tests. I personally think tests are really a lot of work and are typically not fun to do :-/ , so especially writing tests for already existing code which was not made by you  is not really something that will likely happen.

Yeah. I would think that testing would be easier if we could refactor methods to be cohesive (there's a lot of methods that do so much at once, and that's a pain in the ass to test) and make appropriate use of easily testable code (dependency injection is very helpful here), then creating unit tests with the help of a mocking library could be doable. But you're right that it's a lot of work and not very fun (well, except when the tests let you know that you broke something).

One thing in particular that we could do right now without too much work would be to split files into smaller ones. A bunch of files have several classes in them. Those classes could be moved to their own files.

117

MegaGlest / Managing MegaGlest's code

« on: 20 July 2014, 05:51:43 »

Now that I've actually tried to implement things, I've found that MegaGlest's code base is a mess.

In particular, there doesn't seem to be much for code conventions.

• There's tons of commented out code
• Formatting is very inconsistent. In the same method, I've seen `foo=1`, `foo= 1`, and `foo = 1`.
• Documentation is virtually non-existent. This creates a huge learning curve to try and figure out what the software is doing. Not to mention you'll never understand the code you wrote six months later.
• Use of outdated C++ conventions. There's a complete overuse of pointers, for example. RAII, a common programming idiom in C++ for writing safe code, is rarely used. And new code pretty much has to be written pointer heavy, or it ends up being inconsistent with the rest of the code.
• There's a number of code clones. Some which can be eliminated by extracting common code into a method.
• Code is thrown into a handful of gigantic files instead of being appropriately split up. Smaller files are typically more manageable and less cumbersome to work with.
• Lines are pretty much never wrapped. I haven't even seen the majority of files, but I've already seen plenty of lines excess of 500 characters!
• Unit tests pretty much don't exist. MegaGlest would be difficult to test because (1) it was never written with testing in mind and (2) being a game, there's a number of things that only show up graphically (difficult to write automated tests for)

My point being that there's a lot we could do to make the code more manageable. Have some of these points already been considered?

Some of these can be addressed quickly. A formatter ("pretty printer") can make short work of inconsistencies in formatting. A great deal of commented out code can be removed quickly with appropriate regex (commented out code adds nothing; there's no way to know if the code works, if it is still applicable, if it has bugs, etc). Of course, the problem with these large, automated changes is that they pretty much cut off easy access to old revisions and make merging hell (tons of minor inconsistencies). It can be manageable if done when there's no major feature branches on a stable release, though.

Unfortunately, the more useful fixes, particularly documentation and use of modern C++ idioms, would be time consuming and require manual work. It's very possible, though (in fact, my current job is mostly refactoring, documenting, and creating tests for a Java project that did none of these).

118

Feature requests / Re: Attack boosts that effect attack speed

« on: 20 July 2014, 04:51:58 »

Done! See the pull request for details.

Works for both attack boosts and regular upgrades. Attack animation is boosted accordingly.

119

Closed feature requests / Re: [Awaiting pull] Looting

« on: 20 July 2014, 01:59:53 »

Titi, the "issue" of looting faction specific resources that I mentioned in the IRC is actually non-existent. There's no issues here. The resources are correctly ignored and are not displayed. It turns out I was modified the wrong part of the XML when editing it (creating a resource requirement instead). As far as I can tell, there's no issues with this change. I also played a full game to make sure that the AI wouldn't go wonky or anything.

As we discussed, all percentages are now integers (also applies to the starting HP/EP change). This is done in hopes of avoiding possible multiplayer out of sync errors caused by clients calculating floating point numbers in different ways.

120

Closed feature requests / Re: [Awaiting pull] Allow mods to specify a starting HP and EP value

« on: 20 July 2014, 00:26:43 »

The EP startValue makes sense for sure. Maybe not to use it directly with MegagGlest data, but in general for other Mods, like the tower defense mod it makes sense.

Good point. I wasn't sure whether or not to include the EP start value change. Perhaps just the HP fix (which ensures units start with full HP, including upgrades) should be used for now. The EP change would likely need balance testing.

My main reason for including it was because I find it very frustrating if Magic is attacked and needs to spit out emergency units. The units are created and cannot immediately attack (which Tech's units can). In fact, magic doesn't really have *any* way to immediately attack after their units are created. The EP still serves the purpose of preventing the unit from attacking too often.

I think HP-boosts don't really make any sense in MegagGlest, as they would have a VERY similar effect like boosting the armor for a while so everything regarding this does not make a lot of sense.

Good point. I'm not going to bother looking for a way to boost stats above the max (at least not at the moment).

HP start value: I don't really get the need for a HP start value, so can you explain what this should be good for ?

Above all, it allows us to fix the issue that units spawn with their "default" max HP. Upgrades to the max HP are not included. So if a unit normally has 1000 max HP and an upgraded boosts that to 1500, then they spawn with 1000/1500. This seems unintended. Also, if the unit has no HP regen, it can't actually access its max HP. It's also useful for mods that may want to force the unit to regenerate itself to max HP (eg, a unit that starts weak by spawning with low HP, but gets stronger over time as its HP slowly regenerates).

In general: Please try to discuss things first if possible in IRC chat. I also do this a lot and I get many ideas/hints which I did not think about. I myself will also try to reply more to your forum posts now I know there is a chance that you suddenly start working on it.

Sure, great.

121

Closed feature requests / Re: Looting

« on: 19 July 2014, 23:11:20 »

Done! See the pull request for details.

EDIT: Gah, I have some minor compilation errors that appear to be platform dependent (no errors in my build). I'll try and get these fixed, but it's gonna be a pain in the ass when I'm not getting the errors locally (TravisCI takes like 10 minutes to let me know if the build passed).

EDIT2: Fixed. Turns out Windows overrides a standard library function with a macro somewhere in its headers (which are presumably included by some library).

122

Closed feature requests / Re: Allow mods to specify a starting HP and EP value

« on: 19 July 2014, 17:28:49 »

It's done.

Code: [Select]

[url]Here's the pull request[/url]. Below is the full summary of changes (taken from the pull request):

The absolute or percentage starting value can now be set for either HP or EP.

Setting the absolute value is done with `start-value`, while setting the percentage is done with start-percentage. Both of these are attributes of the max-hp and max-ep tags (different from Tiger's changes, which had the starting EP a tag of its own).

The starting percentages are always a percentage of the upgraded max value. Thus, if a unit normally has 1000 max HP and an upgrade is in effect that increases its HP by 500, then setting the max hp to have a starting percentage of 0.5 will result in the unit starting with 750 HP (the result of (1000 + 500) * 0.5).

This is particularly useful because the default behavior is to have units start with their max HP, even if they have upgrades that boost HP. Thus, if you want your units to be created with a starting HP equal to their true max HP (with upgrades), set the percentage starting value to 1.0.

Note that `start-value` and `start-percentage` are mutually exclusive. You cannot use both at the same time. Attempting to do so will cause a runtime error.

I have tested various combinations of starting values and percentages with and without upgrades.

Example:

Code: [Select]

<!-- ... -->
<max-hp value="500" start-percentage="1.0" />
<max-ep value="1000" regeneration="5" start-value="500" />
<!-- ... -->

Known issues

• Setting the starting HP to 0 causes the unit to be immortal. This actually may be a feature.

I wasn't able to make it so that you can start with greater than max HP/EP (a starting boost), as somewhere else in the code seems to be checking that current HP does not exceed max HP. I'll probably look into whether or not that can be feasibly changed (it's pretty common in various games, eg, Deus Ex HR, to be able to temporarily boost above max HP, but can only regenerate up to max HP).

EDIT: As mentioned in the original post, I've Created another pull request for making all units start with full HP and EP. Pull request message:

This differs in two ways:

• Units that have upgrades that boost health take effect from that upgrade immediately, instead of having to regenerate the difference.
• Units with EP start with full EP instead of none. Thus, a newly created mage can head straight into battle instead of having to wait for their EP to regenerate. This may impact balance. On one hand, EP using units were at a disadvantage because of this need to wait. On the other hand, this makes them slightly more potent, off the bat. It shouldn't make a difference when attacking, though, and only a minor difference for defenders.

123

Closed bug reports / Re: [31def0dc1a] Preprocessor inconsistencies when compiling MSVS debug

« on: 19 July 2014, 17:23:01 »

...I presume that's the active development branch; couldn't find any info about how the project uses branches...

Very official and common way, go there and read "The main branches" paragraph first. I haven't idea why it isn't written on the beginning  .

Oh, I know, I use Git all the time. I'm a CS student and currently employed at my university to bring in heavy refactoring to this Java simulation system that was programmed by C programmers.

I mentioned the branches because I've seen a lot of projects use them in crazy ways (the simulation system that I mentioned was originally developed for months by some very smart people without version control).

124

Closed bug reports / Re: Windows DLLs outdated

« on: 19 July 2014, 16:27:48 »

if you need something for 3.9.0 (why?) then you should look for old commit, tagged 3.9.0.

I'm working on the development copy. The only reason I mentioned 3.9.0 is because that's the only place I could get the 7-zip files from (they're not in the windows deps).

Process of overwriting files doesn't goes hand in hand with stability.

But overwriting is exactly what patching does.

Wiki says:
... is usually due to outdated build dependencies. Check http://sourceforge.net/projects/megaglest/files/ for windows_deps.7z when it was last updated, and if it's more recent than the one you have in source\ (or if you are unsure), then recursively delete both source\windows_deps\ and source\windows_deps.7z. ...
and then launch script.

But both the script and deps archive seem to be outdated. And I'm running develop/HEAD. At any rate, this was a fresh install. source/windows_deps did not previously exist. I just downloaded the windows deps archive last night.

125

Feature requests / [31def0dc1a] Run time errors need to be handled better (more visible)

« on: 19 July 2014, 16:23:43 »

I could have sworn that we used to do a better job at handling run time errors (although I may be thinking of GAE; it's been a while).

By run time error, I'm referring particularly to errors in validating tech trees. Right now, they crash the program and don't print to the log. The error log has not been touched. The regular log just cuts off at the unit where the error was thrown. In order to retrieve the error message, you must run the game from the console (so that the console won't close when the program closes).

And even then, the error messages are heavily overcomplicated (for whatever reason) and the simple message is concealed within two dozen lines of "stack traces" (and I put this in quotes because it's not a stack trace I've seen before and doesn't seem to be useful in any way). This may be related to the other issues that I pointed out today, namely that Windows won't compile unless an exception handling line is commented out and that the debugging files are output in the wrong name.

Below is the error of the simple mistake of using an invalid armor type on a single unit.

Code: [Select]

$ megaglest.exe
megaglest.exe v3.10.0-dev
Compiled using: VC++: 1600 [DEBUG] on: Jul 19 2014 07:40:38 platform: Windows endianness: little
GIT: [$Rev$] - using STREFLOP [SSE] - [no-denormals]
*ERROR* [2014-07-19 10:06:38] In [unit_type.cpp::Glest::Game::UnitType::loaddd Line: 727] Error [Arm
or Type not found: asd
Stack Trace:
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18
]
*ERROR* [2014-07-19 10:06:38] In [faction_type.cpp::Glest::Game::FactionType::load Line: 185] Error
[Error loading UnitType: f:\Documents\Projects\MegaGlest\megaglest-source\data\glest_game\techs/mega
pack/factions/indian/units/stickfighter/stickfighter.xml
Message: Armor Type not found: asd
Stack Trace:
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18

Stack Trace:
00000000 00000000 00000000 c809a7e5 NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c809a7e5 NtGetContextThread!ntdll (null)(0) +18
]
*ERROR* [2014-07-19 10:06:38] In [tech_tree.cpp::Glest::Game::TechTree::load Line: 357] Error [Error
 loading units: f:\Documents\Projects\MegaGlest\megaglest-source\data\glest_game\techs/megapack/fact
ions/indian/
Message: Error loading UnitType: f:\Documents\Projects\MegaGlest\megaglest-source\data\glest_game\te
chs/megapack/factions/indian/units/stickfighter/stickfighter.xml
Message: Armor Type not found: asd
Stack Trace:
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18

Stack Trace:
00000000 00000000 00000000 c809a7e5 NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c809a7e5 NtGetContextThread!ntdll (null)(0) +18

Stack Trace:
00000000 00000000 00000000 c809ae0d NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c809ae0d NtGetContextThread!ntdll (null)(0) +18
]
*ERROR* [2014-07-19 10:06:39] In [program.cpp::Glest::Game::Program::setState Line: 683]
Error [Error loading Faction Types: f:\Documents\Projects\MegaGlest\megaglest-source\data\glest_game
\techs/megapack/
Message: Error loading units: f:\Documents\Projects\MegaGlest\megaglest-source\data\glest_game\techs
/megapack/factions/indian/
Message: Error loading UnitType: f:\Documents\Projects\MegaGlest\megaglest-source\data\glest_game\te
chs/megapack/factions/indian/units/stickfighter/stickfighter.xml
Message: Armor Type not found: asd
Stack Trace:
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c8099fdd NtGetContextThread!ntdll (null)(0) +18

Stack Trace:
00000000 00000000 00000000 c809a7e5 NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c809a7e5 NtGetContextThread!ntdll (null)(0) +18

Stack Trace:
00000000 00000000 00000000 c809ae0d NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c809ae0d NtGetContextThread!ntdll (null)(0) +18

Stack Trace:
00000000 00000000 00000000 c809b615 NtGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 c809b615 NtGetContextThread!ntdll (null)(0) +18
]
AL lib: ReleaseALC: 1 device not closed