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.


Messages - thiemo

Pages: [1]
1
Feature requests / Re: Randomly generated maps
« on: 30 December 2017, 10:00:38 »
Quote
1. Create the height map.

My gut feeling is that the height map should rather be done last. The earlier you do the more likely it seems to me that you end up with inaccessibly portions where units are sort of islands. My idea would be (with the premise that every object has a specific anti-gravitational or gravitational force according to its nature and the nature of its counterpart, e.g. player positions repel each other strongly where as resources are lightly attracted, resources attract of the same type but the more are coagulated already the lower the attraction to prevent big lumps, ...)  :
  • Generate player positions
  • Connect them with paths (not necessarily shown as paths in the map)
  • Generate resource positions
  • Generate obstacles like boulders trees, gallows and gibbets
  • Generate topology where the heights and lows, waters also are (anit) gravitational
http://www.anchormodeling.com/modeler/latest/ could give an idea of its workings.
Maybe the topology should still be generated first but needed an algorithm to make sure there are enough level and level enough places to place player positions, to have paths connecting all player positions with each other (multi use permitted) and all the rest.

2
Bug reports / Re: My "Megaglest" does not appear to be in LAN
« on: 10 November 2017, 00:32:46 »
Here's how your ISP's malicious DNS servers can be replaced by proper ones:
https://telekomhilft.telekom.de/t5/Browser/Navigationshilfe-ausschalten/td-p/2466125

Thanks Tom. This did the trick but funny enough, my clientdoes not show any ip adress in the lan hosted setup screen thingy as described above.

3
Bug reports / Re: My "Megaglest" does not appear to be in LAN
« on: 23 October 2017, 14:43:06 »
Thx, I shall try this solution first this weekend.

4
Bug reports / Re: My "Megaglest" does not appear to be in LAN
« on: 23 October 2017, 11:16:14 »
Thanks to all. I gather, I need to compile a snapshot then and try out.

5
Bug reports / Re: My "Megaglest" does not appear to be in LAN
« on: 22 October 2017, 22:13:49 »
I figure that those public ip addresses are linked to my ISP as a tracepath is really short. However, those are not the DNS my ISP provides me.
Code: [Select]
thiemo @ lenovo-tWeed ~ % tracepath 62.138.239.45                                                                                                                                 17-10-23 0:06
 1?: [LOCALHOST]                      pmtu 1500
 1:  fritz.box                                             4.170ms
 1:  fritz.box                                             1.712ms
 2:  p57A4680D.dip0.t-ipconnect.de                         1.519ms pmtu 0
 2:  send failed
     Resume: pmtu 0

Be it as may, why does Megaglest query such information or maybe why does my tWeed know such information anyway as it uses my fritz.box to send DNS queries?
Code: [Select]
thiemo @ lenovo-tWeed ~ % cat /etc/resolv.conf                                                                                                                                    17-10-23 0:06
nameserver 192.168.178.1

6
Bug reports / My "Megaglest" does not appear to be in LAN
« on: 22 October 2017, 19:11:59 »
Hi all

I wanted to play a LAN game and found my client unable to connect to the providing client that I have been able on previous occasions.

I checked our IP addresses which where were perfectly fine in the 192.168.178.0/255 range.
I hosted myself a LAN game and found Megaglest show me 62.138.239.45 and 62.138.238.45 in the top line where as the top line showed the real ip address of its client.

I tried with removing the personal Megaglest config folder (.megaglest), I re-installed Megaglest and also rebooted - all to no avail.

My partner and I both use OpenSUSE Tumbleweed, however my installation is more uptodate. So, it might be, that this issue arises because of a system update. Hoever, I also debuglogged the network of Megaglest and found some strange things:
Code: [Select]
thiemo @ lenovo-tWeed ~/.megaglest % grep -RnF 62. debug.log                                                                                                                     17-10-22 20:44
395:[2017-10-22 20:27:30] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.239.45]
396:[2017-10-22 20:27:30] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.238.45]
1034:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.239.45]
1036:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.238.45]
1245:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [127.0.0.1], maskAddrStr [255.0.0.0], dstAddrStr[127.0.0.1], ipAddress [62.138.239.45], broadCastAddress []
1247:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [192.168.178.73], maskAddrStr [255.255.255.0], dstAddrStr[192.168.178.255], ipAddress [62.138.239.45], broadCastAddress []
1251:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [127.0.0.1], maskAddrStr [255.0.0.0], dstAddrStr[127.0.0.1], ipAddress [62.138.238.45], broadCastAddress []
1253:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [192.168.178.73], maskAddrStr [255.255.255.0], dstAddrStr[192.168.178.255], ipAddress [62.138.238.45], broadCastAddress []
Line 1247 of the debug.log shows that the real ip address of my system (192.168.178.73) is not entirely unknown to my Megaglest client, making me unsure whether this still is a flaw in Megaglest. Btw, I have not been able to figure out where those public ip addresses come from. Grepping /etc or .megaglest for it showed no result.

I did a standard tumbleweed installation with
Code: [Select]
zypper install megaglestfrom
Code: [Select]
lenovo-tWeed:~ # zypper repos -u -E
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias                            | Name                            | Enabled | GPG Check | Refresh | URI                                                               
--+----------------------------------+---------------------------------+---------+-----------+---------+--------------------------------------------------------------------
1 | download.opensuse.org-non-oss    | Haupt-Repository (NON-OSS)      | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/tumbleweed/repo/non-oss/             
2 | download.opensuse.org-oss        | Haupt-Repository (OSS)          | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/tumbleweed/repo/oss/                 
3 | download.opensuse.org-tumbleweed | Hauptaktualisierungs-Repository | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/tumbleweed/                   
5 | packman                          | packman                         | Yes     | (r ) Yes  | Yes     | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/

The system report shows for the OS and Megaglest version the following.
Code: [Select]
***** Operating system *********************************************************

* Distribution: openSUSE
* Release:      20171006
* Codename:     n/a
* Architecture: x86_64
* LSB support:  1

>>> uname -a
Linux lenovo-tWeed.home 4.13.4-1-default #1 SMP PREEMPT Wed Sep 27 14:20:45 UTC 2017 (4dec972) x86_64 x86_64 x86_64 GNU/Linux

>>> cat /etc/issue
Welcome to openSUSE Tumbleweed 20171006 - Kernel \r (\l).

enp3s0: \4{enp3s0} \6{enp3s0}


***** MegaGlest version ********************************************************

>>> INSTALLATION_LOCATION (def2): [/usr/bin/].

>>> ./megaglest --use-language=en --version
megaglest v3.13.0
Compiled using: GNUC: 70201 [64bit] platform: Linux-X64 endianness: little
GIT: [Rev: $5604.3a5d459$] - using STREFLOP [SSE] - [no-denormals]

Is there a work around?

Kind regards

Thiemo

7
MegaGlest / Re: My impressions and thoughts
« on: 23 March 2017, 01:26:29 »
My feeling about this is that expecting a smart challenging cpu mode is asking too much. Every year lots of big budget games with dedicated AI programmers get slated for the stupidity of their AI and lack of challenge. MG is a relatively small FOSS game and will probably never have an experienced AI coder who could re-write it in any big way.
I am far from being expert with respect to AI. I certainly do not think MG should get a shiny self-learning neuronal network AI thingy that would overcome the player anyway. I see the AI rather as expert system where the designer of the game defines some situation patterns that if matched lead to decisions.

... and a set of switches in the faction XML which allow modders to tweak the AI quite a bit to improve its performance with each faction. Sadly these settings have gone largely untried and untested up till now.
I fear most of us are just lazy slobs like me being reluctant to delve into XML files.

Another way to feasibly better the AI would be through the LUA scripting capabilities. The problem is that whilst this may work in 1p vs 1cpu scenarios it would be too slow for large online multiplayer games.
Maybe the overhead for scripting or for more situation patterns to compare with gets compensated by less need for many many units.

I would however like to see a scenario dedicated to providing a responsive, tactical challenge in a local 1v1 game.
I second that.

Finally I would  like to say that as a long-time modder, I appreciate the hard work that the MG team put in. MG is a fun and playable game already, by pointing out some of the above issues I am simply trying to give ideas that I think would improve the player experience  :)
Agreed

--

... horrible strong AI and you state its dumb and too easy to win .
To me, strength and wits are not the same. The difficulty to overcome the AI is not its cleverness but its sheer advantage in resources -  if you just keep the multiplier when selecting the MEGA. I wonder how a MEGA 4.9 can be dealt with but I dare say that after having been given the hint to put the resource input at prime I was able to defeat MEGA 2.5, I should repeat it anytime. Is your experience different?

...Imagine the AI would be smart then you would nearly never win.
I don't agree there. If the AI was smarter, you would not have to put the mutliplier so high to still get a decent fight. As far as I have understood, the multiplier exists to compensate the lack of wits in the AI. BTW, I very much have the feeling that AI does not suffer from the fog of war. The AI headed to my base straight away. I have never experienced reconnaissance missions by the AI.

...For example Ultra and Mega fight a bit smarter by attacking standing units in range first. Of course they do this just in some rare cases, because I added a low chance of doing this ( ultra does it less often than mega does it). Imagine I would raise this to 100%. All your archers would be killed within seconds and you have no chance to controll this as fast as a computer can do this!
So in several places it would be really easy to make the AI smarter.
I quite agree that one would need to get some automation to compensate the AIs vast advantage in control speed of the units if one wanted a smarter AI

You already complain about wanting less micro management, I bet you would even cry more if I make the AI smarter and stronger.
I am sorry if my suggestions came across as complaints. It was not my intention.

In the end this would lead to a half automated AI fights were you can make some strategic decisions, so a completly different game! ... Micromanagement is an important part of this game!
Sorry, my believe is that it IS already half automated AI fights. I cannot imagine that one can control 50, 30 or even only twenty units in a fight - not efficiently at least. Sure, you can group the units but they tend very much to get different amount of damage so one might want to retreat all but the healthy and only lightly wounded. This is not possible without loosing control. Either, you select the ones to retreat one by one and order them out of battle to discover them shortly after in the fight again because you ordered their group on the next target or either you cannot us the group any longer, or you get the whole group out of combat or you just sacrifice some  of them while the group stays in action. Another example: My experience is that it is useless to put more than two or three melee units onto one single field target (the majority of the foe's units, I am sure). If I put more they get in each others way or - being as likely as former said - the are blocked by other enemy units thus running around them and getting hit for nothing. As for range attack units it is slightly different. I guess you can target about 5 units on a still single field enemy unit. If you put  more, the surplus range attack units need to go around the front line 5, being hindered by other units of yours or the landscape artefacts. Having said that a fairly decent army of 20 units would end up in at least 3 groups. Maybe I am just not quick enough but I just cannot control three groups in a battle. I just cannot distinguish which unit belongs to which group thus rendering groups almost useless for me. And - what I have seen in the coop games suggests that much more experienced players operate battles - not skirmishes - like me. They throw in as many units they can grab, retreat the whole lot if there is too much damage to a certain gut feeling "percentage" of units and hope apart from that most of them survive. I do not call this micromanagement. That is, politely speaking, just very crude tactics. The single unit certainly controlled by the computer instruction set for the unit and only now and then a human command.

If you want this you must play another game.
As I stated in my initial post. I did not put my points in as feature requests - andy5995 move the post thankfully to the right forum - because they would alter the character of the game vastly.

Beside of this I myself am pretty sure if the the AI would be smarter, the game would be a lot less fun!
This is subject to the eye of the beholder, imho.

This would mean you need to lower the AIs general production rate to give a human player at least a tiny chance to win.
I do not consider this to necessarily be a bad thing. After all, if the AI would get smarter siblings one was free to choose which way to go.

So just some units on the field and not those big attacking ( and yes often a bit dumb ) armies that attack you now! But would that be fun ? The motivation is a bit like in the "serious sam" or tower defense games, you as a player feel really good if you can stop a huge army because you fight smarter than the attacking AI! And you feel even better if you can do this with a human team in a coop game!
It can be fun to watch a cillion of units bustling about knocking each others heads off of which I only get some glimpses because there happens so much in so short a time. Personally, I get rather bored after the fifth time or so. I play games to influence things and an epic slaughter is rather a film to me.


8
MegaGlest / Re: My impressions and thoughts
« on: 21 March 2017, 14:31:23 »
:-) know these discussions. I actually do not see why one should not implement both such that the player can choose the behaviour.

9
MegaGlest / My impressions and thoughts
« on: 20 March 2017, 22:21:47 »
After a some 10 games my impressions and thoughts. Not sure if to distil them into feature requests as they might alter the character of mg entirely. I would happily discuss the points, however. If it would be best to move the specific points into separate threads or point to already existing threads I shall do so or feel free to do it yourself.

I think it is already a great game. I am really amazed once again how good the quality and functionality of OSS can be. I do not want to imply that OSS developers (and - sorry for not mentioning all on by one - others having their share with bringing OSS to us) are less gifted than paid one. I just refer to the thing that not too many people can afford to spend a big deal of time in unpaid work - I imagine.

My overall impression on MG is that it is quite close to WarCraft. The general setup is acquire resources, put them to good use and defeat the opponent is the strategic aspect that compels me.

However, I feel that the weakness of WarCraft is present here. To me it very much feels that the AI ranges from dumb to particularly dumb - I mean no offence with that and will detail in a second. My feeling about stronger AI is basically - as in WarCraft - that the AI has more initial resources and perhaps some production/harvest/mining speed advantage. I did not test it out. For example I just finished a custom build where on Tropical Arena with a CPU Mega. Eventually I lined up a couple of sphinxes behind a ridge of rocks. AI kept sending its units just along the other border and they were grilled by the sphinxes when passing them. The first unit got through almost unscathed but could be finished off by my other units easily. All following where sent through hell dying or getting out almost dead.

I am not happy with some behaviour of the units. E. g. they do not try to avoid fire if they move to a certain point. Then, the units with distance attacks fire to the spot where the enemy is at the time of firing not taking into account the enemy's movement.

To me, there is a big imbalance between strategy and tactics. Maybe this is inherent in the setup. There is no way a human can control its units as fast as the computer. I mostly find myself deciding, I have not got the time to do this or that. E. g. with an ongoing battle I neglect my harvesting and unit production. While being in a game me against an AI I can pause the game and only blame myself if not doing so. But in network games with more than one human player I cannot. Sure, other players are much, much better in controlling their units, I just do not know how - maybe it’s just me being slow because of age and lack of practice.

Coop games are not so cooperative in my opinion. The ones I have played felt like, each one tried to build up as much momentum for oneself and targets the enemy wherever she sees fit. Sure, one cannot oblige the players to cooperate closely but it is too easy not to do so and still succeed.

I think it is good that one can control everything of the units and it is bad that one is obliged to.

To me the current setup boils down to a battle of material in the sense of “who is able to produce faster than the other” putting a strong emphasis on the strategic aspects of the game thereby neglecting the tactics do to lack of deputising.

Some possible improvements (I do not repeat point I already found in the forum)
a) I would like to be able to tell a building to keep training unit XYZ as long there is enough resources where enough also could be a threshold of the resources defined by me.

b) Make the units smarter such that the majority tries to avoid fire if moving to a point. Maybe its ok for Golems and the like not to. Make the units with range attack take into account the movement of their target.

c) Make unit groups concentrate attack. If I group units they only act as a group if I explicitly tell them what to do. E. g. I tell group one to battle enemy unit x they do, but when that unit perishes, the group members start to fire “randomly” at enemy units. I do not see why they should not pick a common target again. It could be implemented as follows. I make some presumptions. All units get investigated one after another. For the inspected unit it is decided if the unit continues its action or if a new action is set up. If the unit loses its attack target it picks a new one. So if the unit belongs to a group it gets the group target if there is one, if not, it just picks one the way it is done already and that target becomes group target. I see that in the heat of the battle it is not so realistic that one can identify (immediately) the aim of the others of the group. Therefore one could introduce a random element to make some individuals aim not at the group target. One could argue that those dumb rookies from factory are just incapable of coordination but I doubt that reflects sort of reality. Sure they would improve in finding the group target with raising experience but the attempt should be there from the beginning. One could also define a leader unit - be it a special unit type, be it an especially experienced unit - that has to be present in a group to have the advantage of coordinated actions. I guess it also would be a good idea if the factions should have varying effectiveness of coordination. The romans for instance are know to have had very extensive military drill such that their discipline was very high being precondition for extended coordinated actions.

d) Give the units an operation mode where they retreat fighting such that they preserve health by losing ground. Problematic is to define where to they ought to retreat.

e) I would like the units stop immediately when they have killed there immediate target and there is no alternative target in sight - literally. Why do they run to the spot of death of their "victim"? To see how it decomposes? I usually do not want it and would like to have a button to deselect this behaviour.

f) I would like to tell units with range attack to fire behind the nearest line of enemy. I mean, I can have so much collateral damage I am not sure whether to use a sphinx, archmage, dragon, ... or not. Is the damage of a splash attack a function of the distance of the affected spot to the centre of impact? It would make sense to me.

g) I would like to be able to build up a firewall ;-) . I. e. that range attack units keep firing on a spot no matter if there is a enemy unit or not. On the other hand, if the units themselfs got smarter, they ought to avoid such spots (running into my next ambush ;-) ).

h) I would like to be able to give my units standing orders. E. g. my healers at times run into battle even though they are not yet affected by them or even in danger to get affected. So I would like to tell them that they ought to hold position and e. g. after having healed another unit, switch back to hold position.

i) I like the idea of healing very much but in my opinion it is too tedious to be much of use. I have to tell which healer unit is to heal which unit. Totally impractical especially in combat. I would like to see some hospital areas. I imagine several variants of these areas. i. Some radius of a "healer" unit the healer automagically starts to heal if a wounded unit enters it. ii. Mark an area on the map healing ground and staff it with healers. Every unit in that area with healers gets healed eventually. iii. Special hospital buildings that need to be staffed with healer units and units to be healed need to enter it.

j) Having healing areas I would like to be able to tell my units to seek healing and they move and look for it autonomously. After being healed they either return to their previous position or stay just outside the healing zone. So those could be to separate actions or one action with a switch.

k) I would like to be able to tell my units to employ guerilla tactics when attacking. E. g. I do not see common sense in it that an archmage stays longer than necessary in the brunt of the battle especially if he has run out of energy.

l) I would like to be able to give general guidelines of behaviour ranging from "keep out of trouble" over "have good own damage to enemy damage ratio" to "hack and slay no matter what".

Maybe my ideas would lead to a boringly slow game. Sure it is supposed to be real time strategy game but why is it possible to pause or change the speed of the game then anyway?

Cheers

Thiemo

10
Feature requests / Re: Randomly generated maps
« on: 20 March 2017, 11:54:57 »
I very strongly second the idea of random maps. I just think fog of war is partially rendered useless on known maps. As I recently was told in a coop game, the are more resources in the centre of the map... do not be offended, it just natural to take into account what one knows. It is just hard to try to ignore it and I feel it is rather impossible to ignore all one knows as player about a known map that the faction cannot know at the beginning. I see it with myself. I played oneOnOne several times mostly to try out a new faction. After the second time I knew where the gold resource are and I could safe the effort for reconnaissance missions. I do not know, however, if this is an advantage over the AI.

11
Feature requests / Re: record games
« on: 20 March 2017, 11:39:33 »
I think I have seen such a feature in a mac game many years ago. It's cool. I am not sure if the purpose solely to get a film to watch again (and again and again ;-) ) or the command data shall be kept for analytics. If the later is not of importance, one could implement a tool that takes the recorded command data and "converts" them into a film saved as mp4, avi, matroska whatever format. (how have the MegeGlest films created that are on youtube?) The films might be advertising materials or one could make them a library where one could research about tactics.

12
Feature requests / Re: toggle auto-attack mode
« on: 20 March 2017, 11:28:56 »
I feel there is much overlapping to https://forum.megaglest.org/index.php?topic=9819.0

13
I can see the pros and the cons. Personally I was rather affected by the losses as described by the initial post. However, would it be possible to have a building setting that can be switched on/off? Following two "implementations" come to my mind.
a) An additional switch in the building which affects the mode the new unit is in when leaving the building. Default (switched off) might be "move"; switched on shall be "attack".
b) Two meeting point flags of which only one can be set at a time. One makes the new units just move to the meeting point, the other makes them maraud to the meeting point.

I can even see the point in having a third mode where new units sneak to the meeting point, trying to avoid confrontations. I. e. if the unit gets to see an enemy unit, it tries to navigate around it like around an obstacle but with a radius around the closest enemy field equal to the sight range + 1 of the new unit. I assume here the new unit does not know about the sight range of the enemy unit. This seems to me quite natural since they are rookie units.

14
Oh, that's great!  ;D I should be able to get 30 - 50 minutes free from my family :angel:

15
Thx!

Coop sounds good. How long do those last? How much time would I spend?

16
Hi titi

Thanks for the answer. I gather it is lack of tactics. I shall tune mine then. I successfully defeated (kind of pleonasm) the CPU ultra 1.5.

Kind regards

Thiemo

17
I'm rather new to MegaGlest - many thanks to all the authors of the game, it's just great - though I have played WarCraft I and II quite a while.

Now, I played the tutorial and tried some scenarios before I set up my own. I started with the eight opponent wheel where I made two parties. All CPU Mega 2.5 apart from me. I placed myself in the centre as Indian the others "equally" spread at the perimeter with random cultures. I invariably was eradicated rather sooner than later. I then placed an opponent in the centre and myself at the outside. In one occasion we won and I survived but just so. I came to the conclusion that the centre (because/despite of the narrow space) is a big disadvantage as the centred opponent vanquished first as well. I began to wonder how bad I am at glesting so I set up a one on one encounter with a CPU Mega 2.5 Indian against my tribe. I did not survive. In the end I was just flooded by enemy units. Now, I play a against a CPU Ultra 1.5 Indian with my tribe and it looks like I am quite in control. My lines are not torn thin (yet). So touch wood.

My strategy changed from stressing technology over quantity of troops to quantity of troops over technology. Background of the initial decision is that I am no way as fast as CPU to control many units. I eventually found out about the pause and game speed button so this disadvantage has much less weight now allowing me to change my strategy.

Initially thought that Ultra/Mega was kind of synonymous to the multiplier, but after searching the forums I came to the conclusion that Easy/Ultra/Mega/(Normal) are a qualifier for the intelligence of the CPU's strategy. I also found the multiplier to be a multiplier of resources and I assume that 1.0 means equal to human players. But now, is the multiplier applied only to the starting resources or is it production speed too? To me, it surely feels as if it affects production speed. But I could not find documentation. Did I miss it?

Should a CPU Mega 2.5 be a piece of cake? Can one only win against in a special setup (I had one 8 opponents setup where one of the CPU Mega 2.5 opponent was just next to me - both Indians where I was able to raid it before it could bring its resource advantage into account)?

Kind regards

Thiemo

Pages: [1]