Messages

26

Feature requests / GUI based unit editor

« on: 1 October 2016, 12:25:26 »

This is something I've been meaning to ask about for some time. I make custom Megaglest factions, usually based on the existing art and assets. Although I can't complain too much, I do find that it's ultimately time consuming and problematic to edit the xml files of units manually, even in text editors with syntax highlighting and other helpful tools. For one thing you must find the correct code blocks and lines to make corrections based on what you notice in-game, whereas you're also bound to cause errors that only appear when you try starting a new game in Megaglest.

Has anyone considered creating a simple GUI for editing tech trees, and including it alongside the Map Editor and g3d Viewer? I'm thinking a basic program that lets you select a tech tree, lists all of its techs and units, and offers editable fields for every variable... allowing you to delete or create units and skills and attacks, and browse for g3d files or icon graphics or sounds to be included. The program would essentially read existing xml files and update them when you save your changes, offering visual fields for what you currently have to dig up in the xml's yourself. Later on it could have extra features too... like using the g3d viewer to show 3D previews of each unit, graphs for skills, even predicting the balance between techs and letting you know how overpowered they are from one another! The editors in RPG Maker are a good example of how I'm generally imagining such a visual interface.



I understand that making this program would be a bit of work, and the developers have limited time to spend on new features. I won't complain if it can't be considered or happen anytime soon. But I will say that as a developer, I'd find it extremely helpful and useful, and consider the effort totally worth it! People would find it a lot easier to create new tech trees, we should see more content of even better quality in MG. Let me know what you think please.

27

Feature requests / Re: Unit patrolling

« on: 1 January 2016, 21:51:05 »

Still a feature I would gladly enjoy. Hope the devs can give it some thought eventually

Similarly, I wonder if an automatic attack mode could be added. Which would make your units automatically head toward the nearest enemy units and fight them.

28

Feature requests / Re: Changing the appearance of units when an upgrade is researched

« on: 11 April 2015, 06:12:13 »

The Champion unit of my Medieval mod is probably an example, but you need to rearrange the commands in the Champion.xml so the last four commands (the lance attack, requires an upgrade) are moved to the top to become the first four commands, with the upgrade, so you don't need to click the Command bar to use the secondary attack (again, the lance attack).

Can you link or paste the xml file of the unit here please, so we can see how you did it? Although that sounds like the unit will have multiple stop / move / attack buttons, which probably looks ugly upon selecting it.

29

Feature requests / Changing the appearance of units when an upgrade is researched

« on: 10 April 2015, 18:53:11 »

One thing I liked in some RTS games I've played in the past is that some upgrades had visual effects on units. For example: If you researched an upgrade that increased the shield of your base, the visual appearance of all your bases would change (different model and texture) to feature a more solid appearance for the building. In Megaglest, upgrades can be used to boost the traits of certain units or enable the usage of certain skills, but they cannot change the visual appearance of existing units.This is something I would really love to see fixed!

Since skills define the g3d file and animation speed, I think the easiest way would be swapping skills for a command based on when an upgrade has been researched. For example: A soldier can have the normal stop_skill / move_skill / attack_skill, but also a stop_skill_armored / move_skill_armored / attack_skill_armored. Normally the stop command uses stop_skill and so on... but once the blacksmith researches the armor upgrade, the same stop command will use stop_skill_armored. The *_skill_armored skills point to a different set of 3D models which includes the same unit dressed in armor.

Apart from the visual effect, this approach could also be used to completely replace an unit's attack with a whole different attack when an upgrade is researched, which could be an alternative to unit morphing. This is probably less important since you can already make certain commands only become available when an upgrade was researched, but I'm still interested in changing the visual aspect of units.

30

Feature requests / Limiting skills and structure placement to the vicinity of certain units

« on: 10 April 2015, 18:29:57 »

This is a common feature in many RTS games, which I think the MegaGlest engine didn't implement yet. In some cases, faction designers might want to limit the creation of certain units as well as units preforming given actions to the vicinity of some structures. In other words, some buildings should only be possible to build within a given radius from other buildings, whereas certain units should only be able to preform certain skills when close enough to a specific unit.

Practical example 1: Limiting houses to the vicinity of the castle. The faction cannot place a house in the middle of nowhere, and may only create houses within a distance of eg: 15 tiles from a castle (and potentially other houses). When trying to place the house too far from a compatible structure, the hologram representation should turn red to indicate the action isn't possible.

Practical example 2: For some factions, we might want the summoner to only summon some units when standing close enough to a summoner tower (presumably to draw energy from it). Summoners can therefore wander anywhere around the map, but can only summon when they are standing at most 10 tiles away from the tower.

Practical example 3: The blacksmith can only research certain upgrades if a technodrome is located right next to it (eg: 5 tiles), otherwise the button is gray.

Note that the engine already supports boosting, so certain units gain a mana or health bonus when close enough to other units. But as far as I'm aware, there's no support for limiting the construction of some buildings to the vicinity of others, nor limiting specific actions this way. There should be a workaround to the second issue, by giving the unit 0 max mana by default and only allowing that to be enhanced by boosting... but you still can't limit the availability of specific actions.

Also: If the feature will be considered, it could be implemented to support the reverse effect as well. For example, mages could build towers that disrupt the energy of other mages, so when an enemy mage is too close it cannot preform any energy attacks. Or you cannot build houses too close to farms, because people don't like the smell or something

31

Closed feature requests / Re: [Awaiting pull] Looting

« on: 19 July 2014, 23:27:21 »

Awesome! Thank you for adding this great feature... it will likely be a lot of fun

32

Feature requests / AI lacks understanding of building / worker / summoner morphing

« on: 6 April 2014, 20:07:52 »

At this moment, the AI is only interested to morph units when the unit it's morphing to has a better attack. Due to this, things like upgradable buildings or summoners / builders which can ascend and offer new units are difficult to add, because they're not fully understood by the AI. Please extend the understanding of the CPU on unit morphing to encompass buildings builders and summoners, not just warriors.

For example, you cannot make a faction where the Blacksmith you build offers a set of upgrades, but can be morphed into an Advanced Blacksmith which offers new upgrades. The AI never morphs to the Advanced Blacksmith because it doesn't attack, which is currently its only criteria for morphing, so it doesn't care about the upgrades it has to offer. The only workaround is to give the Advanced Blacksmith an attack... which tricks the AI into morphing to it eventually, though it's only for the attack as far as its concerned. Enemies & Allies is a popular tech tree which uses building upgrading, and where the AI never upgrades anything due to this... I also plan on using the feature in most tech trees I will make.

The only thing that probably needs changing is having the CPU also scan for buildings, unit production and upgrades when deciding whether to morph something, apart from only the new unit's attack. It already does this when it decides what workers or buildings to produce, so maybe the same code can simply be piped into morphing. I hope someone can look into this... the current AI's understanding of morphing is very limited and causes factions to require workarounds such as fake attack skills for some unit upgrades.

33

Bug reports / Re: AI breaks when a morphed unit produces units with negative resource requirements

« on: 31 March 2014, 14:39:27 »

The ai has issues morphing structures in general. I think its due to the AI being designed to only morph to warrior units. Perhaps If the post morph unit had an attack skill this might encourage AI to morph. But its still an uncertainty.

My faction relies on morphing both units and buildings. Although many said the current AI isn't good at morphing yet (especially buildings), it's doing a very good job from what I'm seeing. But yeah... I think this is a bug regardless, which has something to do with an incorrect calculation of units that give negative resources. For now I changed the design, so no unit which produces minus-resource units can be morphed to, only build directly.

34

Feature requests / Re: Miners cannot unload to air units

« on: 31 March 2014, 14:35:42 »

While its not possible for land units to deposit to air units, it does work the other way around. Flying units can harvest from the ground and deposit to a ground structure. Ive seen it in the aqua pack.

That does work, I can also confirm. My only confusion now is if the air unit storage behavior should still be changed. Softcoder said this is intended... but then shouldn't units that can't unload there just ignore the air unit rather than following it around and doing nothing once they're near it? Since that part of the problem seems like a bug, and doesn't feel like intended behavior... sorry if I'm wrong though.

35

Feature requests / Re: Miners cannot unload to air units

« on: 31 March 2014, 01:14:20 »

Oh... sorry about that. So it can be solved by also making the air unit have a land property, if that's possible?

Still, shouldn't the miner just ignore the unit it tries to unload to? It does seem rather buggy for it to keep following an unit as if it's trying to unload but never managing to.

36

Bug reports / MG crashes when creation time of an unit is zero

« on: 30 March 2014, 01:03:12 »

If the creation time of an unit is set to zero (<time value="0" />) Megaglest will crash with a "floating point exception" error when the AI (CPU Mega) attempts to build it, although nothing bad seems to happen if the player builds it in a local match. Can be solved by setting it to a higher value, but I don't think it's normal for it to actually crash the engine so I still thought to report.

37

Bug reports / AI breaks when a morphed unit produces units with negative resource requirements

« on: 29 March 2014, 22:01:09 »

I noticed this less obvious bug while working on my tech tree: The AI will refuse to build or produce anything if an unit can morph into another unit which is able to produce an unit that has a negative resource requirement. I preformed various tests and this is a certain conclusion.

To offer an example with the Tech faction: Currently, the farm can produce cows, and cows take -100 food. However, if the farm wasn't an unit which was built directly, but say the Blacksmith could be morphed into a farm, the AI would refuse to do anything.

38

Feature requests / Enable land units to deposit to air units

« on: 27 March 2014, 12:51:34 »

I'm working on creating a faction, and noticed a very problematic bug yesterday: If an air unit stores a resource, harvesting units won't be able to deliver it to them, and will just sit there and do nothing. This happens both if the harvesting unit is land or air itself. The opposite doesn't happen however, and air miners can deliver to land units.

Say you make a flying saucer which can store 100 metal. You move it next to a metal deposit, then assign a worker to mine from that deposit. Once the worker is loaded, it will look for the nearest unit to take the metal to... in this case it finds the saucer. It will walk next to it, but instead of depositing the metal then returning to the mine to continue, it will just sit there and follow the unit around... as if it's trying to unload but can't.

When both the unit which deposits and the unit which harvests are air units, the miner should definitely be able to unload. If the unit who stores is air and the unit who mines is land (or the other way around), whatever the developers believe makes most sense: Either the miner can still deposit, or the miner should ignore the air unit and look for the other nearest deposit... considering they are at different heights logically.

39

Closed feature requests / Re: Looting

« on: 26 March 2014, 02:51:30 »

Makes sense. The percentages aren't a feature I care very much about, I only mentioned them because they might be helpful and I remember seeing them in other XML functions. The part I consider really important is adding an XML function to units so they can give the attacker which destroys them a certain amount of resources... allowing for looting or harvesting your enemies (sometimes for unique resources).

40

Closed feature requests / [done] Looting

« on: 25 March 2014, 20:38:47 »

I was surprised to hear this doesn't exist yet, since it's a rather basic feature and needed for many ideas. If it's not too difficult, please consider adding it soon!

I'd like a new function in the faction XML to specify a list of resources that destroying an unit will give the attacker. If a value is specified, that amount of the resource is given, whereas specifying a percentage gives that amount from what the faction which owns it has. If specifying a negative value, the attacker would actually lose that resource when destroying an enemy building, although that would make little sense. A flag should specify if to also deduct that amount from the owner faction and how much, or if to just make those resources appear to the attacker. If the attacking faction does not use the resource or have where to store it, there's no effect. The function I have in mind would be something like this:

Code: [Select]

<resources-death><resource name, amount, loss/></resources-death>
Example 1: A faction has a building which can be looted of half of the resources it was build with. It costs 100 gold and 50 stone to build. When it comes to the gold, the owning faction will also lose half of what's being looted. Also, 5% of the faction's entire wood stock will be taken away entirely. The code would be:

Code: [Select]

<resources-death>
<resource name="gold" amount="50" loss="50%"/>
<resource name="stone" amount="25" loss="0%"/>
<resource name="wood" amount="5%" loss="100%"/>
</resources-death>
Example 2: The attacking faction uses an unique resource called X, which is optional and can only be extracted by destroying a certain building from another faction. That faction however doesn't use the X resource in any way itself. Implicitly, the resource can only be obtained if the attacker is playing against this faction so they have the building to destroy. The victim faction's building would have this code:

Code: [Select]

<resources-death>
<resource name="X" amount="50" loss="0%"/>
</resources-death>
Before anyone asks, yes, I'm aware this is already possible in Lua for scenarios. To properly do it as part of a faction however, it must also be possible within the XML files of units, otherwise it will not be consistent and won't work in normal battles.

41

Feature requests / Re: Continuous mode (dead factions replaced by new ones)

« on: 1 October 2013, 09:13:03 »

I think this could be very possible via a scenario, and I do agree a map should be bigger at least 256. to solve the power difference each empire should spawn larger than previous empires.

I think it's an interesting idea.

Ah, yes. Lua might be able to do this already... it should have the scripting functions needed. And sure, the map needs to be big enough for this to work out well.

42

Feature requests / Anaglyph stereo support

« on: 30 September 2013, 19:33:37 »

This is probably a more uncommon feature for a RTS game, as visuals tend to matter less from a distant top view. But could support for anaglyph stereo be added to the engine? I have red & cyan glasses, and use them for many games that have stereo support. I think it would look nice for Glest too to see the environments and units in realistic depth

43

Feature requests / Re: Alliance changing system

« on: 30 September 2013, 19:27:28 »

Sorry for reviving an older thread, but I wanted to suggest one more thing: Can the AI be taught to utilize this system please? It seems CPU players have some knowledge on when to accept a player transferring to their team. But I never get any requests from an enemy CPU to join me, nor do any allied players ever betray me. At least in single player I would like to see this.

It should be easy for an AI to evaluate the situation every few minutes and act in consequence. If his allies are weak compared to his foes and also not positioned close to him (as such would mean instant conflict), an AI should seek an alliance with other teams. All the same, the AI should only accept an alliance when it feels it's too weak to take on its enemies, rather than doing so blindly.

44

Feature requests / Re: Automatic unit production

« on: 30 September 2013, 19:17:12 »

Bump. I was wondering if more thought was given to this by the developers. Playing a MG game last night, there were times when most effort went to going back and forth to click buildings and their unit production buttons. It made me less able to focus on what was going on and what choices to take, while sometimes forgetting to build units in some places in favor of others (leaving towns undefended). Although I see the point D.U.P.A. mentioned, I think this would be helpful for Glest too, since numerous units is a key to surviving and once you have a large nation it's hard to attend to all.

45

Feature requests / Continuous mode (dead factions replaced by new ones)

« on: 30 September 2013, 17:48:08 »

Someone close once told me that a reason they don't like RTS games is because you always build everything just to start over again. I remembered that as I was thinking of an idea for MG earlier today. I doubt this would be possible to do in practice, but still wanted to comment the idea.

When you destroy all enemy players, you get a message saying "You have won, press OK to quit". But what if there was a way to have a game that never ends? Whenever you defeat your enemies, new ones appear, who also develop and eventually fight you. This could be achieved by having each defeated player start over again instead of being booted from the game, with the default units and resources. In single player, people could save such games and play them for as long as they want like a story. In multiplayer, people could fight over conquering a map for weeks, each defeated player having the ability to return and build a new nation which will fight the victorious player again. Unfortunately there are at least two major issues which likely make this impossible:

First one is that a new player would be severely underpowered on a map where an evolved player already exists. We couldn't simply have a faction with one castle & 3 workers appear, when a player which has an army of hundreds could simply walk to them and wipe them out in a second. There would need to be some way to keep the victorious player from harming a newly created player until they're strong enough, but any way I can imagine would be an ugly hack.

Second issue is resources. Supposing the defeated player already mined all the gold at his spawn location, the new nation taking his place wouldn't have any gold to mine. So the only way would be all resources getting reset whenever a new faction "arrives" to the map. But what if a building or unit is standing where a forest that was harvested used to be, when attempting to place the trees back? Once again, likely impossible since any solution would be weird.

Still, I'm hoping the idea might be inspiring and someone could think of a system for a "continuous mode". In real life, every empire that fell had another taking its place. Either a larger empire divided itself, or new people came and made their own. Being able to simulate this in Glest games would be pretty neat

46

Feature requests / Re: In-game Lua Console

« on: 30 September 2013, 17:20:00 »

+1. All other games using Lua that I know of have this console, and it can be quite useful.

47

Maps, tilesets and scenarios / Map - Control Points

« on: 29 September 2013, 21:50:51 »

I decided to make a MG map, based on a concept I had in mind for some time. It is a 3 x 3 player, 64 x 64 size map, mirrored on the X and Y axes. Each team's mainland is separated by a river. In order to get from one base to another, you can go through two paths. Each of those paths has a clearing with resources on it, 3 per path / 6 in total. Each team should conquer those spots in order to make it harder for the enemy to get to their base. The idea is similar to Onslaught mode in FPS games, hence the name

Links: source 1, source 2. Once again I forgot how to take a top-view screenshot, so here's a picture from the map editor:

48

Feature requests / Re: Auto RETURN

« on: 12 August 2013, 13:47:31 »

I hear you... this is one of the things I dislike most as well. Sometimes I leave my units guarding an entrance when suddenly a few enemies come by. My units chase them but never come back after killing them. Slowly they find themselves near enemy towns where they get themselves killed. Would love to see this fixed.

49

Feature requests / Defecting units and conquering buildings

« on: 12 August 2013, 13:41:55 »

Here's a nice feature I was thinking of: What if there was a way to convert enemy units to own units, instead of always having to destroy them? In other words having units that defect to an enemy team under some circumstances. Obviously the golden rule is that both you and the enemy must be of the same faction.

I can think of two ways in which this could take place. One is having enemy units automatically become yours if they're low on health and underpowered, as a way of surrendering so you spare their lives. This could be done by having each unit detect the count + attack + defense of enemy and allied units in their view range. If the unit determines there's no chance to win that battle, they might offer themselves to the faction they're fighting. After all, no army has soldiers that wouldn't be betray to stay alive Predisposition to betrayal could be influenced by certain factors. An idea might be the amount of resources you have... so if you're low on food for instance, your units might have a lower moral and turn over to enemies more easily.

The other way is making enemy conversion an attack type, and having special units do this (priests for example). When a priest approaches an enemy and begins preaching to it, that unit won't attack but stay there and listen. If the priest is allowed to talk to the enemy units for too long, that unit is convinced to join their faction. I remember seeing exactly this in another RTS years ago (I think it was Populous) and it worked nicely. But this ability should require limited mana, and certain units should be immune to preaching. Only problem is such units would be useless if you don't have an enemy of the same faction as you, unless they also have other abilities like healing.

Buildings might be a different matter since they aren't sentient beings. They can simply become yours after their health drops below a certain amount, to represent your troops taking them over. It would be cool to conquer enemy establishments during an attack instead of just destroying them, and take over castles / barracks / blacksmiths. Animals could work the same way, since pigs and cows don't care to fight for their country

I think this feature would add more depth balance and strategy, and I'd love to see any idea like this done. What do you think, and any developers willing to give it a try?

50

Feature requests / Re: Ability to change music when an upgrade / new unit is reached

« on: 7 June 2013, 09:22:54 »

Now since you can do multiplayer scenarios, maybe such a thing could be done through a scenario? Since you can change the music in game through lua.

Technically it sounds like you can. But this is meant to work primarily for custom matches, not only scenarios. It does however sound like the same function that allows doing it in a scenario could help do it as a faction property.