Topics

51

Feature requests / AI Improvement: Produce more powerful units

« on: 13 November 2011, 20:08:27 »

As mentioned in the Annex thread, the AI, even on Mega, generally produces swarms of weak early game units, rather rarely creating later game units, and when they do, they're generally much later than the human player. This doesn't make sense, since the AI is supposed to have more resources than us at those difficulty levels, so can afford to make these expensive units as well.

This becomes an issue in mods where the jump from early game to late game units becomes large. For example, if the early game primary attackers are rather weak and cheap, while several late game units become so strong that they are almost impervious to the early game units, the AI would be at a distinct disadvantage. Not to mention sending hords of weaker units means more kills for our stronger units, which levels them up and makes them even more overpowered against the AI. For the most part, most mods don't have such a huge difference in the stats of their units, but still offer a noticeable difference.

Ideally, in fact, an AI with a 2x multiplier should be able to always beat a human player in a game of flat out attacks. If the human is to defeat an enemy that outnumbers it 2:1, they should need more advanced tactics than just build all the best units. However, as it is, if you simply happen to be a smarter producer, it can count for a lot more than the extra numbers.

Compiling all the resources together, for the cost of one battlemachine (counting the cost of the technician), you can build 3 guards, but the battle machine is vastly superior in strength, health, and defense, so will defeat those three guards in regular combat. Not to mention it is far more effective against buildings, can attack air, and has a secondary ranged attack it can use while safely away from opponents.

This occurrence seems inconsistent around techtrees though, since an AI with tech will produce more battlemachines than an AI with annex would produce harriers, though they're still the same principal: late game units that make a huge difference.

I'm not saying that late game units aren't built, just that they're built far later and in far smaller quantities than a human player would if they had the resources the AI did (y humans no get resource multiplier???), and that the AI should be tweaked to improve on this.

52

General discussion / GAE and MegaGlest: Friends, not rivals

« on: 3 November 2011, 02:14:31 »

I'm sick of seeing people get hostile when GAE and MegaGlest are compared. They both stem from the same roots, they have their differences. One engine might do one thing better, while the other does another. The two engines have even worked together in the past; GAE members have added content to MegaGlest, and Tomreyn did a rash of bug testing for GAE. I don't see why this has to be some petty rivalry, when they can work together and cooperatively. Yes, everyone is welcome to have a preference, but it doesn't matter if you prefer GAE or MegaGlest if you care about both maxing out their potential.

For example, if someone requests a feature on MegaGlest, let's say they want a method of transports (storing a unit inside another unit). Someone might mention that GAE has this feature, and then might explain (or link to an explanation) of how it works there. This isn't meant to be in any way an attempt to fuel rivalry between the two engines. It's meant to ensure that should the feature be implemented in the lacking engine, it can use the same (or similar) syntax. If there's one thing I'm sure we can all agree on, it's that when it comes to modding options, doing the same thing different ways hurts modders.

As well, does it matter if someone immensely prefers one engine? Should they be banned from commenting on the other engine? There's no reason that just because someone prefers one thing over another, that they don't still approve of the other. For example, I prefer sour cream and onion chips over all dressed, but I still like all dressed chips. I can still eat them. I might not like them as much as sour cream and onion, but I still like them.

The bottom line to this message, is that lately people have been getting tense whenever someone mentions the other engine on their specific boards (such as in a feature request). I don't see GAE and MegaGlest as rivals. They share much of the same fan base, and are very alike, stemming from the same source. I see them as friends. When GAE is mentioned on the MegaGlest boards, people shouldn't be groaning. They should be noting the differences the engines have, so that both can be improved better. It's not just about GAE, nor is it just about MegaGlest. It's about both MegaGlest and GAE. Friends, not rivals.

53

General discussion / Discussion on Effects

« on: 31 October 2011, 22:17:58 »

What exactly is it that causes issues with a multiplier of zero? I'm assuming it's because in this example, the effect's stacking is set to stack? Would it be better overwrite/extend, or is this something entirely different?

54

General discussion / Differences in same-functions between the engines

« on: 1 October 2011, 21:28:46 »

There aren't many, and some steps have been taken to point out the MegaGlest and Glest Advanced Engine both have some functions that do the same thing, but using different code. This topic was inspired by John's post here, and hopes to list these functions that perform the same way, but using different syntax, purely in hopes that one engine (or both) will compromise. It will NOT be about deciding which is better, despite strong opinions, as that will not lead to any progress.

The way I see it, having functions that do the same thing but must be different for the modders makes it more complex (more to learn), requires more work when porting a mod from one engine to another, and is simply redundant. However, I don't think that the first to do so must necessarily be the way the engine's should implement same-features, as it's possible for one engine to have an inferior way of doing something, even if it was done first, and the later implementation on the other engine might be a better way to go. In such cases, the programmers should consider getting together and deciding what exactly to do, taking into account existing mods which may already use one system.

Finally, if implementing a new feature that an existing engine has, it should actually be a goal of the programmers to try and maintain compatibility by having the syntax the same as the other engine, unless you have some groundbreaking new idea that improves it greatly (simply a perceived "better" term to describe an XML value isn't enough). I don't expect programmers of one engine to necessarily know if the other engine has such a feature already; especially since they may not play that engine (much/at all), but if someone in the community points out "oh, the other engine has this feature and it works like...", it should be taken into consideration, even if yours was written from the ground up.


And now for the list of features that are shared in GAE and MegaGlest with different syntax. Please post below if any are missing and they will be added to the table.

Feature GAE Syntax MegaGlest Syntax Loading screen images <loading-screen>    <background-image path="loading-screen.png" /> </loading-screen> No XML tag; depends on an image named loading_screen.* to be present. Regions, events, and triggers registerRegion(name, area) registerEvent(name) setUnitTrigger(unitId, condition, event) setUnitTriggerX(unitId, condition, event, userData) setFactionTrigger(factionIndex, condition, event, userData) registerCellTriggerEventForUnitToUnit(sourceUnitId, destUnitId ) registerCellTriggerEventForUnitToLocation(sourceUnitId, Vec2i pos ) registerCellTriggerEventForFactionToUnit(sourceFactionId, destUnitId ) registerCellTriggerEventForFactionToLocation(sourceFactionId,Vec2i pos) getCellTriggerEventCount(eventId) unregisterCellTriggerEvent(eventId) triggeredCellEventId() Timers and related functions in scenarios setTimer(name, type, interval, periodic) stopTimer(name) <timer name="name"> </timer> startTimerEvent() resetTimerEvent(eventId) stopTimerEvent(eventId) timerEventSecondsElapsed(eventId) triggeredTimerEventId() Command queuing Shift + Click Control + Click

55

General discussion / Proposal: Change version numbering system

« on: 28 September 2011, 05:13:04 »

This may be a stupid proposal, but on the other hand, has use. Firstly, a follow-up; as it is, GAE started with totally new version numbering, starting at 0.1, working its way up to 0.3.2, the last stable release, with version 0.4 planned as the next release. However, the preceeding zero, in my opinion, makes it sound like its more of a beta and less of a fleshed out engine. Sure, GAE may not be as multiplayer stable as MegaGlest, but it's definitely not the buggy testing ground it started as, and has several mods specifically for it.

Thus, I propose that the leading zero be bumped off. Version 0.3.2 becomes version 3.2. The upcoming 0.4 will be version 4.0. Unless there's some easy way to do it, the trac and repository could remain unchanged (easy conversion), but when releasing it, or referring to GAE, we'd cut off that first number. It's by no means a major change, and virtually unrelated to the code (just the tiny reference to version numbering would have to be changed in the source).

It would have the advantage that new players would be less likely to think that GAE is some new engine or very unstable (when in truth it predates MegaGlest by years). It wouldn't need much adaption for the community either; I've seen many instances of people accidentally bumping off the first zero anyway.

56

Feature requests / Description value for Scenarios

« on: 26 September 2011, 18:45:57 »

It'd be nice if we could have a description of what the scenario is about in the XML/Language file, which would be displayed in the scenario mission, below the table displaying the faction, map, etc.

We'd have an element like <description value="my_description" /> in the XML which would refer to the string "my_description" in the language file for that scenario (to maintain translatability).

57

Bug reports / Reporting Bugs

« on: 6 September 2011, 20:15:10 »

Uh oh, something went wrong? Hey, mistakes happen, let's fix that. The first and arguably most important step in fixing a bug is reporting it (after all, how can we fix what we don't know about?). All bug reports in this board should be for GAE only. MegaGlest and Glest bugs have their own boards.

Guidelines

• All regular board rules apply here.
• Search existing bug reports first to see if it has been fixed. Also consider trying the latest git-master to see if it has been patched up without a report.
• Each bug report should be its own thread. Don't make lists of bugs, as then we easily will end up missing the bug report. If you have multiple bug reports, make multiple threads.
• Name each thread appropriately. Don't just say "BUG - GAE Crashed!!!". Be specific.
• In addition to naming the thread appropriately, be specific in your post. Tell exactly what happened to make the bug occur. If possible, give instructions on how to re-enact the bug. Images a huge help, as well.
• Include computer specs. Lots of bugs are related to your computer itself. When posting a bug report, also post your Operating System (eg, Windows 7), your graphics card (eg, AMD Radeon HD 4650), your RAM (eg, 4 GB), how much of that RAM is actually available before opening GAE, and your computer's max resolution (eg, 1920x1080).
• When a bug is solved, change the thread name to include [Fixed], so that developers can tell apart fixed bugs from active bugs.

If GAE isn't starting at all, consider checking if your graphic drivers are up-to-date. Outdated drivers can cause issues that cannot be fixed on our side.

58

Off topic / Worries about developers' privacy

« on: 6 September 2011, 03:54:13 »

Hmm, for someone so secretive, you seem to lack online security on other locations, Softcoder. I can see a picture from a (not accepted) friend request from Ultifd on Facebook, since you appear in his friends list. As well, on your personal site, linked from your facebook page, even contains your address in the contact page. If you're serious about security, you may wish to fix those up. Not trying to be creepy, just proving how one should expect anything (s)he posts online to be accessible to others. Plus, Facebook's security is laughable.

59

General discussion / Bugs child board?

« on: 4 September 2011, 22:57:52 »

Would the GAE team like a child board for bug reports like MG has?

60

Feature requests / Please add a mod translation system

« on: 3 September 2011, 06:27:18 »

[Edit (tomreyn): Since this is a feature request, I moved it here where feature requests belong. Omega's post responds to a post by softcoder.]

Actually, not all of those are "built in". Resources (eg, food) are mod specific, and could only be translated with a mod translation system, which does not exist in MegaGlest. Technically, you could create a mod in a different language (though don't expect many players unless you release multiple languages, as english is a majority language here, by far). Perhaps MG should consider implementing such a feature, as GAE has? In GAE, every command can be translated with the name parameter (eg, if your airship's attack command has the name value of "airship_attack", then in the faction language file, that's your keyword). As well, GAE lets all resources, unit names, level names, attack types, armor types, faction names, techtree names, etc be translated.

The translation also has a secondary purpose, as it allows tooltips (by adding the "tip" attribute to name elements), allows modders better control over casing (eg, MG cannot have a unit named "MIRV", as it will display as a very ugly "Mirv". Language files allow modders to fix this issue), allows modders to easily change the name of something without referencing it in a dozen places (eg, if you want to change the name of a unit, or perhaps fix some spelling in its name, you change ONE value in the language file instead of changing every instance it appears in the XMLs), and also allows others to expand translations to your mods (if you release a full english translation, even if many things appear unchanged (you might have a string that says "Airship=Airship"), others who don't know how to make mods can still easily make a translation for you.

Win. Win. Win. Win.

61

Bug reports / Bugs in the AI with additional resources

« on: 29 August 2011, 16:56:55 »

Wouldn't it be better to improve how the AI works than to give the faction such a huge advantage? As well, I'm assuming that the issue is merely that the AI cannot produce food, a very common game stopper with mods. It would be very beneficial to improve the AI away from whatever causes this problem, rather than a hacky fix.

62

Feature requests / [Done] Option for Camera movement when mouse on window borders

« on: 28 August 2011, 06:15:09 »

^{As per https://forum.megaglest.org/index.php?topic=7477.0}

When you move the mouse to the borders of the game window, the camera will move in that direction. This is an intended behavior and many players will make use of it. However, some players have voiced that they would prefer to disable this feature (the camera can also be moved with the arrow keys, by default). An option, preferably in the INI and the options menu, that could toggle whether or not this behavior occurs would ensure everyone is happy. The current behavior should remain the default.

63

Feature requests / [done] Option for Camera movement when mouse on window borders

« on: 28 August 2011, 06:15:09 »

^{As per https://forum.megaglest.org/index.php?topic=7477.0}

When you move the mouse to the borders of the game window, the camera will move in that direction. This is an intended behavior and many players will make use of it. However, some players have voiced that they would prefer to disable this feature (the camera can also be moved with the arrow keys, by default). An option, preferably in the INI and the options menu, that could toggle whether or not this behavior occurs would ensure everyone is happy. The current behavior should remain the default.

64

General discussion / Complex widgets; Compound widgets missing

« on: 17 August 2011, 00:48:23 »

When trying to compile the latest Git-master, I got an error of missing files for complex_widgets and compound_widgets, which both appeared in the SLN, but the files themselves didn't exist and I double checked to make sure that I had the most recent version. What are these files, and why don't they seem to appear in the master?

65

Mods / How to distribute your mod

« on: 15 August 2011, 00:52:44 »

So you finished your new mod after weeks of effort? Or perhaps you're about to release a beta to show others how your work is going?

STOP.

There's still some things to do for distributing your mod. These are not rules that must be followed (ie, we won't remove your post for not following them), but they can increase the downloads your mod gets, can improve community reception, makes your mod easier for others to install, and overall improves your mod in various ways. You can think of them as guidelines for getting the most out of your mod.

Ensure it's in a manageable format.

• Mods should generally be distributed as either a zip or 7z, for compatibility. While you can use formats like bz2 or gz as well, they are frowned on because they are not only inferior to 7z in compression rate, but cannot be used as an archive in GAE. As well, the extra tar file can confuse users, whereas 7z and zip only have one archive file.
• 7z archives must be non-solid. This ensures support with GAE's addons.
• Mods should be released in the addons format, which ensures that all engines can install the mods equally easy and with a standard (GAE users can copy the archive to the addons folder, which Glest and MegaGlest users can extract it to their User data folder.

Upload to a suitable location

• There's no perfect host for files, sadly, as most hosting sites will eventually delete inactive files, some lose files for no reason, etc. Some of the top tier hosts are Dropbox, Free-hidrive, and various other personal file hosts.
• GitHub can also be used as a repository for containing all files in an accessible format, and is particularly handy for collaborative efforts, though is more complex and will require some time to learn how to use it.
• Uploading to multiple locations such as a regular host, sites like ModDB and GitHub provide alternative locations to download as well as make your mod easier to find.

Post a forum thread

• If you haven't done so already, make sure you have a dedicated thread specifically for your mod on the board. Don't post the links in some other topic, make a new one.
• Have a proper first post in that topic, as that will be the most visited post. The current downloads should always be there, and there should be screens and information about the mod. If the first post consists of only a single sentence and a link, don't expect any downloads. Update that post with each release. Also, editing the title of the first post changes the title of the entire thread, new releases should take advantage of that.
• Don't make more than one thread about your mod, even if it's a new version. Stick with editing existing posts.

Place your mod on the Glest Wiki

• The Glest Wiki is the number one result in search engines for Glest mods, so take advantage of that and ensure your mod is mentioned there.
• Make sure your mod appears in the Mods/List page (for techtrees and factions), the Tilesets/List page (for tilesets), the Scenarios/List page (for scenarios), or the Maps/List page (for maps). If it's already there, ensure the download link is up to date.
• Consider making an individual page for your mod (such as how Apocalyptic Dawn or Japanese do). This forms a central location from which you can document your mod.
• Ensure you're familiar with the Wiki's guidelines before editing. If you need help with editing, take a look at the Help Wiki or post in the wiki forum thread.

Ensure your mod has stated a license

• All mods need to have a declared license, or else others do not know what they can or cannot do with your work. The most common license for mods is CC-BY-SA, which means that the users can use your work in any way as long as they credit the author(s) and release it under the same or a similar license. Another common license is CC-0 which is effectively a way of ensuring your mod is public domain in any location, and users can do anything they want with it, no need to credit the author and no restrictions on their licensing. CC-BY-NC-SA is generally frowned upon because it prevents only indy developers from using your work, as major developers would never use a Creative Commons license anyway.
• If you use any work by other authors (eg, you use a song by another author licensed as CC-BY-SA), you should include an "AUTHORS" text file with your mod that lists all the other authors, what work is theirs, and the license it is under. You can use multiple different licenses by explaining them here.

Promoting your mod

• Consider having your mod on sites such as ModDB, news sites, modding boards, etc to gather players from outside of the existing Glest community.
• Place a link and basic information in your signature. Signatures can be edited in Profile > Forum Profile.
• Consider letting real life friends know of the mod, advising them to spread it on to others, and use sites like Facebook, Twitter, and blog sites to reach out to others.
• Listen to community feedback: others opinions can often help improve your mod, keeping them coming back for more
• MegaGlest mods can be added to the Game Mods menu which also makes them eligible for free hosting on megaglest.org (contact the MegaGlest team). MegaGlest mods which are not ready to go into the Game Mods menu yet can still be mirrored on megaglest.org if they are not a pre-release version ("alpha", "beta" or similar) and licensing terms allow for mirroring them. When contacting the MegaGlest team, provide the original download location, file description and licensing terms.

66

Feature requests / Allow detectors to have multiple cloak groups

« on: 4 August 2011, 22:04:51 »

Just a small change, allowing detectors to have multiple cloak groups would be a huge asset for Apocalyptic Dawn, which is fine the UNATF as it is, but once the Brotherhood is implemented, it would need detectors to be able to exist in multiple cloak groups to ensure that the planned stealth vs detection balance can go as planned.

This would preferably use slightly tweaked code such as:

Code: [Select]

<groups>
<group name="ground-cloak" />
<group name="air-cloak" />
</groups>
It would be an optional value, though at least one of either the one group or multigroup syntax would have to be used, and if both are present, use the multigroup (more versatile).

The current plans of stealth and detecting units in Apocalyptic Dawn is:

So, the stealth units in UNATF are the B-2 Spirit and the XM500 Special Op. The B-2 Spirit can only be detected by UNATF's Patriot Missile System, while the Brotherhood detects it with their L152 Takeout unit. The XM500 Special Op can be detected by the MQ-1C Grey Eagle in UNATF and the Attack Dog or the IT26 SHADE Trooper in the Brotherhood. Both of these lose stealth temporarily while attacking.

In the Brotherhood, there is currently only IT26 SHADE Trooper with stealth, and it is detected by the MQ-1C Grey Eagle in UNATF and the Attack Dog in the Brotherhood. It loses stealth if it attacks with it's gun, but not if it attacks with its knife. As necessary, all units must have some type of detector in both factions (so in a Brotherhood vs Brotherhood game, things still work, etc).

Only changes to this original message is that the XM500 Special Op will uncloak on move, not attack, and the IT26 SHADE Trooper will not uncloak on its machete attack, only on the assault rifle attack.

67

Feature requests / Non-translated Lua strings: New strategy

« on: 20 July 2011, 03:46:35 »

Yes, this topic has been brought up before, and was denied, presumably to encourage the ability to translate scenarios. However, I return with new logic because, to be honest, we (or at least me) need this feature.

Firstly, why would we need to have a Lua string bypass the translation (if a string isn't translated, it gets a rather ugly "???" surrounding the text, which, while great for testing, doesn't do a whole lot of good to regular players, especially since the untranslated string would be better to display than the untranslated string surrounded by question marks)? Well, let's use an example. In Apocalyptic Dawn (formerly known as Military), the king of hill scenario displays a timer as the display text, counting down from 10:00 (ten minutes). As a result, there are over 600 lines just from this timer. Personally, I had to write a script to generate those lines even, and many modders would just get stumped on how to proceed.

As another example, suppose the display text dynamically tracks enemy kills, and lists them. If the enemies spawn using a formula for infinity (ie, Call of Duty Black Op's zombie mode), there's no saying how many kills they'll get. We could end up just having a language file of 1000 lines that look like "1=1, 2=2, 3=3"... We shouldn't have to do this.

But before we think that this is just for numbers, suppose we output the name of the last unit to die (this is done with lastDeadUnitName()) into the display text. Or if we ever get a way to allow players to input data (eg, type their name), we'd want to output that non-translated too.


So that sums up why we need this simple feature, now as to how it can be done. Firstly, I propose two methods. The first is simplest, though would require the entire output be non-translated, while the second would allow some translation. Obviously, the second is more difficult, though would allow translation to still work by only bypassing the translator for the variable. However, it should be noted that no mods actually are in anything but english (GAE's customized magitech, being bundled with the engine, is not a mod)! Besides, this feature would be used rather rarely, only when it is necessary to bypass the translation, such as in the examples listed above.

First method:
Firstly, we can simply set the display text or post a message by using an optional attribute in the function. Instead of showMessage(text, header) and setDisplayText(text), we'd have showMessage(text, header, [translate]) and setDisplayText(text, [translate]) (where translate is an optional boolean value which defaults to true, but if false, will bypass the censor). The advantage is a backwards compatible, easy to use method of telling a string not to be translated. The additional attribute would even be ignored on an older version of GAE, preventing that from breaking.

Second method:
Now the more complicated method: a way to have some parts of the string translated and some not. The string concatenation unit in Lua is .. (thus, to combine the strings 'Cat' and 'Dog', we could use 'Cat' .. 'Dog'). Thus, we'd use the above method of not translating a string, but instead translating parts of the string using a new function (nested), and then combine all these parts, some translated and some not, into our new string, which we'd output.

This would need a new command such as translate(text) that would translate the text and return the translation (and old school, if there is no translation, we'd see it surrounded in question marks). I'm thinking an example is worth a few dozen words:

Code: [Select]

showMessage('Do not translate' .. translate('translate_me') .. 'Do not translate', translate(header), 0);
So how does that work? Firstly, the first attribute is the text of our message, where we have a non translated string at the beginning and end (since it isn't passed through the translate() function), then we have a translated string in the middle (it is passed through this function). Thus what the engine does is it perform proper nesting, first translating the "translate_me" string from the language file and "merging" it with our non-translated text to make our finally line. We must translate the header too, since we'll be turning translation of the final product off. Finally, since we already did the translation needed, we set our last attribute, as described above in the first method, to false, meaning it will not try to translate this line (it's already translated, thanks to the translate() function.

This isn't a whole lot more difficult, and expands on the first method, so it's wholly possible to do just the first method and then come back to the second method later.

For the need of a better example of it in action, let's use this example. Here, we set the display text to tell the number of kills and the name of the last killed unit. For simplicity of the example, the number of kills and last killed unit are just static variables, but in an actual scenario, they could be dynamic variables that will be changing with each kill.

Code: (Lang) [Select]

string_beginning = Total units killed so far:
string_middle = Last killed unit was a


Code: (Lua) [Select]

kills = 19;
lastUnitKilled = 'swordman';

setDisplayText(translate('string_beginning') .. kills .. '(' .. translate('string_middle') .. lastUnitKilled .. ').', 0);

The important part of this above example is: translate('string_beginning') .. kills .. '(' .. translate('string_middle') .. lastUnitKilled .. ').' This would output Total units killed so far: 19 (Last killed unit was a swordman)..

I cannot think of any flaws with this strategy, as I even checked to ensure that you can concatenate strings as attributes to functions (eg, myFunction('1' .. '2');) and that Lua performs coercion (converting numbers to strings when performing concatenation), eg, myFunction('string' .. 2);.


To sum that all up, there are two changes. The first is simply adding an attribute to setDisplayText() and showMessage() which will allow the translator to by bypassed. The second is adding a new function translate() to grab the translated version of the string. Things like concatenation and coercion are a standard part of Lua and should already exist in the engine. Note that the second function requires the first change to be of any use.

If these changes occur, it would make things like timers far, far easier in scenarios, and as per a very interesting idea on the Apocalyptic Dawn thread, there will certainly be some interesting scenarios to come from this! As long as the second method is chosen and modders 'play within the rules' by not abusing the bypass of the translator when not needed (eg, don't bypass anything unless it is not static, that is, not created during the game, such as a timer or kill count), there will be no negative impact on anyone wishing to translate the scenario, except possibly in languages where the sentence structure may be different and the variable would normally be in a different spot, which is a small compromise for the advantages this offers.

68

Feature requests / Cooldown on Permanent Cloaking

« on: 13 July 2011, 07:01:48 »

It's possible to have a unit that has a permanent cloak (meaning they always have a cloak unless they use a decloaking skill (eg, they might be set so that when they attack, they become uncloaked) or are within the sights of a detector unit of the same cloak group). I had an interesting idea about having a unit that can only decloak by attacking, however, there was one slight issue: the moment they stopped attacking, they would instantly become "invisible" again. I propose a "cooldown" period for these decloak skills.

This would be XML specified, such as with <cooldown value="10" />, which would specify the time in seconds before the unit will be cloaked again once it finishes using that skill. So with that tag, for example, a unit that decloaks on attack will not be cloaked again for 10 seconds, so they cannot take out an entire base single handedly by letting the cloak resume after the attack, as well as it would work well with units that are meant to attack infrequently, eg, every 5 seconds.

Relatedly, another feature would be to prevent these cloaking units from regaining their cloak if under attack, and require a cooldown period of which they cannot be attacked in to cloak again. This could use <no-attacked-cloak value="true" length="10" />. The value would enable this (if false, they can regain their cloak even if under attack; if true, they cannot regain their cloak until they are no longer under attack). The length would be a cooldown period, in seconds, in which they cannot be attacked within in order to become cloaked again. If they get attacked, the timer restarts.

For example, a unit might have a decloaking skill on attack, so when it attacks, it's suddenly visible. The enemy will attack this unit, so even if it stops attacking, it will not regain it's cloak while under attack. If it kills the attacking enemy, it would have to wait ten seconds to regain that cloak.

Without this, cloaking without a detector will be hampered. I plan to make use of such a feature, if implemented, in Apocalyptic Dawn by having a sniper that has very potent cloaking and cannot be seen until he attacks (though I may have to give the short-sighted Headquarters a detector to prevent the abuse of them for spying on bases). The entire point of snipers is to remain hidden until after they snipe. Of course, once he pulls that trigger, he's vulnerable (the US, if I recall, has a system that can locate a sniper instantly based on the sound waves). This could also be applied to a sniper perch defensive structure, allowing them to be hidden until they decide to pull the trigger (it is a camouflaged post).

69

General discussion / Optional tags

« on: 11 July 2011, 23:30:56 »

I know that tags like the resource-requirements are optional in upgrades, but does this apply to units (and everywhere else)? Are all "empty" tags, such as levels or unit-requirements optional? If so, would this be GAE only, or would it apply to all versions of Glest?

70

Feature requests / Simple override for default levels

« on: 11 July 2011, 22:40:42 »

Since you can specify that stats for leveling up (eg, you might want it to gain a 1.25x multiplier for attack after 8 kills), the old system (1.5x hp, 1.5x ep, 1.2x sight, 1.5x armor) is should generally not be used if you are specifying custom levels. Because of the large number of mods which may depend on this "faulty" combination of both the default and their specified custom leveling, we cannot just disable the old system when specifying which stats to raise and by how much when leveling.

I propose a new tag such as <disable-default-levels value="true" /> as a child for the <level> tag (sibling to the static-modifier and multiplier tags). If true, the default leveling will NOT take place. If false, it will take place in addition to whatever you specify, unless you override them with:

Code: [Select]

<multipliers>
          <max-hp value="1" />
          <max-ep value="1" />
          <sight value="1" />
          <armor value="1" />
</multipliers>As it is, if you wish to disable to default system, you must specify this multiplier above, as it will override the defaults then. The implementation of a <disable-default-levels value="true" /> tag would be a cleaner alternative to disable to default levels, as well as hopefully reduce the number of modders who may be surprised to find the default is combined with their custom chosen stat increases.

71

General discussion / Animation bound to build HP

« on: 6 July 2011, 20:51:09 »

This was discussed before, and not sure whether or not it was implemented in GAE, but at any rate, MG has it implemented, and in the words of Titi, it was very easy. Basically, if the value is true (MG syntax <anim-hp-bound value="true"/>), then the animation will depend on the amount built so far, so if the building is at half HP (half built), the animation would be half done, etc.

If this is already implemented, what is the syntax? If not, we should follow MG's syntax.

72

Feature requests / Scenario Unique Addons

« on: 6 July 2011, 01:52:05 »

As it is, we can have scenario unique maps by placing the GBM/MGM file in the scenario's directory. This allows maps that are made only for that specific scenario (and thus not playable in a regular game) to be used without the risk of someone accidentally trying to play a regular game with them. I propose one step further: scenario unique addons. These are addons that would only be applied to that scenario, thus, you could have a scenario which uses magitech, but adds in a new unit to magitech. The reason to use a scenario specific addon is to prevent the loading speed of a regular game from increasing and to allow the original faction to be unmodified, necessary for multiplayer.

This would make the current way of having a map scenario specific by placing it in the scenario directory deprecated (though it would still be supported for backwards capability). The big advantage is this means we could have scenario specific techtrees, factions, maps, tilesets, even tiny tweaks to an existing mod (eg: magitech).

The addon would be read the exact same way as addons are normally read, just at the start of the scenario, not the start of the program. The addon would be immediately "voided" (for lack of a better term) once the scenario is over (so you could modify the language strings, eg: so a pirate scenario has pirate talk in the language strings, and the original language strings would be used once the scenario is over).

To prevent the possibility of any stray files in the scenario directory from being mistaken for addons, the addons would all be placed in a new folder in the scenario's directory simply called "addons", which could contain multiple addons like the regular addons folder does. This would make the folder (from the shared folder) gae/scenarios/category_name/scenario_name/addons (eg: gae/scenarios/glest_classic/storming/addons).

Pros and Cons Analysis
Pros:

• Allows scenarios to do so, so much more
• Clean and easy way to modify assets for scenarios

Cons:

• Cannot package scenarios as an addon.

73

Feature requests / Tileset unique maps

« on: 6 July 2011, 01:42:18 »

With the dawn of many tilesets using new techniques with larger than normal objects (eg: 2x2 objects like houses), these tilesets need special maps made specifically for them, and these maps will not generally work with other tilesets. Thus, the solution I propose to prevent clashing is to have maps that are "tileset specific", meaning they can only be chosen with that tileset. To do this, the map would simply have to be inside the tileset directory (eg: Tilesets/dark_forest, the same directory as the tileset XML is stored).

If the user selects that map on the new game screen, the list of tilesets will automatically change to filter out the non-supporting tilesets. If they choose that tileset, the same goes for the map list. There can be multiple maps inside the tileset folder (meaning the tileset can be used on multiple different maps) and maps can appear inside more than one tileset folder (so if map A is in both Tileset1 and Tileset2's folders, then both Tileset1 and Tileset2 will appear in the tileset's list on the new game screen). Yes, this would mean there could be multiple copies of the same map, but it's the cleanest way, and besides, it's unlikely for many tileset-specific maps to be compatible with more than one tileset.

Scenarios will completely ignore this rule, to allow custom maps that are only for that scenario to be used.

Pros and Cons Analysis
Pros:

• Prevents incompatible maps from being used in tilesets made only for certain maps
• Still MG compatible (though the tileset specific maps wouldn't appear in MG, the tileset itself would still work, and the maps would just have to be added to the MG directory
• Doesn't break scenarios and the way they can have maps that won't appear in the map list

Cons:
   You know me, I'm too good to let any cons appear in my feature requests.

74

Bug reports / BUG - Scenario not end on death

« on: 28 June 2011, 20:03:05 »

Testing some stuff for scenarios, with the default winning conditions on, even if you are completely wiped out, the game will not give the "you lose" message. Normally if the default winning conditions are on, you win and lose based on the buildings destroyed.

As well, the loading screen images for scenarios don't seem to be working. I just got the generic missing image screen. Is the loading screen the path relative from the scenario XML?

75

Forum discussion / Theme update and SMF 2.0 complete

« on: 26 June 2011, 18:49:54 »

2 July 2011:
The theme has been updated. This topic is kept only for the record. Please move any active discussion to the main Glest Board topic.


1 July 2011:

Happy Canada Day! An email from Jose revealed he was sick, but has just backed up the board and is likely to update today. The board will go offline during that time span and until I get the mods installed, it will not be 100% complete. Thank you for your understanding.


I originally planned to upgrade the board today, since I finished the theme and the mods were all tested and ready to go. Sadly, it has proven to be impossible, due to limited rights. The web install fails with a 500 because some PHP functions seem to be disabled. As well, the large install cannot be used because while I have a (very limited) method of uploading files to the server, there is no way to extract the files (not to mention that if the web install would fail, could this even succeed? Would render the board nonoperational unless the restrictions limiting the web install too were removed).

Thus, we must let the Glest team do the upgrading. I will try and contact them, and send the theme (though I could do the theme myself, once upgraded, if necessary). Mods would have to be installed after.

If anyone wants to take a look at the theme, feel free (requires a server running SMF 2.0): https://www.sugarsync.com/pf/D6983676_8815923_64554


This is a notice that the theme has been completed and I am just doing the finishing touches of gathering the mods (note: some mods are not yet compatible, so there will NOT be the activity bar, at least not until the author updates it).

The board will probably be down for around an hour or so to update the version, which will take a long time to convert all the posts, etc. As well, the update will not be finished until I get all the mods safely added in, so until I change the name (and content) of this topic, please be aware that it is not yet complete and may have bugs. Until it's 100% complete, please do not comment on them.

I do not know the exact start time of this update, but it should be whenever my snail internet finished downloading a backup.


Edit: Ooh, had a good catch there too... While testing the mods, some time after its installation, the Bad Behavior mod, which sounded so great, started crashing the forum. We won't be using that.

Edit2: And it is complete. Uploading will commence shortly. Screens:

Code: [Select]

[URL=http://imageshack.us/photo/my-images/847/preview1r.jpg/][IMG]http://img847.imageshack.us/img847/8523/preview1r.jpg[/img][/URL]

[URL=http://imageshack.us/photo/my-images/405/preview2kq.jpg/][IMG]http://img405.imageshack.us/img405/3723/preview2kq.jpg[/img][/URL]
IMPORTANT NOTICE: The Youtube tag mod was abandoned in favor of another, however, it doesn't use a tag, but just needs the link. Thus, youtube tags will NO LONGER WORK. To embed the video, just post the bare link (no url tags), preferably on a new line for formatting. Problem solved, the old method with youtube tags will be continued, screenshot below.