Messages

1

Bug reports / 3.11-beta2.0: attack_stopped targets are different from normal attack targets

« on: 3 January 2015, 01:33:41 »

Normal attacks basically target the closest unit with an attack skill, or if none exist, the leftmost in-range enemy unit (with no attack skill of course).  The target is chosen in the function attackableOnRange in source/glest_game/world/unit_updater.cpp.

The attack_stopped skill (hold_position, towers), however, only attacks the leftmost unit, regardless of whether it has an attack skill.  This often results in a single unit drawing fire from all towers that can fire at it, often resulting in a waste of shots.  Also, it causes tower performance to vary depending on the direction of the attack--players attacking from the left will have their ranged units attacked first by towers.

This is because the function updateAttackStopped finds its target using unitBeingAttacked, which just gives the leftmost unit.  It also has a use of attackableOnRange like the normal attack does, but only if unitBeingAttacked fails, and I don't think that branch is ever followed when there is actually anything to attack.

Thus, applying

Code: [Select]

[url=http://pastebin.com/imfv9kcK]this diff[/url] results in the same behavior for attack_stopped as normal attack.

Code: [Select]

[url=http://s000.tinyupload.com/index.php?file_id=05647447169642467245]This scenario[/url] may demonstrate the inefficiency of the leftmost-first targeting in the case of anti-air towers.  Leftmost-first targeting also means that towers with reduced range (e.g. 12 instead of 15) can be more effective than those with greater range, since they will have different targets and thus waste fewer shots.

Leftmost-first doesn't matter as much when there are only units that can't attack, since players are usually in the "destroy the helpless base" stage of the game when that happens.

2

Closed bug reports / [fixed]v3.11-beta2.0: colorpicking order of dead units is wrong

« on: 2 January 2015, 17:14:18 »

The order of colorpicking is sometimes wrong.  It is most noticeable when you are in a battle that produces lots of dead units and you want to select/target a live unit; it seems that for colorpicking, dead units are drawn above live ones.

I can't reliably reproduce the screenshot-during-selection bug/feature, but I got screenshots anyway:
https://imgur.com/a/EIUtG

The archmages are standing on top of a pile of dead daemons, but they are below the daemons for colorpicking, making them difficult to select.

This may be related to what will pointed out in https://forum.megaglest.org/index.php?topic=9308.msg89443#msg89443 .

3

Closed bug reports / [fixed]Range upgrade is always displayed as "+1"

« on: 30 September 2014, 02:33:09 »

This seems to be an old bug.

The relevant code is here.  Removing the "!=0" on what is now line 269 should fix it, as noted in the other post.

4

Closed bug reports / [invalid] 3.10.0-dev 4808.30d3626: bugs with shared resource caps

« on: 27 September 2014, 06:25:38 »

Shared resources were introduced here.

There are bugs in the implementation that are visible when one player is a net consumer (negative resources) and for another is a net producer (positive resources).

The bugs are most visible when the producer reaches the shared resource cap.  For example, one faction, a producer, might have 4000/2000 gold when total storage is 4000, (2000 for each faction), while the other faction, a consumer, might have -3900 gold.  The combined gold of the two factions only 100, but now, the producer cannot store any more gold; the only way for the team to get more gold is for the faction with negative gold to produce some.  This kind of situation might occur when players agree to handle different roles (e.g. resources/combat), or when one player is a human and the other is CPU.

Now destroy the producer's storage building.  The team's storage capacity decreases by 2000.  However, the producer now has 0/0 gold--it decreased from 4000/2000!  The consumer still has -3900 gold, so the team now has -3900 gold.  The consumer now has to make up the gold debt before anything else can happen.

Desired behaviour:
There should be no resource cap per player; it should be possible for two players to respectively have, for example, 10000/2000 and -9999/2000, for a team total of 1/4000.
The individual resource count/cap should only be the net produced/consumed, which is just some possibly interesting information; it should have no effect on the game.  Only the team total resource count/cap should matter.
When storage capacity is destroyed and it is necessary to cap the team's resources, it should only be decreased to the team's total storage cap; the deducted amount can be subtracted from the destroyed player's resource count, if it is necessary to keep track of that, but again, the individual resource counts should have no effect.

5

Closed bug reports / Re: r2797: Forcing IRC nickname change

« on: 14 September 2014, 19:33:26 »

The relevant code is in this source file: https://github.com/MegaGlest/megaglest-source/blob/develop/source/shared_lib/sources/platform/posix/ircclient.cpp#L320

To me, it looks like testing code that wasn't removed.

Besides "nick", "quit" (result: quit IRC with reason "of course, Master!") is notable.  Making other clients quit probably isn't so funny.

6

MegaGlest / Re: Headless server minimum players

« on: 4 May 2014, 15:06:34 »

Actually, you can set MinHeadlessPlayersRequired in the configuration.  This is an undocumented option, but you can find it in this file.

7

MegaGlest / Re: A first cup to begin this idea ^^ (enrrollment)

« on: 17 March 2014, 20:20:12 »

deadline for enrolling : Saturday 30 October 23h59

I suspect there is a translation error.
2014-10-30 is a Thursday.  The next *-*-30 that is a Saturday is 2014-08-30 (August 30).

The "Oct" in October might be confusing.  October used to be the eighth month of the Roman calendar until January and February were inserted at the beginning.

8

MegaGlest / Re: New team play features coming soon

« on: 14 February 2014, 00:34:56 »

Would it be possible to replace the cpu with some sort of dummy unit so that I have entire control of the other player?

If you modify lastCustomGameSettings.mgg, you can set FactionControlForIndex#=7.  Then you can reload the last settings, and that faction will be under "Human" control--the AI will be disabled.  If you have multiple factions set to human control, then only the last faction is actually under your control ...  but if team unit sharing is on, you can control all factions on the same team.

9

MegaGlest / Re: running multiple headless servers on one host

« on: 10 February 2014, 03:08:56 »

For the stop file, would the server have to poll for its existence?  I guess it's not such a big deal if you make it sleep between checks, and headless server seems to already use a busy loop when it's idle (version 3.9.1; estimated about 4-5% of a CPU core), but it would be useful to eliminate this if you want to run multiple servers on one machine.

I think signal handlers could work too.

So, for example, there could be a signal handler for SIGTERM (or some other signal) that makes the server quit if no game is in progress, or if a game is in progress, exit after the game is over (i.e. set "exit" mode if it is not already set).

Then you can do "killall megaglest", and all idle servers will quit immediately, but other servers will wait until they are finished, then quit.

10

MegaGlest / Re: Problem magic strategy

« on: 25 January 2014, 04:20:39 »

Put your golem and maybe a summoner guild in the front of your base.  When or before the CPU enemy makes its first attack, morph perhaps 5 or more initiates into battlemages.  The CPU enemy should mostly be attacking the golem and/or summoner guild, and you should be able to kill the first wave without any battlemages dying.

After the first wave, you can try to attack the CPU enemy immediately, since it will be at its weakest.  Avoid towers, and you should be able to defeat many of their combat units in detail while you continue to harvest resources and get a larger army.

Also, your mage tower should almost never be idle in the first few minutes of the game, unless you need to spend gold early (e.g. to make battlemages for rushing or to quickly make a new mage tower) - in general, it should continue sending initiates to mine gold until the local gold is almost saturated with initiates, at which point you should probably still be making more initiates to build stuff or to convert to battlemages.

11

MegaGlest / Re: Comparing units

« on: 22 January 2014, 04:53:40 »

Golem has 2000 hp (stone), 45 armor, 10 range, 200 impact damage * 0.6 Hz, 3 hp/s regeneration
Behemoth has 5000 hp (organic), 50 armor, 1 range, 325 impact damage * 0.75 Hz, 5 hp/s regeneration

Against non-impact attacks, 2000 stone hp (0.5 multiplier) is equivalent to 4000 hp, and 5000 organic hp (1.25 multiplier) is equivalent to 4000 hp, so golem and behemoth have basically the same damage absorption ability.

Range isn't really useful for the golem; its attack strength is only approximately that of one battlemage, and its purpose is to absorb damage, not to deal damage.  Behemoth is much more useful for absorbing damage since golem is too slow to even get into a battle, unless the battle comes to it.

And if it's a defensive situation, the summoner guild is the best unit for taking damage.  7000 stone hp, cheaper than golem, and gets built faster too.  It doesn't attack, but that doesn't matter.

So in my opinion there is almost no reason to build golems.

Golem:
+ can be repaired (rate: 7 hp/s/initiate)
+ has large range
+ can hold position
+ regenerates faster than behemoth (golem: 3 hp/s (stone)=6 hp/s; behemoth: 5 hp/s (organic) = 4 hp/s)
- can't move well
- does not do much damage

Behemoth:
+ can move much faster than the golem can
+ levels up in 5 kills, vs 10 kills for golem
+ does twice as much damage as golem
+ tougher against impact attacks
- can't be repaired
- short range
- can't hold position (but this is not very useful for short-ranged units)
- needs Hell Gate to be built

Summoner Guild:
+ 7000 stone hp
+ can be repaired (rate: 35 hp/s/initiate)
+ built quickly (about 1 minute at 105 hp/s)
+ can be built from the beginning of the game
+ cheap
+ can store wood
+ can make summoners
- no armor
- does not regenerate
- does not attack
- does not move

12

Feature requests / Re: Expand minimap when selected in game menu

« on: 5 January 2014, 08:45:49 »

When connected to a server it is possible to click on a button when the map is displayed.  Custom game menu is fine though.

13

Bug reports / headless server generates infinite output if stdin hangs up

« on: 5 January 2014, 07:41:10 »

When the "vps" option is not used, headless server generates repetitive output if nothing is connected to the write end of stdin.
Try this in the shell:

Code: [Select]

$ megaglest --headless-server-mode > file &
$ ^D
This leaves megaglest alive in the background until it is killed.
file will be full of

Code: [Select]

server command []
error in file descriptor
hang up in file descriptor
server command []
error in file descriptor
hang up in file descriptor

Or try this:

Code: [Select]

$ cat | megaglest --headless-server-mode
^D
to get a lot of

Code: [Select]

server command []
hang up in file descriptor
server command []
hang up in file descriptor

The process should not try to re-open stdin after it fails to do so, since it is likely that the write end of stdin will never be open again.  The only exception I can think of is if stdin is a fifo, but I believe mkfifo fifo; megaglest --headless-server-mode < fifo & echo > fifo ... and later, echo "quit" > fifo is an unlikely way to run it.

(edit: fix typo in first command)

14

Feature requests / Re: Expand minimap when selected in game menu

« on: 4 January 2014, 02:18:13 »

When the zoomed map is rendered, clicking should only dismiss the map, nothing else.  Right now it is possible to (accidentally) click on something when trying to dismiss the map.

15

Bug reports / 3.9.0: LAN server connects to other computer(s) on local network and freezes

« on: 1 January 2014, 08:11:29 »

This could be related to my current local network, but I am not sure.

I hosted a game with publish disabled.
After waiting a few seconds, I clicked "Return"; the game froze on this screen: http://i.imgur.com/9PwLTdk.png

I opened a terminal and ran netstat -pant; this was the output:
(note: command for starting megaglest was megaglest-3.9.0/megaglest)

Code: [Select]

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 127.0.0.1:61355         0.0.0.0:*               LISTEN      3666/megaglest-3.9.
tcp        0      0 0.0.0.0:61357           0.0.0.0:*               LISTEN      3666/megaglest-3.9.
tcp        0      0 0.0.0.0:61358           0.0.0.0:*               LISTEN      3666/megaglest-3.9.
tcp        0      0 172.16.1.38:46767       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:32881       86.65.39.15:6697        ESTABLISHED 3807/irssi         
tcp        0      0 172.16.1.38:46770       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46772       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46775       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46771       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46769       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46773       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46768       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46777       172.16.1.35:2869        ESTABLISHED 3666/megaglest-3.9.
tcp        0      0 172.16.1.38:46766       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46774       172.16.1.35:2869        FIN_WAIT2   -                   
tcp        0      0 172.16.1.38:46765       172.16.1.35:2869        TIME_WAIT   -                   
tcp        0      0 172.16.1.38:46776       172.16.1.35:2869        FIN_WAIT2   -                   

172.16.1.38 is the computer I ran MG on; OS is Gentoo GNU/Linux; it is a laptop, connected by wifi.  The binary was compiled from megaglest-source-3.9.0.3.tar.xz.
172.16.1.35 is a desktop computer running Windows 7, connected by ethernet.  It does not have MG installed.  I do not know what is listening for connections on 2689 on that computer, or why MG tries to connect to it.

MG froze for a few minutes before it returned to the menu.  I also tried it again for more testing; it would not respond to ^C (SIGINT) on the command line, but did close as a result of closing the terminal window (SIGHUP).

When I ran with megaglest-3.9.0/megaglest --headless-server-mode=lan, I also saw connections to 172.16.1.35:2869.  I opened some MG clients and joined (on 127.0.0.1:61357), and then started the game; the clients were stuck waiting for the server for some 160 seconds before the game started.

When left alone, the headless server stopped connecting to 172.16.1.35 a few minutes after starting.

16

Bug reports / 3.9.0 & f06d474.4541: game results time does not account for game speed changes

« on: 25 December 2013, 18:41:19 »

If the game speed is changed using + or -, the new game timer will speed up or slow down accordingly.  The game duration displayed at the game results screen (and also on play.mg -- test with a single-player network game) does not take into account game speed changes.

To reproduce:
Start a new game.  Press + until the game is running at 8x, and wait for some time.  Pause the game, noting the displayed game time (if on git head), then quit, and note that the time on the results is different.

17

Feature requests / Re: Game Timer

« on: 25 December 2013, 18:26:51 »

I think the text is too long now -- it doesn't fit in the area under the minimap.

The real time is not necessary since most people probably have another clock available.  The text "Game duration" is probably also not necessary since it's rather obvious what a counter that starts at 00:00:00 and increments every second is.

18

Bug reports / 3.9.0: enemy units should be visible if *any* part of them is within sight range

« on: 21 December 2013, 05:03:42 »

Currently, enemy units are only visible if their "center" (the cell that splash is centered on, I assume) is in sight.

This can result in situations like this image:
http://i.imgur.com/YWbxDCd.png

Tech catapults have attack range 10 and sight range 11.  They are attacking a tech castle.  The castle is invisible because it is not in sight range, but part of it is in attack range.

To fix this, the enemy unit should be visible if any cell that it occupies is in sight range.

19

Feature requests / Allow typing values in custom game menu

« on: 21 December 2013, 04:45:23 »

In the custom game menu, if there are a lot of maps or tilesets installed, it can be difficult to select the desired one since the user has to do O(n) clicks if there are n items to choose from.  Changing the CPU multiplier also requires unnecessarily many clicks.

I suggest that if the user clicks in the gray area of a setting, it becomes editable (like the area for the name).  The user then is able to type anything into this area.  This would be easier to use than shift+letter+click, which can be hard to do even for an Emacs user (e.g. try shift+M+click), and doesn't work for map names starting with numbers.

If the user presses Enter, the setting is set to the appropriate value, if found; if an invalid value was entered, it reverts to what it was before.  The search should be case-insensitive and treat underscores and spaces equally.  If the user presses Escape, the field should be reverted to its previous value (i.e. no change).  Tab completion would also be useful.

Examples:
User enters "Conflict" in map area; map is then set to "Conflict".
Current faction is "Magic"; user enters "NotAFaction" in faction area; no such faction exists, so the faction is not changed (remains "Magic").
User enters "3.2" in CPU multiplier area; the CPU multiplier is set to 3.2.
User enters "0.4" in CPU multiplier area; the CPU multiplier is not set (it is out of range).
User enters "one king rules them all" for map; map is set to the file "one_king_rules_them_all.gbm".
User enters "One king Rules them All" for map; same result.
User enters "one_king_rules_them_all" for map; same result.
Current map is "Conflict"; user types "one king rules them all" in map area and presses escape; map remains "Conflict".

20

MegaGlest / Re: Weak factions?

« on: 16 December 2013, 04:19:10 »

Magic's my favorite faction, so I don't think you're getting yourself into trouble .

Magic has the following weaknesses compared to other factions:

• Initiates mine significantly slower than workers of other factions due to the combination of slower mine speed (200 vs 225 gold per second), smaller load (20 vs 25 gold), and slower walk speed (150/130 vs 190/190 unloaded/loaded).  Initiates do harvest wood faster (200 vs 150 wood per second), but this is not very significant since Magic doesn't use much wood.
• Magic's air units are among the worst. Dragons do 250 damage at 40 rate, which is less than the similarly-priced units of other factions such as Thunderbird (250 at 70 (ground only)), Flyingvalkyrie (270 at 50), and Ibis (170 at 100).  Evil Dragons do 450 damage at an effective rate of 20 due to their EP requirement, which is about the same damage per second; their advantage over normal dragons is increased hp, better burst damage (especially when leveled up), and range, but they cost even more.
• All other factions except Norsemen have a ground-attacking range 12 defensive building.  Magic does not.  The closest unit is the golem, but it only has 10 range and 2000 hp (stone) and does only about 1 battlemage of damage on average.  A summoner guild, although it has no armor, does no damage, and can't move, is a cheaper and more effective defense building when combined with an army of mages who do the damage while hiding behind it.
• Most other factions have an effective cheap melee unit.  Egypt doesn't have an effective cheap melee unit in my opinion (mummy and spearman are too weak), but it has Anubis Warrior, which is fast and tough and doesn't get killed by snakes (whose splash does not damage friendly units, unlike archmages).
  Magic has no effective melee unit.  The daemon has 500 hp organic, which is very weak, and ghost armors tend to get killed by battlemages when they move into the place of a dead enemy and get hit by spells targeting the dead unit.  This is even worse with archmages since the archmages are almost guaranteed to kill all friendly melee units with splash.  Titi tried to make ghost armor less useless with the last balance change by making it cheaper and faster and allowing its armor and damage to be upgraded, but I still don't use it much (although this is partly because in team games, other factions make melee units for me).

But Magic has the following unique strengths, which may or may not make up for the weaknesses:

• Battlemages (when they have EP) are more powerful than archers of other factions, although their range is slightly worse.  I believe their strength is also what makes ghost armors almost useless, even though ghost armors are now among the strongest "metal melee"-type units -- it does not take very many battlemages in a group (exploiting their range) to be as effective as the same number of ghost armors.
• Also, they are morphed from initiates, which means that making more initiates than necessary for work is not a waste of gold, since they can be converted later if it becomes necessary.
• Archmages are extremely effective against ranged units and buildings when used correctly ... but it is difficult to use them correctly.  You have to worry about friendly splash, running out of EP, and inability to retreat quickly.
• Initiates also build the mage tower faster than other factions build their main buildings.

21

MegaGlest / Re: How exactly does Food work?

« on: 8 December 2013, 18:57:00 »

loosing 200 HP per game cycle

For a 600 HP worker, this is correct.  In the general case, units lose floor((Max pre-level HP)/3) per food cycle.

Thus workers (600 HP, 200 HP/cycle) and unleveled guards (900 HP, 300 HP/cycle) die in 3 cycles, and swordmen (700 HP, 233 HP/cycle) die in 4 cycles.  Elite guards (1350 HP, 300 HP/cycle) die in 5 cycles.

22

MegaGlest / Re: Production Time and Seconds

« on: 8 December 2013, 00:52:03 »

Well, you can get the gold harvesting speed using a similar formula.
Worker has 225 mine speed, and just divide this by 100 to get 2.25 gold per second.
Of course, the worker then has to walk back to the main building, and the distance varies.

I think you can do (walk speed)/100 to get the number of squares per second a unit moves too.

23

MegaGlest / Re: Production Time and Seconds

« on: 7 December 2013, 23:58:12 »

Actual production time depends on production speed of the thing producing it.

A worker (time=40) is produced by the castle, which has production speed 300.
A barracks (time=100) is produced by the worker, which has build speed 105 and repair speed 40.

The number of "productions" per second is ideally (production speed)/100, although it may deviate from this slightly if the number is not a factor of the frame rate (40/second).

So the expected actual worker production time is about 40/3=~13.3 seconds, and the barracks production time is 100/1.05=~95.2 seconds.  Again, expect slight deviations from these numbers since the divisors do not exactly divide the frame rate.  Also, buildings start with 5% of their total HP, but the build rate is still approximately (total HP)*(production speed)/(time) HP per second.

24

Maps, tilesets and scenarios / Scenario: Break the Turtle

« on: 24 November 2013, 10:30:12 »

Today I spent something like 9 or more hours learning how to Lua and MG scenario.  As a result, I was able to make my first scenario!

I spent much of that time learning more advanced stuff and debugging things and figuring out how MG actually behaves when I try to do insane things ... and I was eventually able to get what I wanted: you are effectively able to choose your faction in this scenario (that's not possible normally, right?  Because otherwise all this hacking would have been for nothing fun).

Other than that, the scenario is just you vs. 17 guard towers, 16 ballistae, and 8 eagle pillars; not too special.  It is not possible to lose since the romans don't do anything; your goal is simply to get through the defense.  But the scenario might be good for testing to see what works against the defense and what doesn't.

Instructions:
At the start, you have to choose your faction.  To do that, kill one worker with the horseman; then the first part of the scenario ends with a call to loadScenario.

In the second part, you will be the faction whose worker you killed in the first part, and your goal is to kill the roman defense in the top left of the map.

Download:
http://www.sendspace.com/file/fryyyp

This scenario depends on some peculiar behavior (bugs I guess, but they probably only appear if somebody like me is trying to do strange things like this) by MegaGlest when it does scenario loading that I don't feel like explaining right now because I need to sleep.  I have tested it on GNU/Linux and Windows, and it appears to work on both, but it might break in the future if the behavior is changed.

25

Closed bug reports / [fixed] 3.9.0: cannot delete characters after clicking on player name in lobby

« on: 19 November 2013, 07:11:24 »

After clicking on a player name in the lobby, I can only delete (using backspace) the number of characters I have actually typed in the chat box.  In the first image I typed nothing and was unable to delete any characters; in the second image I typed 4 characters before clicking the name; I was able to delete the last four characters "_186" but no more.

The text can be cleared by pressing Esc, but this is still a bug.

1: http://i.imgur.com/FGEzLKW.png
2: http://i.imgur.com/msIKDw9.png