Topics

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

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)

6

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.

7

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.

8

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.

9

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".

10

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.

11

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

12

Closed bug reports / [fixed]3.8.0-beta1: evil dragon team color is transparent when not attacking

« on: 27 October 2013, 21:56:49 »

See this screenshot: http://i.imgur.com/b5MoFCg.png

The evil dragon in the center is in mid-attack and has the red team color on its body; however, the other two that are waiting for EP (so they are using the stop animation) are transparent in that area (although the color remains on the wings).  This also affects the animation for moving.

13

Closed bug reports / [fixed] r4635, Windows 64-bit: error when switching languages in custom game menu

« on: 26 October 2013, 23:35:36 »

In the custom game menu I had the default setting but with the second player opened to network, publish disabled.

Then using ctrl-l, I switched to German; no error.  All slots become closed (this should be another bug).  Then switched back to English and encountered this:
http://pastebin.com/raw.php?i=wb4r2jh2
screenshot: http://i.imgur.com/iaIUDxU.png

I was unable to reproduce after restarting the game.

14

Bug reports / Misspellings in Megapack

« on: 20 October 2013, 01:36:01 »

Norsemen faction:
thrull -> thrall.  Thrull is not a word.
med_bar -> mead_bar, and med -> mead.
flyingvalkyrie -> flying_valkyrie.
thortotem -> thor_totem.
*_berzerk (3 units) -> *_berserk.

Indian faction:
firegolem should be fire_golem.
bigtent -> big_tent.
mainteepee -> main_teepee, or perhaps just teepee, since the other tents are called *tent, and "main teepee" sounds boring.

15

Closed bug reports / [fixed] Changing maps in headless server is extremely difficult (3.8.0-beta1)

« on: 2 October 2013, 07:17:46 »

Changing maps as the controller when connected to a headless server is extremely difficult.

To demonstrate: join a headless server that is not yours (I tested on Summoner).  You will likely have a different map set from the server and non-negligible latency.

Then try to switch maps to something alphabetically far away from the current map.  There is no map filter on headless, so you must scroll through the whole list of maps.

Frequently, the map will change by itself to something you have already scrolled past (related to latency, or when you have a map that server does not), thus undoing a lot of clicks if you have been clicking quickly.

Eventually you will probably encounter a map that the server has but you don't.  The selected map is now "***missing***".  Suppose that you do not want to download any new maps, so you decline the download.  The map selection now reverts to the alphabetically first map in your set, undoing a lot of your clicks.  If you were unable to get the map you wanted to select, you probably will not be able to get it now.

If you mv ~/.megaglest/maps ~/.megaglest/maps2 (thus removing all non-default maps) it will get somewhat easier to scroll, but users should not have to do that.

Possible solutions (or feature requests?):
*Make the headless server not need to know anything about the map, so then only the controller's and clients' map sets need to matter.
*Headless server should send the controller a map list upon join, and only those maps that are on both server and controller are scrolled through.
*Make a better selection interface, like a drop-down menu, so that selecting a map does not require temporarily selecting each one of the maps between the current one and the target one.

16

Closed feature requests / Include version string in IRC real name

« on: 16 September 2013, 06:52:35 »

It is not possible to easily determine the MegaGlest version of a player with the name MG_name_### in the #megaglest-lobby channel.  As a result, one may possibly ask to play a game, only to find that the versions are incompatible.

Currently, this is the result of a /whois on a MegaGlest client:

Code: [Select]

/whois MG_lyra_68
MG_lyra_68 [~MG_lyra_6@(host)]
realname : megaglest
channels : #megaglest-lobby
[...]
The current "real name" of all MegaGlest clients is "megaglest".  Adding the version string to the IRC "real name" (e.g. so that it is "megaglest 3.8.0-beta1" in the case of the current beta version) may make it easier to determine a player's MG version--just do a /whois.

It's not possible to do a /whois from within MegaGlest, but this might still be useful to people who sit around in the channel with their IRC clients.

Implementation of this should require adding the version string to the last argument of irc_connect in source/shared_lib/sources/platform/posix/ircclient.cpp lines 790 and 1001.

17

Closed feature requests / [done] Shortcut key for attacking should cycle through attack skills

« on: 20 February 2013, 04:35:44 »

Pressing the shortcut key for attacking (default is 'A') selects/deselects the primary attack for the selected units.  There is no keyboard shortcut I know of that allows for selecting the secondary attack, which is selected by clicking its icon or automatically activated by attacking (right-clicking) a unit that can be attacked by secondary but not by primary.

I propose cycling through the attack skills, so e.g. if Tech's Battle Machine is the selected unit, pressing 'A' would select, in order, Attack->Attack Arrow->no action.

If multiple units of the same type are selected, cycling should work as if only one unit is selected.  If units of different types are selected, only the primary attack should be selected.

18

MegaGlest / Why is the rate of fire is determined by anim-speed, not speed?

« on: 7 February 2013, 19:32:20 »

In the xml for units, there are lines like this:

From tech's battle_machine.xml:

Code: [Select]

                <skill>
                        <type value="attack"/>
                        <name value="attack_arrow_skill"/>             
                        <ep-cost value="0"/>
                        <speed value="52"/>
                        <anim-speed value="65"/>
[...]

In the game, the "attack speed" displayed when one hovers the cursor over the attack icon is the speed value.  One would expect that this is the rate of fire--normally it is, and the units are centishots per second (also, I recommend changing the game text to "attack rate" or something like that, since "attack speed" could also be interpreted as how fast the shots move).  For most combat units, speed and anim-speed for attacking are the same, but for some, like the Battle Machine's attack arrow, they differ.

The actual rate of fire is not controlled by speed as one would expect, but by anim-speed.  To confirm this, change anim-speed to something very different without changing speed.  Or change speed without changing anim-speed.  Notice that changing speed doesn't do anything but change the displayed attack speed, but changing anim-speed has an effect on the rate of fire.

I suppose fixing this will likely affect game balance.  The Indian Thunderbird, for example, has for its ground attack

Code: [Select]

                        <speed value="40"/>
                        <anim-speed value="70"/>
Fixing this would result in a rate of fire reduction by a factor of 1.75.  Of course, I expect that attack speed 40 was the intended speed in the beginning, especially when the stats are compared with Magic's Dragon.


Edit (tomreyn): No [bug] tag, please, this forum is already called "bug reports". Thanks.

19

Bug reports / 3.7.1, L64 - Camera does not stop rotating in free camera mode

« on: 19 January 2013, 17:36:20 »

I'm running version 3.7.1 from the Gentoo distribution, 64-bit.

Assuming the default keyboard layout, enable free camera mode by pressing f.
Press w/a/s/d to rotate the camera.  Instead of the rotation stopping once the key is no longer pressed, it continues rotating forever (if left/right; if up/down, until the camera hits top/bottom) in the same direction until free camera is disabled by pressing space.  If f is pressed again, the camera will rotate by itself in the same direction again.

There is a possibly related bug with the setmarker command, enabled by the x key.  Once x is pressed, all clicks, not just the first one following the keypress, produce a temporary marker on the map, which rapidly gets annoying.

20

Closed bug reports / [fixed] 3.7.1, L64 - Splash attacks do incorrect damage

« on: 14 January 2013, 07:18:37 »

I'm a fairly new player, and I have spent some time playing by myself (attacking my own units) to get the hang of game mechanics and stuff.  One thing I noticed was that if a unit fires a splash attack, then moves before the attack hits the target, the target will suffer less damage than usual.

Today I also noticed that archmages, when doing "hold position", always seem to do the damage of a direct hit to their targets, while units that were closer to the splash center than the target received less damage than the target.

Since I know some programming and this bug was starting to bother me, I decided to look at the source code.

The problem appears to be an incorrect splash center.  If the attacking unit moves, the splash center, for the purpose of calculating damage, becomes the attacking unit's position.  If the attacking unit targets another thing in its range, the splash center is the position of that other thing.  The area of effect, however, is still centered on the attack impact position.  If the attacker does not move, the splash center is the position of the targeted unit.

As a test, I put an archmage at range 4 from its target (another archmage), and fired an ice nova at the target.  By reducing the game speed and pausing frequently, I was able to tell the attacking archmage to move as soon as it fired its attack.  When the attack hit, the attacking archmage had <100 health left (out of 450), and the target had >300.

What I believe is the offending code, in source/glest_game/world/unit_updater.cpp, starting at line 1900:

Code: [Select]

void UnitUpdater::hit(Unit *attacker, const AttackSkillType* ast, const Vec2i &targetPos, Field targetField){
   //hit attack positions
   if(ast->getSplash()){
      PosCircularIterator pci(map, targetPos, ast->getSplashRadius());
      while(pci.next()) {
         Unit *attacked= map->getCell(pci.getPos())->getUnit(targetField);
         if(attacked != NULL) {
            if(ast->getSplashDamageAll()
               || attacker->isAlly(attacked) == false
               || ( targetPos.x==pci.getPos().x && targetPos.y==pci.getPos().y )) {
               attacker->setLastAttackedUnitId(attacked->getId());
               scriptManager->onUnitAttacking(attacker);

               damage(attacker, ast, attacked, pci.getPos().dist(attacker->getTargetPos())); // BUG IS HERE
              }
         }
      }
   }
   else{
      Unit *attacked= map->getCell(targetPos)->getUnit(targetField);
      if(attacked!=NULL){
         damage(attacker, ast, attacked, 0.f);
      }
   }
}

Unit::getTargetPos() returns the target position.  In source/glest_game/world/world.cpp, Unit::setTargetPos is called in World::setUnitPosition:

Code: [Select]

void World::setUnitPosition(int unitId, Vec2i pos) {
   Unit* unit= findUnitById(unitId);
   if(unit == NULL) {
      throw megaglest_runtime_error("Can not find unit to set position unitId = " + intToStr(unitId));
   }
   unit->setTargetPos(pos);
   //unit->setPos(pos,true);
   this->moveUnitCells(unit);
}

I didn't look for where this function is called, but I am guessing it is called whenever a unit moves into a new cell.  Basically, we can't use the attacker's getTargetPos() to determine the splash center.

But the area of effect center is still the projectile impact position, because it uses the function's targetPos argument:

Code: [Select]

PosCircularIterator pci(map, targetPos, ast->getSplashRadius());

Non-splash projectiles also use targetPos to determine impact position.

So replacing attacker->getTargetPos() with targetPos should fix the bug.

Also, http://megaglest.org/linux-packages.html doesn't list Gentoo.  Running emerge megaglest as root will install MegaGlest on Gentoo.