Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Omega

Pages: 1 2 3 4 5 [6] 7 8 9 10
126
Feature requests / Attacking a Position
« on: 11 December 2010, 06:31:55 »
Feature Request: tag to allow an attack to attack a position, not an actual unit. While useless for melee, it would be highly useful for long range splash attacks, particularily Military's nuke, which is difficult to use since you must first send a scout to the enemy base so you can target the base (unless Fog of War is off). This would mean you could use said attacks easier, and could strategically "time" your attack so it will hit an area when an enemy is passing through, etc;

The concept is simple: The attack command works the same as any other, but instead of clicking a unit to attack, you click an area on the map, which the unit will unleash its attack upon. Damage would be dealt on impact, so if a unit moves into that area, they can be damaged, while if they move away, they can escape the damage.

Pros: Easier to use long range attacks, improved gameplay
Cons: You tell me ;)

127
Question: Which of the two is your favorite to use for everyday usage and/or modding? Please give REASONS FOR YOUR ANSWER. Don't just state your favorite (the reason why there's no poll), but defend that reason.

Important rule to note is not to attack the other people's opinions on their favorite. This is a question to determine the community's preferences, not to split the community into those favorites.



I'll begin. I prefer GAE because it has many more features for modding which I've come to depend upon, a better UI, improved pathfinding, and features like autoreturn.

128
Sorry if this has already been fixed, but seeing how little used effects are and that I've heard no mention of it, I assume not, and it is a bug in 0.3. As the title explains, effects cannot bring regeneration past zero (aka: no regen). In short, you cannot use effects to create negative hp regeneration, which would be used to create HP draining, sapping health, poison, injuries, etc etc.

This is one effect tag is even used in an example on the wiki (worth mentioning the wiki's examples are outdated and things like "movement-speed" need to be changed to "move-speed" and so on...

Also worth noting that you can reduce HP regen if it's already over zero, but you can't make it a negative number. (ie: an effect that gives -50 HP regen that affects a unit with 3 HP regen will end up with no HP regen instead of the -47 it should be).

129
Feature requests / Request: Config dir also in the INI
« on: 20 November 2010, 01:02:51 »
GAE 0.3 introduced the config directory, a location for addons and the like for users who may not have access to the normal directories of Glest. Currently, this can only be set as a parameter when running the program (from a shortcut).

I propose (and, to be honest, beg) that the INI can have the same setting, as well as a setting for the "start in" directory (the reason why a shortcut has to be used. Not sure if this was fixed or not). What would happen is the INI would also have a setting, which, by default, would not exist, but can be created, which will have the relative path to the config directory. The purpose of this is to facilitate mods that require changes to the config directory. If the program was started with an attribute for the config directory being passed in, it will use that one over the INI setting, but if nothing was passed to the program on startup, it would use the INI setting, thus, people who don't have access to the install directory can still set a config directory by changing it by passing the parameter to the program (such as with a shortcut or command line).

There are no cons to this, as it will not change the default distribution. It is also a very minor change, but one that will solve a LOT of problems for me with cross platform distribution, and that will carry on to making it easier to install cross platform-wise.

Relatedly, if the "run in" shortcut parameter (windows, unsure of linux equivalent) could also be moved to the INI, that would ensure we would no longer HAVE to use shortcuts to run the game.

EDIT:// I forgot that the INI is stored in the config dir, so there'd also have to be a generic INI available in the install directory itself for the initial run.

130
I noticed that the hold position ("attack_stopped") command seems to be broken in the latest stable version (0.3.1). I'm not sure if hold position is even working at all, to be honest... Though for certain, I can notice that it's not playing the animation it should be for hold position, as most of my units have unique models for said command.

131
In 0.3.1, the effects aren't seeming to work. In my tests, I had an attack that set a negative value for the HP regen, but the effect was never applied (despite 100% chance of applying). I don't think the problem is in my XML, as I've tested said XMLs before, and even tried a copy-paste from the wiki. Seems to me that the effects simply won't apply to the units...

Also, relatedly, there is an extra line (which is blank, except for that odd bullet character that appears on the effect menu when you hover over the attack button). I have an image that details exactly what I mean, and will post it when I get home (sorry, school computers) along with the XML.

EDIT// Here's the image of what I am describing:

132
Off topic / Another View on Gaming Piracy
« on: 22 October 2010, 22:06:57 »
This was posted on the 0AD forums, and I found it quite interesting...
http://www.wildfiregames.com/forum/index.php?showtopic=13065



We've been hearing a lot about game piracy recently, with big developers inflicting draconian online-only DRM systems on their users, and blaming their declining PC game sales entirely on piracy. I'm not questioning that piracy is common, since even honest, DRM-free, indie developers like 2DBoy[1] report a 90% piracy rate. I am, however, questioning what this means. How much revenue are developers actually losing to piracy?

The common industry assumption is that developers are losing 90% of their revenue. That is, pirates would have bought every single game that they downloaded. From personal experience, I know this is not possible -- most pirates that I've met have downloaded enough software to exceed their entire lifetime income, were they to have paid for it all. A more plausible (but still overly optimistic) guess is that if piracy was stopped the average pirate would behave like an average consumer.

This means that to calculate the worst-case scenario of how much money is lost to piracy, we just need to figure out what percentage of the target market consists of pirates. For example, if 50% of the market is pirates, that means that it's possible that you've lost 50% of your revenue to piracy. So how do we calculate what percentage of the market consists of pirates? Do we just go with 90%?

iPhone piracy

iPhone game developers have also found that around 80% of their users are running pirated copies of their game (using jailbroken phones) [2] This immediately struck me as odd -- I suspected that most iPhone users had never even heard of 'jailbreaking'. I did a bit more research and found that my intuition was correct -- only 5% of iPhones in the US are jailbroken. [3] World-wide, the jailbreak statistics are highest in poor countries -- but, unsurprisingly, iPhones are also much less common there. The highest estimate I've seen is that 10% of worldwide iPhones are jailbroken. Given that there are so few jailbroken phones, how can we explain that 80% of game copies are pirated?

The answer is simple -- the average pirate downloads a lot more games than the average customer buys. This means that even though games see that 80% of their copies are pirated, only 10% of their potential customers are pirates, which means they are losing at most 10% of their sales. If you'd like to see an example with math, read the following paragraph. If word problems make your eyes glaze over, then I advise you to skip it.

Let's consider the following scenario. Because game pirates can get apps for free, they download a couple new games every day -- or about 500 games in a year. On the other hand, normal gamers tend to play the same game for a longer time -- buying an average of 5 games per year. If this seems low to you, then consider that you are also reading a post on an indie game developer blog. You are probably more hardcore than the average gamer. Anyway, given these statistics, if the market consists of 10 million gamers, then there are 500 million pirated game copies, and 90 million purchased game copies, From the perspective of every individual game, 80% of its users are using pirated copies. However, only 10% of the market consists of pirates.

PC game piracy

Does this also apply to PC (Windows/Mac/Linux) gamers? Many PC game developers find that about 90% of their users are running pirated copies -- does this mean that piracy is killing PC games? Let's try our alternative explanation, and see if these statistics are possible even if only 20% of worldwide PC gamers are pirates. The average PC gamer worldwide only buys about three games a year, and plays them for a long time [4]. I buy many more than that, and you probably do too, but again, we are not average gamers! On the other hand, game pirates might download a new game every few days, for a total of about 125 games a year. Given these numbers, games would see 90% piracy rates even though only 20% of gamers are pirates.

Are these numbers accurate? The NPD recently conducted an anonymous survey showing that only 4% of PC gamers in the US admit to pirating games [5], a number that is comparable to XBox 360 piracy statistics [6] . However, since piracy is inversely proportionate to per-capita GDP, we can expect piracy rates to increase dramatically in places like Russia, China and India, driving up the world-wide average. Let's say to 20%.

This means that if all pirates would otherwise buy as many games as the average consumer, then game developers would be losing 20% of their revenue to piracy.

But would pirates really buy games?

Anecdotally and from studies by companies like the BSA, it's clear that pirates for the most part have very little income. They are unemployed students, or live in countries with very low per-capita GDP, where the price of a $60 game is more like $1000 (in terms of purchasing power parity and income percentage). When Reflexive games performed a series of experiments with anti-piracy measures, they found that they only made one extra sale for every 1000 pirated copies they blocked [7]. This implies that their 90% piracy statistic caused them to lose less than 1% of their sales.

Why are PC games really losing sales?

While many game developers blame piracy for their decreasing PC game sales, it is clear that this is not the problem -- relatively few gamers are pirates, and those that are would mostly not be able to afford games anyway.

However, it's easier for these developers to point their fingers at pirates than to face the real problem: that their games are not fun on PC. The games in question are usually designed for consoles, with the desktop port as an afterthought. This means they are not fun to play with a mouse and keyboard, and don't work well on PC hardware. Their field of view is designed to be viewed from a distant couch instead of a nearby monitor, and their gameplay is simplified to compensate for this tunnel vision.

Blizzard is one of the most successful game developers in the world, and it develops exclusively for desktop computers. Why do they succeed where everyone else fails? They create games that are designed from the beginning to work well with the mouse and keyboard, and with all kinds of desktop hardware. If developers spent more time improving their PC gaming experience, and less time complaining about piracy, we might see more successful PC games.

With the Humble Indie Bundle promotion we've seen that when we treat gamers as real people instead of criminals, they seem to respond in kind. Anyone can get all five DRM-free games for a single penny, and pirate them as much as they want -- we have no way to find out or stop it. However, in just the first two days, we have over 40,000 contributions with an average of $8 each! Would we have seen this much support if the games were console ports that only worked when connected to a secure online DRM server? We'll never know for sure, but somehow I doubt it.

133
Feature requests / Random Faction/Tileset/Map
« on: 22 October 2010, 20:39:35 »
Once upon a time, GAE was the first to have a "Random" option for factions, but that seems to have been removed... I think that it should be reimplimented, along with a Random option for Tilesets and Maps (not a randomly created map, randomly picking a map from installed maps). HOWEVER, if there's only 1 item in that options menu, the random option should not be displayed. For example, the Military tech tree has only the Military faction, and thus, it should only display Military in the faction choices (as displaying "random" is pointless, since there's only one choice).

134
Feature requests / Improved Shadows
« on: 22 October 2010, 20:32:39 »
Glest has basic shadows, but they have much room for expansion. Shadows are cut off at certain angles, and shadows sometimes change when you move the camera. In short, the rendering area of the shadows, and the models in this area (and their effect on the shadows) would have to be increased. The shadow mapping could also use improvement, as though it has potential, its shadows are very blocky.

Like my water suggestion, this is very low priority, but is yet another pretty graphical enhancement.

135
Feature requests / Improved Water
« on: 22 October 2010, 20:30:30 »
Yes, this is a massive graphical thing, and low priority (1.0?) but certainly would look very nice on the long run. Something similar to 0AD's water, as seen here would be nice. We notice it has reflections, ripples, modified by light, etc. Overally, it would be very difficult (no clue how 0AD's water is done), but the effect is nothing short of breathtaking. :)

136
General discussion / BUG: In game chat broken
« on: 21 October 2010, 01:46:10 »
In game chat (either team or all) seems to be broken. The text simply doesn't appear. As well, when you "send" a message, then open the chat box again, the message is still in the chat box, instead of it being empty as it should be.

137
Feature requests / Campaigns (yes, campaigns)
« on: 21 October 2010, 00:12:12 »
Amazingly, when I curiously went to see when campaigns (aka: extended scenarios) could become a reality in GAE, I was surprised to see that one of the most requested features was not even in the tracker!

Now, to define a campaign, I refer to a string of scenarios that must be played in order, usually telling a story. For example, The series of 5 scenarios in Military, the End of Morning series, is technically a campaign, though there's no way to keep them in order, and a true campaign would work as though it were 5 scenarios moulded into one. This would be beneficial for GAE, and would most likely be done by an extra folder. For example, from the scenarios directory, we might have a new scenario category (ie: campaigns).
Sample code for the campaign XML:
Code: [Select]
./scenarios/campaigns/my_campaign/my_campaign.xmlThe XML file would describe a few simple settings, primarily the scenarios that have to be played (possibly other things, such as the action for when the player dies, whether to restart the current scenario or reset from scenario 1). From there, there would be a folder for each scenario, which would just be a normal scenario folder. When you finish the scenario, you'd "unlock" the next one. Security isn't a deal at all, and for simplicity and testing purposes, the "location" in each scenario could be stored in a separate ini, etc;
Sample code for scenario paths:
Code: [Select]
./scenarios/campaigns/my_campaign/my_campaign.xml
                                 /scenario1/scenario1.xml
                                 /scenario2/scenario2.xml
                                 etc...

This method for a campaign would ensure that as little changes as possible would be necessary, and, more importantly, remind everyone of a common feature request that has been nearly forgotten about! :)

138
Feature requests / Scenario Background Images (From MG)
« on: 20 October 2010, 23:59:55 »
I noticed when I tested the latest MG, that one scenario (one of the beginner ones) had an image in its folder. Curious what it was, I realized that it was an "override" for the background image displayed on the loading screen. In this case, it was simply used to show where the enemy camp was, so to make the game easier for the new player. I think GAE should impliment this feature, since it could be very useful for both purpose and for looks. For example, a tutorial might use it in a way similar to that MG scenario, or, more specifically, a campaign scenario such as Military's End of Morning series.

While it's not priority, the code to display background images for the loading screen already exists, and MG has done this already, should a reference be required. The usage is mostly visual, but does have some practical uses as mentioned above.

139
While unit particle effects work fine on units (ie: the spirits in Wciows beta of his undead mod or the Indian's fire golem), they don't seem to be working for the deaths. The particle effect simply isn't displayed... For example, start a game with the indians, kill their tipi, and compare that in MegaGlest and GAE.

Relatedly, units that are created without moving don't start with particles until they move (such as those made with Lua or as a starting unit).

140
Feature requests / MegaGlest Lau Commands
« on: 10 October 2010, 02:02:51 »
GAE would greatly benefit from the implimentation of the following Lau commands, which are now in megaglest.

void enableAi(factionindex)
void disableHunger(factionindex)
void enableHunger(factionindex)
bool getAiEnabled(factionindex)
bool getHungerEnabled(factionindex)
void startPerformanceTimer()
void endPerformanceTimer()
Vec2i getPerformanceTimerResults()   (returns a 2D int array, item #1 is avg updateFps, #2 is avg RenderFps)
void DisplayFormattedText(format, ...)   (prints a message using printf style formatting and NOT using language files)

(Filtered out new commands that already have a GAE alternative, though, for compatability, they could perhaps be implimented too. It would certainly be nice if MG stuff also works in GAE  ;))

Full list and associated MG topic found here

141
Forum discussion / SMF 2.0 - First Looks
« on: 8 October 2010, 18:53:59 »
Well, taking a look at SMF 2.0 RC3, I'm quite impressed. While it works pretty similar on the everyday-user end, it features a lot of great enhancements on the configuration end, since it has built in security such as spam detection, has warnings when posting on very old topics, can send newsletters, has dropdown menus, a slightly spiffier navigation and improved moderation tools (including an effective warning system) among many others! Of course, there are also a few problems:
-The theme is incompatable. Fortunately, a core theme which is similar to the Glest Board's original theme (the blue one) is available, and I will make a Glest theme from it from scratch. The Glest 2.4 theme was too messy anyway and had a lot of unnecessary files thrown in...
-Some mods may be incompatable. I only could test what I had on my computer, and most of those were downloaded before RC3 was even released, so probably have new versions. If not, I think I've gotten good enough to manually do it, but not sure how to do so when I don't have server access, only Admin access to the board itself. Of course, I can talk to martino about that, maybe one of the Glest team can help? Of course, that also brings the question of upgrading, which I haven't tested. I will very soon, though I only tried the full install. Now I'll load one of the Board backups on my computer and make a local copy of the board to test.

Biggest problem may be that I don't have the server password (well, technically, I can access it, but its encrypted, since the password is hidden in the settings page...) We'll have to see. No immediate plans to convert anywaty, at least not until I have the new theme ready.

142
Feature requests / Size of the back.tga File
« on: 30 September 2010, 01:38:54 »
The "back.tga" file (one of the menu textures, used for the background of the loading screens, etc) has always been a 1024x512 image, due to the "power of 2 restrictions". This means that the resolution is 2:1, and thus, we have to paste a stretched image in and let it stretch to the window, which would give poor quality. My proposal is to have the ability to create true sized images, such as one in a 4:3 ratio, the most common (ie: 1024x768, or 1200x900, etc;). Alternatively, it could be beneficial to have two images, one for wide screen resolutions (16:9) and one for standard resolutions (4:3). Not sure how wide screen stretches it at the moment...

If we maintain support for the current 1024x512 resolution, we break nothing, but open possibilities for higher quality images (stretching = image breaker) to ensure that the image looks as originally intended.

Also, for clarification, what exactly is with all the power of 2 limitations of Glest? Surely modern software has no trouble loading non-square images? I know that several modelling formats require them, but what about the ones that are always 2D, such as interface images?


143
Feature requests / More Language File Control
« on: 30 September 2010, 01:32:22 »
The Language file (which holds all the game's text strings) should hold more, particularily the version (very handy for times like in military, since its logo replaces the glest logo, but military isn't version 0.3....). As well, there's at least a few other strings that don't have a string in the language file, off the top of my head, I know one with the word "IP" in it on the join game menu isn't, since I tried to capitalize the word "IP" (Ip looks bad) but found it wasn't in the language file...

As well, another interesting thing might be the ability to add line breaks (\n) in the language files, such as, we might have the part of the intro screen which has the link to the Glest site, and we may change it to say "www.glest.org\nwww.yoursite.com", etc;

The second idea is a bit more complex (maybe?) but the first is very much doable and would be beneficial.

144
Feature requests / Discount Unit Cost Before Production
« on: 29 September 2010, 23:22:17 »
As you all probably know, the discount costs are always taken off AFTER the unit has been produced (ie: Unit costing 10 gold with 50% discount would still cost 10 gold, but would give you back 5 gold after the production is done). This is impractical, and it would be nice to either have it actually taken off of the production cost or given an XML option to have it taken off before production (for Legacy support?).

145
General discussion / Massive Lag on Screenshot
« on: 27 September 2010, 22:15:45 »
When taking a screenshot (default: 'e' key) on GAE 0.3, the game freezes for several seconds before resuming. It did not do this before, and usually was a very fast instant picture. The freezing, abet, temporary, interupts gameplay for several seconds.

No known ideas for cause, though it seemed to appear with every screenshot, regardless of where or the map used. (default 1024x768 resolution).

146
General discussion / AI vs Multiplayer
« on: 4 September 2010, 05:41:43 »
Quote from: Silnarm
  From an AI developers perspective there is little difference, the AI in GAE is in need of a revamp to handle all the new features, and I am planning such a revamp, but was going to work on improving the multiplayer first, though I'm now thinking this will probably be decided by a poll.

Since he hasn't yet, I figured I'd beat him to the punch so that the community can decide which would be more important to do FIRST (we can assume both will come in time, though obviously one must come first).



Personally, I would prefer to see the AI worked on, because it cannot use some of the new features, such as it won't build a unit with a water field, nor will it EVER use subfactions, among others. Unsure yet if it can use the carrier units that GAE 0.3 will offer. Regardless, the multiplayer works, but the AI is "broken" and thus, I think we would benefit more from that AI. Let's not go overboard immediately though. While things like Lua AI's are very tempting, they might be a bit too complex, and it may be better to just get a simple, working AI that can handle all the new features of GAE functionally.

147
As those with poor computers may know, the unit particle effects, which are always on and usually have lots of particles, can really lag up low-end computers. Dark magic, for example, is considering implimenting unit particle effects, though that would mean some users would be lagged up, leaving them to consider releasing two separate versions. My alternative is to have an option, found in the options menu, ini, and configurator, to choose whether or not these extra particles will be rendered.

All unit particle effects are really just optional, made so it looks good, so there's no real penalty (other than the eye candy) for not using these. Thus, I think the community can benefit from this option. It would make it easier for modders (no need to release a low-graphic version) and players (can choose as they like), making it a win-win. This only applies to unit particle effects, and NOT to particle proj's or particle splashes.

148
Feature requests / Read Me First
« on: 12 August 2010, 02:08:33 »
Ok, so you have some cool idea for GAE/MegaGlest. That's great, but thinking up an idea is only half the fight. Here's some general tips for helping getting your idea actually listened to.
Familiarise yourself with any previous discussion.

At the bottom of this post are a few of the most frequently posted ideas, so not to post them again.

Give your post a meaningful title.

If your idea is good, people will be hunting for your thread in months to come. A clear name ensures that they can find it!

Similarly, if a thread inspires a new idea that's only loosely related to the initial post, start a new thread. Months down the track no-one will find your nifty idea about simulating rock damage if it's located on page 3 of the "Catapault unit" thread!

Examples of clear and unclear thread titles:

Unclear: "Comments on my idea please?"
Clear: "Suggestion: Add Rock Effect to Catapult."

Unclear: "Fiery"
Clear: "New ability: Automatically deal damage over time when struck."

Unclear: "Some ideas"
Clear: <Individual threads with meaningful titles>

Propose a solution, not just a problem.

It's good to draw attention to areas where Glest can be improved. But proposing a solution up front means that people willl be discussing the solution rather than just the problem.

Okay: "Behemoths cost too much."
Better: "Behemoths seem to expensive for their abilities which are limited as their large size prevents proper path-finding and their attacks are geared towards buildings."

Suggest, don't demand.

Remember that Glest is developed by volunteers. They don't work for you, and if you speak to them like they do, they'll react poorly. Your goal is to show people how good and interesting idea your idea is so that they want to pursue it.

Bad: "The Behemoth's stats are just stupid! He needs to do more damage!".
Better: "I think it would be a good idea to give an advantage to the Behemoth over humanoids because [...]"

Give clear reasons why you think your idea should be implemented.

Bad: "Behemoths should have an extra attack."
Better: "The late-game Behemoth's stats are limited to buildings, something archmage's tend to do better against, thanks to their splash. The Behemoth's large size works against it, causing it to have trouble attacking. It needs a ranged attack such as throwing a rock to balance this out. This also puts it on par with its close cousin in the tech faction, the Battle Machine."

"Any new feature is by default bad. It's bad because it's more we have to write, and more importantly, more we have to maintain and test. We will only implement a feature if it solves some problem that we think is worse than the cost of adding the feature. If you don't tell us about this problem, then we might not notice it for ourselves, and we'll see your idea simply as being 'bad bad bad'."

Clearly state how your idea will work in practice.

Be specific. Numerous threads containing promising ideas have died because the posters weren't quite clear on what was being discussed.

Bad: "Mages should have an aura that damages attackers".
Good: "I propose adding a defensive flame aura to archmages. After each successful strike an opponent makes against the archmage, 20 points of fire damage is inflicted on that opponent. The fire attack would always hit, but would be affected by a unit's fire resistance as per normal.".

Consider and address your idea's weak points.

Consider reasons your idea might not be accepted. When you do this, occasionally you will realize that the idea should be discarded as unsuitable. But mostly it's just helpful to anticipate objections so that you can address them in your pitch.

eg. "My proposed flame aura ignores terrain and automatically affects units that are normally difficult to hit. I don't consider this a problem because: (a) it can't be used offensively, (b) it does very little damage per attack and (c) it's associated with a relatively weak unit with little health (archmage). This makes it a poor tool for offensive use to try and hit the well defended foes, because the foe's will be hitting much harder and thus taking out the archmage before it can deal much damage with its aura."

Show that you're willing to put your effort where your mouth is.

Bad: "Let's create a distinctive new race, unique to Glest!"
Good: "I suggest creating a distinctive new race, unique to Glest. Here's some unit art and stats I prepared to demonstrate the idea."

Use clear language.

This is an international forum where many of the regulars don't speak english as their first language. We don't expect perfect spelling and grammar. However, a good way to instantly alienate about 50% of your readers is to use 'leet' or 'txt' ("u shld make orcs more tuff"). Using words that are too flowery (superfluous magniloquence), slang ("I reckon he's telling porkies") or odd spellings ("prolly" instead of "probably") also make your post harder to understand. The goal is to have the reader understand your post and agree with it. If they have difficulty understanding your post, or find it annoying to read, they're a lot less likely to support your idea.

Revise.

Before you post have a quick reread. Is there anything that could be made clearer or less wordy? Have you assumed people know what you mean at any point?

Know when to let go.

Sometimes, despite your best efforts, people just don't agree with your idea. If you've reached a point where the community has made it clear they're not going to be convinced, let it go. No matter how good an idea is, if the community's opposed to including it, it's not going to happen.

If your idea is one that you can implement by yourself (eg. a custom multiplayer faction) and you feel strongly enough to do so, go for it; just don't expect it to be official. Once you've done some work on it, people might take a liking to it and chip in. Or they still might not.

That's it. Good luck!



Check out the tracker to see what's already been suggested: http://sourceforge.net/apps/trac/glestae/report/1

Common Suggestions:
  • Stealth Units
  • Carrying Units
  • "Smart" AI
  • Mod Downloader

149
Feature requests / Read Me First
« on: 12 August 2010, 01:37:07 »
Ok, so you have some cool idea for MegaGlest. That's great, but thinking up an idea is only half the fight. Here's some general tips for helping getting your idea actually listened to.
Familiarise yourself with any previous discussion.

At the bottom of this post are a few of the most frequently posted ideas, so not to post them again.

Give your post a meaningful title.

If your idea is good, people will be hunting for your thread in months to come. A clear name ensures that they can find it!

Similarly, if a thread inspires a new idea that's only loosely related to the initial post, start a new thread. Months down the track no-one will find your nifty idea about simulating rock damage if it's located on page 3 of the "Catapault unit" thread!

Examples of clear and unclear thread titles:

Unclear: "Comments on my idea please?"
Clear: "Suggestion: Add Rock Effect to Catapult."

Unclear: "Fiery"
Clear: "New ability: Automatically deal damage over time when struck."

Unclear: "Some ideas"
Clear: <Individual threads with meaningful titles>

Propose a solution, not just a problem.

It's good to draw attention to areas where Glest can be improved. But proposing a solution up front means that people willl be discussing the solution rather than just the problem.

Okay: "Behemoths cost too much."
Better: "Behemoths seem to expensive for their abilities which are limited as their large size prevents proper path-finding and their attacks are geared towards buildings."

Suggest, don't demand.

Remember that Glest is developed by volunteers. They don't work for you, and if you speak to them like they do, they'll react poorly. Your goal is to show people how good and interesting idea your idea is so that they want to pursue it.

Bad: "The Behemoth's stats are just stupid! He needs to do more damage!".
Better: "I think it would be a good idea to give an advantage to the Behemoth over humanoids because [...]"

Give clear reasons why you think your idea should be implemented.

Bad: "Behemoths should have an extra attack."
Better: "The late-game Behemoth's stats are limited to buildings, something archmage's tend to do better against, thanks to their splash. The Behemoth's large size works against it, causing it to have trouble attacking. It needs a ranged attack such as throwing a rock to balance this out. This also puts it on par with its close cousin in the tech faction, the Battle Machine."

"Any new feature is by default bad. It's bad because it's more we have to write, and more importantly, more we have to maintain and test. We will only implement a feature if it solves some problem that we think is worse than the cost of adding the feature. If you don't tell us about this problem, then we might not notice it for ourselves, and we'll see your idea simply as being 'bad bad bad'."

Clearly state how your idea will work in practice.

Be specific. Numerous threads containing promising ideas have died because the posters weren't quite clear on what was being discussed.

Bad: "Mages should have an aura that damages attackers".
Good: "I propose adding a defensive flame aura to archmages. After each successful strike an opponent makes against the archmage, 20 points of fire damage is inflicted on that opponent. The fire attack would always hit, but would be affected by a unit's fire resistance as per normal.".

Consider and address your idea's weak points.

Consider reasons your idea might not be accepted. When you do this, occasionally you will realize that the idea should be discarded as unsuitable. But mostly it's just helpful to anticipate objections so that you can address them in your pitch.

eg. "My proposed flame aura ignores terrain and automatically affects units that are normally difficult to hit. I don't consider this a problem because: (a) it can't be used offensively, (b) it does very little damage per attack and (c) it's associated with a relatively weak unit with little health (archmage). This makes it a poor tool for offensive use to try and hit the well defended foes, because the foe's will be hitting much harder and thus taking out the archmage before it can deal much damage with its aura."

Show that you're willing to put your effort where your mouth is.

Bad: "Let's create a distinctive new race, unique to Glest!"
Good: "I suggest creating a distinctive new race, unique to Glest. Here's some unit art and stats I prepared to demonstrate the idea."

Use clear language.

This is an international forum where many of the regulars don't speak english as their first language. We don't expect perfect spelling and grammar. However, a good way to instantly alienate about 50% of your readers is to use 'leet' or 'txt' ("u shld make orcs more tuff"). Using words that are too flowery (superfluous magniloquence), slang ("I reckon he's telling porkies") or odd spellings ("prolly" instead of "probably") also make your post harder to understand. The goal is to have the reader understand your post and agree with it. If they have difficulty understanding your post, or find it annoying to read, they're a lot less likely to support your idea.

Revise.

Before you post have a quick reread. Is there anything that could be made clearer or less wordy? Have you assumed people know what you mean at any point?

Know when to let go.

Sometimes, despite your best efforts, people just don't agree with your idea. If you've reached a point where the community has made it clear they're not going to be convinced, let it go. No matter how good an idea is, if the community's opposed to including it, it's not going to happen.

If your idea is one that you can implement by yourself (eg. a custom multiplayer faction) and you feel strongly enough to do so, go for it; just don't expect it to be official. Once you've done some work on it, people might take a liking to it and chip in. Or they still might not.

That's it. Good luck!



Check out the tracker to see what's already been suggested: http://sourceforge.net/tracker/?atid=1266779&group_id=300350&func=browse

Common Suggestions:
  • Stealth Units
  • Carrying Units
  • "Smart" AI
  • Mod Downloader

150
Bug report / Posting Errors: Guidelines
« on: 8 July 2010, 00:34:34 »
So Glest isn't working for you? This part of the board is only for Glest errors. GAE errors should be posted on the GAE board, MegaGlest errors on the MegaGlest Board, and mod errors in their appropriate thread. Bear in mind that the original Glest is NO LONGER in development, so please do not submit bugs in the game, nor suggestions, but most error codes given can be solved here.

When posting an error, we need information to be able to help you. Please don't just say "Glest crashed. What do I do?".

You should make sure you are on an up-to-date version of Glest (3.2.2) and have your graphics card at the newest version to see if Glest still has the error before posting here.

If the problem persists, then you should post detailed information about the error here. Be sure to include:
-Operating System (ie: windows, linux, mac)
-Graphics Card
-What you were doing
-General system stats (when appropriate)
-Normal resolution of the monitor
-If you've changed any settings in Glest, post that as well

*It's also a good idea to Search the board to make sure this hasn't been reported before. You can save both yourself and us a lot of time doing that.

Solutions to Common Errors:
Segementation Fault: This is a linux only error, generally caused either by bad case (such as being told to look for file a.bmp when it is really called A.bmp) or a bad executable. Check if the mod is certified to be linux compatible, or try to redownload/rebuild the executable. The linux board on the Glest Forums may also prove handy.

Map not a power of two: The map's dimensions are not a power of two (ie: 2, 4, 8, 16, 32, 64, 128, 256...). The map should be a perfect square, though vanilla glest does support having sides of different lengths as long as both are powers of two (but since GAE does not, you should always use perfect squares).

Error Opening Log File/Could not open INI File: The log file could not be opened, generally because of bad permission settings. For windows, either turn UAC off or right click the glest directory, choose properties > security > select all checkboxes for every user.

There is no lang file: No translation files could be found. Normally, glest should have English and spanish among others. If you see this error, redownload, since you are missing some files. May occur in GAE since the folder was moved.

Server and Client Versions do not match: If Network Consistency Checks are on, Glest will not play multiplayer cross Operating System. It generally should work, though may come out of sync and crash at any given time. Disable from the INI at your own risk!

Checksum error, you don't have the same data as the server: The techtree/map/etc that you are trying to play multiplayer with is not the same as the other player has. This is to prevent cheating by changing values. Simply make sure each player downloads from the same source and has the exact same files on both of their computers (which is why many people use a different glest for multiplayer).

[[Missing a common problem? Please post below!]]

Pages: 1 2 3 4 5 [6] 7 8 9 10