Messages

76

Mods / Re: Minecraft Mod

« on: 28 November 2014, 08:22:54 »

What's this? A GIF for ants?

77

MegaGlest / Re: What to do with GAE descriptions in Wiki?

« on: 28 November 2014, 08:18:55 »

It was going to be removed, but nobody has done it and I have no time.

78

Closed bug reports / Re: Improper handeling of Multiple Attack Boosts

« on: 24 November 2014, 03:34:09 »

^{I want this renaming thing to take off, so I'm gonna call them auras instead of attack boosts.}

I can confirm that Softcoder is correct (I had to do a double take on that description).

The relevant part of the code is:

Code: [Select]

if(boost->allowMultipleBoosts == false) {
// Check if we already have this boost from this unit type and multiples
// are not allowed
bool alreadyHasAttackBoost = this->unitHasAttackBoost(boost, source);
if(alreadyHasAttackBoost == true) {
shouldApplyAttackBoost = false;
}
}
As we can see, the only thing this variable does is prevent repeated application of the same boost to a unit. Since this check can happen many times per second, the effect quickly piles up and the current way that boosts are applied do not allow a maximum to be specified.

So it may not be a bug in the traditional sense, but I believe this is a serious design bug. As Ishmaru states, there's pretty much no reason for this behavior. I cannot think of a positive way to use this (since anyone receiving the boost will have their stats boosted to infinity). I think it should be changed to:

• Off: Users can receive a single aura from each unit of each type. For example, if the castle has an aura and a unit is near 2 castles, it should only get the boost from a single castle (doesn't matter which since the boosts are the same, but we should assume that in the future, it may be possible for the same units to have different boost; consider the possible feature of upgrades that boost auras).
• On: Users can receive an aura from each unit nearby. So if castles have an aura and a unit is near 2 castles, they should receive twice the effects of the castle's aura.

This has a clear and obvious use case: we could have healer units that heal nearby units. More healer units let you heal faster (probably shouldn't be able to heal themselves to prevent abuse). Or powerful generals that enhance their allies stats and more generals mean more stat boosts (but these units are limited enough to not be abuseable).

As an aside, a potential future feature request that may be of use would be the ability to provide maximum and minimum boosts. This would make it easier to prevent abuse of stacking attack boosts. For example, maybe a common enemy reduces enemy attack by 1%. This stacks with the number of this unit up to a minimum penalty of -10%. It makes it useful to have many of these units without allowing that ability to be abused (of course, an alternative is to just limit the range so that you can't have too many in the area of affect -- this limitation makes the above mentioned feature request very low priority).

79

Closed bug reports / Re: bug with chat in custom-menu, only one line visible

« on: 23 November 2014, 17:58:49 »

Have you considered using GitHub's issue tracker for reminders like this? One particular advantage they have over forums is the ability to easy categorize and filter by what bugs must be fixed for the upcoming release. In my last job, we used GitLab's issue tracker, which worked very similar to GitHub's. In my current job, we use Asana for similar purposes. I think they both improve productivity.

80

MegaGlest / Re: The idea Going to change history MG

« on: 9 November 2014, 23:44:09 »

The complication here is, if a registered user plays against a guest, how should the registered user's score be tabulated if it's based on opponent skill?

The simplest thing to do is treat unregistered accounts as rank 1.

The more interesting thing to do is to make a rank based on relative scores and the ranks of other players. For example, if you get about the same score as a rank 5 player, then we'd treat you like you were rank 5. Do better and you're treated like a higher rank and vice versa.

81

MegaGlest / Re: The idea Going to change history MG

« on: 7 November 2014, 05:24:24 »

How force? If the method like "registration, or fuck off" then I strongly disagree.

By force, I mean that when they try and play multiplayer on a master server (and just that) they'll encounter a screen asking for them to either login or register.

So they can easily try the game without registering at all. And the actual registration would be super straightforward and hassle free. Pick a username. Enter a password. Confirm the password. Done. Optionally can enter an email to allow account recovery. That's like the system Reddit uses. Except we wouldn't even need a captcha (since registration is in-game only and is really just to play the game).

Of course, we could also just allow skipping the registration stage. The part you're quoting is an alternative (which *might* entice people into playing more competitively -- or do the exact opposite; I don't know). In which case we'd just ask users for a temporary name (not stored anywhere, but presumably should be used by a player) and treat them like rank 1. Optionally, we could offer the ability to create an account after their first game (and allow carrying over the score from said game).

82

MegaGlest / Re: The idea Going to change history MG

« on: 6 November 2014, 06:47:37 »

The main difficulty comes from cheat prevention. It's very difficult because someone can modify the source code to cheat.

With that said, cheating is an issue for even large closed source games. I think it's reasonable to simply ignore the cheating (there's already systems in place that would prevent the easiest methods of cheating) and simply remove any cheating accounts that might show up.

In which case, it's mostly a matter of using the game stats that are already sent to play.mg. The sent data would have to be modified to take accounts into affect. There's probably other issues -- I'm not very familiar with the multiplayer code. We could then create some kind of scoring system. For example, create ranks (based on points) and give points for winning games using the score times some rank multiplier (so beating rank 1 players doesn't reward as many points as beating a rank 10 player). The configuration of the game (players versus AI, players versus players, etc) needs to be taken into account. It's not that important right now (that's the easy part).

Of course, this opens additional complexities for those who want competitive play (namely the ability to find similarly ranked players), but that's not a big concern, particularly since our community is too small to sustain such a type of play.

That leaves most of the development on the creation and management of user accounts. It seems that the main difficulty is sending scores to this ranking site without allowing just anyone to send the score. This again ties into the cheating issue and would depend on what part of the game is sending these scores. If a master server can send the scores, this is more ideal. We could maintain a list of trusted master servers that have keys that they use to encrypt the score and only properly encrypted scores would be accepted. It does limit the ability to play ranked games (have to use an approved master server), but there's just no getting around the fact that we cannot trust the client (and the open source nature of MG prevents us from placing any kind of key inside MG). Again, I'm not familiar with the multiplayer code and it totally depends on that (it may already be the case that the master server is the only part reporting finished games).

The creation of user accounts is actually fairly straightforward (especially if we use a library). The game would login by connecting to this ranking server. We'd get current rank from this server. At the end of the game, we'd send the points earned by the game to the ranking server (securing this was the topic of the previous paragraph). Players would be able to create accounts in the game. The difficulty here is preventing easy creation of multiple accounts and playing against these accounts. I don't think there's any real solution. It shouldn't be necessary to verify the account since we don't want to exit the game. Similarly, we don't want to use the IP in the account because the same IP may have different users (consider the case of Titi and his son using the same computer even though they'll certainly have different accounts).

User accounts can simply be a username - password pairing. There's no need for anything else at the time (although future features could expand on that). Although an optional email for the purpose of allowing accounts to be recovered is a good idea (no email = no recovery option). We can allow unregistered players to also play in a similar fashion, and treat them as players of the lowest rank when creating the scores for other registered players. Alternatively, we could force players to register (more enticing for competitive players who want to be able to maximize their score by playing against similarly ranked players). I don't see any reason that anyone would want to avoid registering besides the very small registration time (there's no required personal information being stored).

So in summary, we'd need to

• Create ranking server that stores rankings online and provides the means to communicate with this server to authorized master servers.
• Master server must have some private key to show that it is trustworthy.
• After completion of games, master server sends the score change for all registered players. Alternatively, master server sends the data it already sends but with account information and the play.mg site calculates scoring and ranking.
• Change in scoring depends on factors such as game configuration and other player's ranks. Ranks are simply obtained by getting certain scores (like how the ranks on this forum depend on posts).

The security of this is important to keep in mind, since if the system gets easily and uncontrollably gamed, then the entire ranking system becomes worthless.

Sample scoring system

• Use score from games (and the game's scoring system can/should be adjusted to better reflect skill). I implicitly refer to this score from now on.
• Games against AI where there are no humans on the AI's team are divided by 2^h where h is the number of humans played against the AI and multiplied by the number of AI and the multiplier of the AI. So 2 humans versus 2 AIs with a 1.5 multiplier (CPU-ultra) is a score multiplier of (2 AI * 1.5 multiplier) / 2^{2 humans} = 0.75.
• Games where the human has AI on their team are further divided by the multiplier of that AI plus one. The plus one is to prevent increasing the score when humans have weaker AI on their team. So stronger AI teammate = score penalty. This effect stacks. For example, if you have a two normal AIs on your team (1.0 multiplier), your score is divided by 2 twice, resulting in a score multiplier of 0.25.
• Teams get the average AI-on-your-team score penalty of all other teams + 1. So if the above example of a team with two normal AIs was playing against a different team with no AIs, then the team with no AIs gets the 0.25 plus 1 = 1.25.
• Games against humans are ultimately going to depend on how hard it is to get ranks, but something like multiplying by the difference in your ranks divided by the number of ranks plus one seems like a quick approach. Thus, it's beneficial to play against higher ranked players and worse to play against lower ranked players. For example, if a rank 2 player plays against a rank 5 player and there are 10 ranks, that player gets a score multiplier of (5 - 2) / 10 + 1 = 1.3. On the other hand, the rank 5 player gets (2 - 5) / 10 + 1 = 0.7.
• To handle the case of teams of humans versus teams of humans, we use the algorithm from the above point and apply it against all other players. For your team, we take the average of comparing you against players not on your team and divide that by the average of comparing you against other players on your team. So if your team average compared to you is 0.5 (implying that your teammates are a lower rank than you) and the averages of players not on your team compared to you is 1.5 (implying they're a higher rank than you), you'll get 1.5 / 0.5 = 3.
• To make up for mismatched team sizes, if one team has less players than any other team, they get an added bonus of 0.25 * team size difference. For example, if there's game of 3 on 1, the player who is on the solo team gets a bonus of 0.25 * 2 = 0.5 added to his score multiplier.
• And of course, most importantly, winning doubles your score multiplier. Losing halves it. So all else equal, winners get 4 times the points that losers get. Big benefit for winning, but not too bad for losers. To increase the dependence on the multipliers and game score, this difference could be increased.

Example game with this scoring:

Player	Rank	Team	Game score
Alice	2	1	10,000
Bob	3	1	12,000
Carol	4	2	20,000
AI (0.5 multiplier)	N/A	2	Doesn't matter

Assume that Carol beat Alice and Bob. Assume there is 10 ranks.

Carol's score: Since Carol has an AI on her team, her score is divided by the AI multiplier + 1. So her score multiplier is now 0.66 (1/ (0.5 multiplier + 1)). The difference in her score from Alice is (2 - 4) / 10 + 1 = 0.8 and the difference in her score from Bob is (2 - 3) / 10 + 1 = 0.9. Average of this is 0.85. So now her cumulative score multiplier is 0.66 * 0.85 = 0.56. She won, so her multiplier is doubled, making it 1.12. She gets 1.12 * 20,000 = 22,400 rank points.

Alice's score: The difference in Alice's score from Bob is (3 - 2) / 10 + 1 = 1.1. The difference from Carol's score is (4 - 2) / 10 + 1 = 1.2. The average of players on her team is obviously 1.1 and the obvious of players not on her team is 1.2. We then divide the players not on her team by those on her team, 1.2 / 1.1 = 1.09. Alice's team doesn't have an AI. The AI penalty of the only other team was 0.66, so this team gets a multiplier of 1.66 making the cumulative score multiplier 1.09 * 1.66 = 1.81. Alice lost, so her multiplier is halved to 0.91. She gets 0.91 * 10,000 = 9,100 rank points.

Bob's calculation is similar, so won't be shown here.

Points to ponder

• Good thing about a system like this is that fair games will result in getting the same number of rank points as the number of game points. Multipliers only come into play when the game is unbalanced (or when we play against the CPU, since the CPU is so brain dead).
• Lots of potential for cool features such as achievements, where performing certain tasks gets more points (pre-multiplier). This is very difficult because achievements feel like something that should be moddable, yet we'd need to be able to approve achievements to prevent people from creating mods that have easy to obtain achievements that give a ton of points. Alternatively, achievements would be mod-neutral and be dependent on things like killing multiple enemies in a short period of time, killing enemies with a variety of different attacks (ie, using a variance of attacks), or killing enemies with an effective attack type for the target's armor type.
• Rank size and number of points required to reach is is going to depend heavily on the kinds of scores players easily get. Eyeballing past games, it looks like around 20,000 points is common for winners of medium length games. Something like 20,000 * 1.5^{rank + 1} creates a nice curve for 10 ranks. That creates an achievable first rank for new players. First rank needs 60,000, which is only 2 wins for a good player in medium length games (recall that wins get double points), but more for a novice -- new players will probably have multipliers due to their low rank, though. Achieving the top rank (rank 10) needs 1,729,951 points (about 45 wins at 20,000 game points per win).
• However, having such small ranks would inflate the rank difference multipliers. Perhaps better to have fewer large ranks. Perhaps also increase the loss penalty so that you have to win to rank up (and thus must be a good player to get a higher rank).
• Perhaps size difference should use a multiplier and not add a percentage to our running multiplier.
• Penalty/bonus from having AI teammates seems too severe.

83

Closed feature requests / Re: health bars (old topic relaunch!)

« on: 30 October 2014, 11:19:26 »

I strongly disagree with the health bars being a mod feature. This should be a PLAYER feature. Players would choose whether or not to display the health bar and its appearance.

This whole thread illustrated that we cannot agree on how to show health! Forcing players to use one system is a bad idea. Let them choose which they prefer.

Being a mod level change is also a major limitation because I suspect many modders won't make the change, and thus nobody can use the feature (since you can't just add it in yourself, as that breaks multiplayer support).

I would put these values in the INI, and the visibility should be in the in-game settings.

84

Closed feature requests / Re: health bars (old topic relaunch!)

« on: 28 October 2014, 13:29:48 »

The ability to toggle the health bars with a hotkey would be great for usability. The bars are very useful, but they're quite cluttering when you don't need them. Although the modes that Titi mentioned also helps with this (particularly the ability to only show the health bar when the bar is not full.

85

Closed bug reports / Re: unhandled error

« on: 4 October 2014, 05:01:02 »

There isn't really enough information here. Have you read the "how to report bugs" post?

Exactly what are the circumstances leading up to the error? Is there any console output?

86

Closed feature requests / Re: [DONE] particles for tileset models

« on: 29 August 2014, 04:55:00 »

Although I think that alket is referring to animated ground textures. I think this would have very limited usefulness. However, if ever implemented, GIFs are probably a bad idea. They're limited to 256 colors, which hinders quality (although might not be a big issue since ground textures tend to use a small number of similar colors). More for consistency than quality, animated ground textures could be implemented like water textures currently are.

But again, I'm not sure how useful these would be. It seems like proper use of animated objects and particles for those objects, combined with tileset fog would be better looking.

87

MegaGlest / Re: MG Launcher/Lobby

« on: 23 August 2014, 01:57:27 »

For games I plan to get the CSV file format from play.mg (which for the moment I can't find)

I wasn't aware that there was one. The desktop notifications feature that I wrote for play.mg uses JSON.  Use this URL: http://play.mg/showServersJson.php.  For parsing JSON with Python, see here.

You might also want to consider taking a look at the desktop notifications script. It automatically recreates the table you see on play.mg and creates desktop notifications (so includes a means of detecting new games). You could use similar functionality in your launcher.

To check for the current version of MegaGlest, consider using GitHub's API. Here's how to get release data. Here's the exact URL you'd have to use to access release data: https://api.github.com/repos/MegaGlest/megaglest-source/releases. Note that it's in ascending chronological order. While it technically does include the binaries that get bundled with each release, not every release has every binary, so users would probably need to manually install. Also, it looks like Softcoder released 3.9.2 on Github, but that's not the version on the forum or MegaGlest site (and the release has no binaries).

If you have questions about the masterserver API, let me know and I may be able to help.

EDIT: Obviously the mentioned limitation of using Github's API would prevent the launcher from installing updates automatically. Unfortunately, the INI file that you posted would have major limitations of its own, namely the inability to maintain platform independence (speaking of which, platform independence is why I love using languages like Java or Python over C++). You could work around this, but there's no trivial solution. Possibilities include:

• You could convince the MG devs to make their releases consistent. Have every release (on Github) have bundled executables that have a specific naming format. It looks like they already partially do this, but not entirely. You could try this and if there's no bundled executable, then tell the user they have to manually download and give them a link to the release (although this will fail hard for things like this 3.9.2 issue, where the release doesn't seem to be official).
• You could store these binaries on your own server. Gives you full control, but you'd have to have storage and bandwidth. You'd also have to do extra work on every release (whereas with #1, all the work is stuff that normally is done on every release, anyway).
• The solution that always works: interact with git and download the source code for that release and compile it locally. You'll never have to worry about the release not having bundled executables, since you make your own executables. The downside is that compiling MG can be a pain in the ass, sometimes. You'd need a way to get the dependencies (the Windows dependencies are huge). Windows and Linux currently have different methods of compiling. The first time downloading everything would be very slow, but after that, updates would be very fast. Much, much faster than downloading everything. Some programs take this approach to downloading stuff. Off the top of my head, OS X's Homebrew does this, downloading sources and building them locally instead of downloading prebuilt binaries.

Each of these has pros and cons. #1 is the easiest to implement, but requires depending on the MG team to change their process and stick to it. If they screw up, your program also gets screwed up. #2 is expensive, as you need your own server. #3 is probably the safest approach, but by far the most difficult (not to mention the very slow initial downloading of dependencies and the git repo).

88

Off topic / Re: Great linux games

« on: 22 August 2014, 06:41:59 »

Let's not forget Steam games. Civilization V is worth every penny. I've put more than 350 hours into that game since launch. It's a turn based strategy where you create your own civilization and compete against others (eg, throwing the world into a nuclear war or coming out as the culturally superior civilization). Fantastic replay potential.

Portal and Portal 2 are also amazing games. They're puzzle games. The second is hilarious.

Half Life 2 has aged a bit. At its release date, it was widely touted as the best game ever made. Now its mechanics have been used by so many other games that it's just "good". Still very enjoyable, if overhyped.

The Witcher 2 is a live action RPG. It's a mature game with a solid story line. The story line branches out heavily. As in, the entire story is totally different (different sides, different locations, etc) based on a few choices that you make at points of the game. As a result, it takes multiple play throughs to see all the possible choices. Note that it's very computationally intensive. An open world sequel is coming out, soon, too.

And then there's various games that I haven't played that have strong reputations, such as Team Fortress 2 (multiplayer FPS), Left 4 Dead 2 (similar, but with zombies), CounterStrike (another multiplayer FPS), and Europa Universalis IV (strategy game that is supposed to have some of the largest time investments by players).

Linux's library pales compared to the Windows roster, but still some great games. And hopefully as Steam gets more popular on Linux, we can expect to see more developers porting their games.

89

MegaGlest / Re: Managing MegaGlest's code

« on: 10 August 2014, 16:55:11 »

I hope I don’t break git when I pull omega’s commits for this.

My documentation changes are in the master, now. I recommend that you follow the same style of documentation (Javadoc style with Doxygen). It's fairly readable in the source code and produces useful documentation when combined with the Doxygen tool.

For refactoring methods I would use tools like ack to find out where this method gets called and fix them.

As an aside, an IDE's "call hierarchy" feature will usually do a better job at this (as it actually parsed the files rather than blindly searching). With Eclipse, the call hierarchy is very fast due to how Eclipse indexes the files. Most IDEs should have a feature like this (although some, such as MSVS 2010, are incredibly slow and possibly inaccurate).

I also used many pointers in my editor’s classes, but mainly because I did not understand how to get a new instance of a class without a pointer. But will do better in future code.

If you're interested, here's a relevant SO question and here's a portion of Stroustrup's C++ book that deal with RAII and its benefits.

For formatting I would suggest:

4 spaces indentation
80 characters
trying to split methods if they exceed 80 lines

I would disagree slightly. I'd like to suggest:

• Tabs for indentation (allow adjustable indentation levels; removes argument about size of indentation). Spaces can be used for alignment after indentation is done. Tabs should *never* be used for alignment, as they have variable width and in some editors, tabs indent to the next tab stop level while in others, they indent a set width. Although frankly, anything's better than mixing tabs and spaces on the same line...
• When wrapping lines, indent the wrapped line with 2 tabs.
• 100 character widths. 80 characters seems too small, and the majority of screens I've seen in recent years can easily fit 100 characters, even with IDE windows. More than that is probably a bad idea, though, as we'd want to avoid horizontal scrolling.
• Stroustrup style indentation and braces. We're already mostly following this, but are inconsistent in a few places and the spacing is extremely inconsistent.
• Space between all binary operators. That is, foo = x + 1 instead of foo=x +1 (etc).
• In conditionals, don't compare a boolean to true or false. ie, use if (foo) instead of if (foo == true)

I'd also like to suggest the following non-formatting changes:

• Stop using C style strings. That means no printf. Mostly to avoid mixing C and C++ style strings (and IMO, C style strings need to burn in hell)
• Those places with 10 indentation levels? They need to be split up or other wise refactored. You won't even be able to wrap these without them going off the screen.
• Remove all the commented out code. It's already in the repo if anyone ever needs it. I suspect a great deal of it will never even be looked at, though. As it is, it's just cluttering things up. The author didn't even mention why it's commented out. The code may also be buggy or outdated.
• Prefer to qualify std members with their full namespace. Eg, std::vector instead of just vector.
  

Here's an example that just shows the formatting. ---> represents a tab while · represents a space.

Code: [Select]

/**
·*·Does·some·cool·thing.·More·details.·Yet·more·details.
·*·@param·foo·Some·foo.·Details...
·*·@param·bar·Some·bar.·Details...
·*·@return·Some·non-sense·because·I·wanted·to·demonstrate·all·the·formatting·points.·Oh,·and·this
·*·line·is·approx·100·characters·long.
·*/
int·someFunction(Foo·foo,·Bar·bar)·{
--->if·(foo·==·bar)·{
--->--->std::cout·<<·foo.getName()·<<·"·equals·"·<<·bar.getName();
--->}
--->else·if·(foo.thisLineIsVeryLong()·<·bar.toShowLineWrapping()·&&·foo.hasTehCodez·&&
--->--->--->!bar.shouldDefinitelyBeFalse())·{
--->--->//·...
--->}

--->return·foo.shimShimmyShoo(bar);
}

//·Stuff·that's·aligned·--·I·actually·dislike·aligning,·though
int·getMeaningOfLife()···················{·return·meaningOfLife;·}
void·setMeaningOfLife(int·meaningOfLife)·{·this->meaningOfLife·=·meaningOfLife;·}

90

MegaGlest / Re: lua function unitName broken ?

« on: 9 August 2014, 21:24:30 »

As an aside, if we are using two functions (or have some optional boolean parameter that specifies whether to translate), then I think the current unitName should *probably* be the untranslated value, simply to fix any scenarios that might have been broken and gone unnoticed. Although I'm not sure if there are any such scenarios. If there is, though, it'd probably using the old behaviour could fix broken scenarios, while the worst case for it would be printing out a non-translated name when a translated name is expected.

91

MegaGlest / Re: lua function unitName broken ?

« on: 7 August 2014, 21:42:15 »

Yes, that seems to be broken. It was changed by softcoder in 0ead6a36. As an aside, git blame makes it easy to figure out where a specific line of code changed.

Here's the relevant function:

Code: [Select]

const string World::getUnitName(int unitId) {
Unit* unit= findUnitById(unitId);
if(unit == NULL) {
throw megaglest_runtime_error("Can not find Faction unit to get position unitId = " + intToStr(unitId),true);
}
return unit->getFullName(game->showTranslatedTechTree());
}
This is what it used to be:

Code: [Select]

const string World::getUnitName(int unitId) {
Unit* unit= findUnitById(unitId);
if(unit == NULL) {
throw megaglest_runtime_error("Can not find Faction unit to get position unitId = " + intToStr(unitId),true);
}
return unit->getFullName();
}
As an aside, I haven't checked if the function is used elsewhere.

This is probably unintentional, since it prevents easy checking for what unit an ID corresponds to (eg, what type was the last unit that died?). Not to mention most of the changes in the revision in question are using the non-translated versions. However, I do think we need some way to get the translated value for output (since scenarios can be translated).

92

MegaGlest / Re: Forsaken project (maybe)

« on: 7 August 2014, 03:48:24 »

https://github.com/MegaGlest/megaglest-source/graphs/contributors 37 commits on develop since 23rd March

If you count the pull requests that aren't yet in the repo, there's another 28 commits.

93

Closed feature requests / Re: particle acceleration

« on: 5 August 2014, 18:00:39 »

Ah, I see what you mean now. I was assuming attack projectiles, not unit particles (any chance we could see both?). Looks good.

94

Feature requests / Re: Non selectable non commandable uints

« on: 5 August 2014, 02:37:19 »

Some interesting examples for non-commandable units, but I disagree with all the uses of  non-selectable. In all those cases, I'd argue that the unit should still be selectable, otherwise there's no way to view the unit's health. And making them non-selectable seems very inconsistent when we consider that even resources are selectable.

95

Feature requests / Re: Rename attack boosts

« on: 4 August 2014, 18:16:48 »

So, titi, softcoder, can we rename them? If desired, I can make this change.

What I would do is make "aura" (since that seems to be a term we can agree on) an alias to attack-boost (in the same way that attack-strenght and attack-strength are aliases). I'd then rename AttackBoost to Aura. Do a grep for various combinations of attack boost and rename them appropriately (so that the code is consistent in naming things).

Once the change is in a release, we can rename the term in our documentation and declare attack-boost as depreciated. As an aside, I'm thinking that the --validate-* functionalities should warn about depreciated elements (not sure if they already do).

Note that this will create conflicts between any awaiting changes that modify attack boosts. So my tags change would have to be integrated first (possibly others?).

96

Feature requests / Re: Non selectable non commandable uints

« on: 4 August 2014, 18:08:05 »

In such a case, why even have commands on that unit?

Have you played the storming scenario? I'm pretty sure that it's in all engines, since it was one of the last additions to vanilla Glest before development stopped. In that scenario, you have to accompany a summoner around the map. If the summoner dies, game over. In order to make things difficult, the summoner moves on her own and you must guard her. But that would be too easy if you could control the summoner (just make her sit in a safe place).

The solution that the original Glest devs used was to make the summoner belong to an allied faction (thus preventing you from issuing commands from her). Making a unit non-commandable would allow this to be done without using a new faction.

Only complaint is that as a unit property, you'd have to create an entirely new unit to use this in scenarios (which is totally doable if you use a custom techtree/faction, but not so doable if you want to use someone else's techtree/faction). I was able to do this in military (several units only appeared in scenarios) since I had full control over the techtree. But a scenario for MG won't be able to modify the MegaPack without requiring a new version of the game (or a MegaPack clone, etc).

So setting a unit non-commandable would probably better as a Lua command.

Although that's assuming that scenarios are the only reason to set a unit non-commandable (but I can't think of any others).

97

Feature requests / Re: Tags

« on: 4 August 2014, 17:59:47 »

Done! Tags are working as expected. Rather than repeat myself, please see the pull request here. It details everything you need to know about tags, including syntax and translating.

How does saving work in MegaGlest? I spent a lot of time modifying GAE's save and I wonder if GAE and MG do it in the same way.

It dumps pretty much everything you'd need to know about the game state (eg, list of all units, stats that they have at a given time, etc) into an XML. When loading the game, that XML is read to determine what to load (eg, what units to load, their stats, etc). It largely works in a hierarchy, having factions call load methods of units, units call load methods of attack boosts, etc. The code is very messy, though. There's a great deal of commented out code. I think that's mostly because who ever implemented the save/load feature realized they don't have to save everything. Upgrade types aren't saved or loaded, for example, since they can't be changed in game, so can be loaded from the faction (although the upgrade manager and its list of in-progress/completed upgrades is saved/loaded).

EDIT: For the convenience of who ever has to merge this change, I added additional comments to explain design choices and places that aren't very clear in the diff. These are (as far as I know) only visible on GitHub.

EDIT2: For further convenience, I created a pull request for the megaglest-data change (just a single line in a language file).

98

Closed feature requests / Re: particle acceleration

« on: 4 August 2014, 16:22:01 »

The pull request says

For example with negative speed + spherical shape you can make very nice effects.

I'd like to see an example of exactly what this looks like, because I'm having difficulty imagining it.

As for other use cases, attacks that shoot rockets might look interesting with acceleration. I think for really long range attacks, though (the thing I have in mind is the nuclear missile that I previously implemented in Military, which was able to target anywhere on the map), we'd need a way to specify the maximum speed, so that the projectile won't accelerate too fast. Rather, it'd start slow and eventually reach a max speed (very much like a real missile).

99

Feature requests / Re: Non selectable non commandable uints

« on: 4 August 2014, 16:16:57 »

Non-commandable would be useful for scenarios. The normal approach (as used by the Storming scenario) is to use units in an allied faction. This would remove the need to use an allied unit (which is kind of confusing and removes a faction).

I'm not sure about use cases for non-selectable though.

100

Feature requests / Re: Tags

« on: 4 August 2014, 13:48:06 »

Hey Yggdrasil, long time, no see. Anyway, thank you for your reply. That worked perfectly. While I knew about passing by reference and value, I did not know that return types had similar semantics. The code is now working as expected.

Anyway, now that that's working as expected, I just a have a few things related to tags that I need to finish up. I need to verify that saving and loading the game works as expected, I want to refactor AttackBoost::isAffected (it has a horrible amount of code clones), and I want to make tags translatable (in the same manner as the rest of the techtrees).

EDIT: This makes me realize that there's a number of other places where we return a copy to a vector instead of a reference. They haven't been caught because they didn't use iterators like I did, but pose a threat creating of future bugs. Might be worth taking the time to convert these.