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.


Topics - tomreyn

Pages: 1 ... 15 16 17 18 [19] 20
451
Feature requests / Coherent order of resource requirements
« on: 2 March 2011, 00:02:10 »
I think it would really look nicer if all resource requirements were always listed in the same order: gold, stone, wood, just as they display on top of the screen. Right now, some buildings and units list resources required to build them in this, others in that order...

If this is just dependant on the order the resource requirements are listed in on the XML files, and if everyone is fine with me changing those, then I'll happily do it.

452
This affects both 3.4.0 and r1765:
If a user quits, then a quit message is displayed to the remaining user in the language the quitting user has setup. So if the user who is leaving has setup her game language to be portuguese, but the other users have different languages setup, such as english and french, the other users will still get to see this message about the user quitting:
Code: [Select]
Username: Decidiu sair do jogo!
It seems that some client messages are just passed through as localized strings, not as placeholders which then get translated by each receiving users' game. This would also explain why sometimes you get to see something like ???QuitGame??? when a user quits who doesn't have up to date language files (but you do have up to date ones).

453
MegaGlest / Megapack balancing rants (was: Improvements for Romans)
« on: 27 January 2011, 17:24:41 »
There's two things which I think would be nice to improve about the Romans faction, yet. (I'm not commenting on balancing factions since I'm hardly qualified for it.)

1. Units can stand in the walls of the main building, which doesn't look so nice.
2. Romans' archer models do have a bow, but no arrows. This doesn't look so nice to me, either.

The images below demonstrate these issues.
(click to show/hide)

454
It would be nice to have a glest: URL protocol handler so that you could create web pages with links to game servers using something along the line of
Code: [Select]
<a href="glest:127.0.0.1:61357">my server</a>How to do this on Windoze is explained at MSDN. This could then feed into MG via ./glest --connect=%1. I have not checked how to do this on Linux, yet, but then that's usually the easier part...

455
Feature requests / "Ready" checkbox and timed game starts
« on: 23 January 2011, 17:38:46 »
I was again thinking about how we can have more servers. While I still think having a dedicated/headless server software is the only way to achieve this, there can be another way to achieve it with less efforts involved.

The following new features and changes can get us closer to this:
* from now on, all players connecting to a server become observers
* when they check the newly introduced "ready" checkbox, they will become active players instead.
* the server admin can schedule automatic server starts, based on time ("start this server in 15 minutes") or based on # of connected players ("all players are now connected, please set up your options, the game will start in 30..29..28..27.. seconds")

This would also allow for setting up games where the server admin just keep the computer running but does not actually participate in the game.

456
Bug reports / Bug: one worker fails to build on queued build
« on: 23 December 2010, 01:14:43 »
<tomreyn> if you make one worker build a building, then queue another build job for this one and another worker (who is currently idle) then only one of them (not sure which one) will build the second building,
<tomreyn> the other one will just stand around near the first building
<tomreyn> i have not tested whether this is reproducible but i think it is, since it happened this way to me several times

457
Currently, there are cases when users (re)connect to your game server and show up on the lobby without triggering the trumpet sound. Please make it so that whenever any user connects the trumpet sound will be played.

458
Closed bug reports / [invalid] bone tent cannot be rotated
« on: 20 December 2010, 14:24:40 »
In contrary to all other buildings, the Norsemen's bone tent cannot be rotated. This doesn't seem to make sense and seems like a bug to me. It's been this way since I started playing MG, so this is not a recently introduced bug, it probably never worked.

459
Whenever you click on a menu button you get to hear a clicking sound. Depending on what you click on you get a higher or lower click sound. However, there is no click sound on the 'reload last settings' button in the 'Custom game' menu. I am fully aware that this is really a minor issue. ;-)

460
Closed bug reports / [fixed] r1296, Linux: Still 'freezing' in menu
« on: 17 December 2010, 19:44:05 »
I still have the issue we have seen a few weeks ago. When you start the game and enter the "Internet game" -> "Custom game" menu, your screen output goes dark and stays like this, unless if you're lucky and someone connects to your game host which is when the screen output returns to normal.

Here's some backtraces I made while the screen was black. Note how they differ:
(click to show/hide)

For the record, this is a debug build made with cmake.



tomreyn, 2013-05-26:
This no longer happens on current releases and development builds, so we can safely assume this is [fixed].

461
Closed bug reports / [invalid] End-of-game prompt reacts incorrectly
« on: 17 December 2010, 01:21:26 »
When you get the end-of-game prompt "You won, do you want to quit?" and respond to it by clicking on the right hand side button 'No' you may return to main menu nevertheless. This does not always happen but sometimes.

462
MegaGlest / MegaGlest Website
« on: 1 December 2010, 12:06:18 »
http://www.megaglest.org/

Hey, it's about time that MegaGlest get's a serious website, maybe something like what's on http://glest.org (aside of the forum). I could do the coding for this, but my web design capabilities are basically not existing. So I'm looking for someone not unlike YOU to help out with this. You'd obviously get credited for your web design works for one of the most popular open source games, making it a good reference.

Who would like to help with this?

463
Closed bug reports / [invalid] Issues with RoutePlanner-beta
« on: 2 November 2010, 02:17:37 »
M0ellemeister and I - both on unixoid systems (FreeBSD + Ubuntu) - played a network game with two AIs and RoutePlanner-beta on r1203.

The game did not crash or get out of synch, so I contribute that part to cross architecture games exclusively. However, there were some other issues:

* One of my workers whom I had ordered to walk to some distant place was stuck in the middle, walking down a field from top to bottom (north to south), and once he reached the lower end of that field, would magically disappear, then reappear at the top of this field, then walking the same way again, then disappear and reappear again... a vicious circle.

* Several of M0ellemeister had ordered several workers to walk to another place (probably also a longer walk), and they went in this direction, but after a while they stopped in the middle of their walk. Manually giving them new orders after this worked, though.

464
MegaGlest / Suggested GUI changes for 3.4.0
« on: 26 October 2010, 08:56:08 »
As discussed previously on IRC, I suggest to remove GUI access to the following options:

* Path finder selector: Unfortunately Silnarm's path finder has not been working for us for a while now and it has not been worked on for a while, so at this point it is just an option which will cause crashes, and should thus be removed from GUI. It can remain as an .ini file option, though, so that it can be worked on again later if someone gets around to it.

* Server controlled AI: Client controlled AI does not work too well and has been causing crashes in the past, but server controlled AI works very well. So I recommend to remove GUI access to this option. If, for any reason, client controlled AI would seems to make more sense in a certain use case, it can remain as an .ini file option, though, so that it can be worked on again later if someone gets around to it.

* Shadow mapping: This option does not seems to work for anybody - it seems to always result in a message of "GL_ARB_shadow_ambient required for shadow mapping". So it seems to either rely on an OpenGL extension which is not available in nowadays hardware or it just fails to detect availability of this extension properly. In any case this option is not usable for anyone. So I recommend to remove GUI access to this option - it can remain as an .ini file option, though, so that it can be worked on again later if someone gets around to it. Alternatively, it might be possible to try and fix shadow mapping. Thanks to kobe for pointing this out again recently.

465
I played r1163 and it worked fine for a long time (>=20 minutes?). But then, at once, it segfaulted. I was unable to pinpoint any trigger for this, but the backtrace seems to indicate that this is a bug in the resource cache:
Quote from: backtrace
Core was generated by `./glest.bin'.
Program terminated with signal 11, Segmentation fault.
#0  getResource (this=0xfb83788, unit=<value optimised out>, type=<value optimised out>) at glest_game/type_instances/object.h:51
51      Resource *getResource() const      {return resource;}
#0  getResource (this=0xfb83788, unit=<value optimised out>, type=<value optimised out>) at glest_game/type_instances/object.h:51
#1  getResource (this=0xfb83788, unit=<value optimised out>, type=<value optimised out>) at glest_game/world/map.h:113
#2  Glest::Game::Faction::getClosestResourceTypeTargetFromCache (this=0xfb83788, unit=<value optimised out>, type=<value optimised out>) at glest_game/type_instances/faction.cpp:741
#3  0x00000000005bf485 in Glest::Game::Map::isResourceNear (this=0x396b610, pos=..., rt=0x36dcf00, resourcePos=<value optimised out>, size=1, unit=<value optimised out>, fallbackToPeersHarvestingSameResource=true) at glest_game/world/map.cpp:278
#4  0x00000000005b448f in Glest::Game::UnitUpdater::updateHarvest (this=0x396bb50, unit=0xfdcfa10) at glest_game/world/unit_updater.cpp:666
#5  0x00000000005ae527 in Glest::Game::UnitUpdater::updateUnitCommand (this=0x396bb50, unit=0xfdcfa10) at glest_game/world/unit_updater.cpp:187
#6  0x00000000005b1ef3 in Glest::Game::UnitUpdater::updateUnit (this=0x396bb50, unit=0xfdcfa10) at glest_game/world/unit_updater.cpp:134
#7  0x00000000005c9b24 in updateAllFactionUnits (this=0x396b578) at glest_game/world/world.cpp:251
#8  Glest::Game::World::update (this=0x396b578) at glest_game/world/world.cpp:324
#9  0x0000000000446013 in Glest::Game::Game::update (this=0x396b560) at glest_game/game/game.cpp:696
#10 0x00000000004a55c1 in Glest::Game::Program::loopWorker (this=0x286c9d0) at glest_game/main/program.cpp:297
#11 0x00000000004a1ed5 in Glest::Game::glestMain (argc=<value optimised out>, argv=<value optimised out>) at glest_game/main/main.cpp:972
#12 0x00007f6d21605d8e in __libc_start_main () from /lib/libc.so.6
#13 0x000000000040a209 in _start ()

Please inspect my log file dump megaglest_btrunk+r1163_d20101025-232213UTC_ptomreyntrunk_tsegfault.tar.gz which is available in the usual location.

466
When you only have a single tech tree installed, and thus cannot switch to another tech tree, clicking the arrow buttons to change the tech tree should not reset your faction to 'egyptian'.

467
Slightly rearranged IRC log:

Quote
<tomreyn> softcoder: these changes to how the workers harvest are problematic
<tomreyn> workers stop harvesting, or can not even start to (cancel it as soon as they arrive at the harvesting location, but the order to harvest is still present (yellow arrow))
<titi_linux> the workers are corrupt now
<titi_linux> they often simply stopped
<titi_linux> cpu replace was fine
<titi_linux> and cpu has same problems
<titi_linux> much more stuck than before
<titi_linux> and completly nonsens kind of stuck
<tomreyn> got a screen shot?
<titi_linux> no
<tomreyn> well should be easy to reproduce
<titi_linux> I think its very easy to reproduce
<titi_linux> :)
<titi_linux> but cpu takeover was really fine
<ultifd> can we make it optionable for cpus to replace, sometimes you don't want them to

468
And another segmentation fault in r1089:

Code: [Select]
Program terminated with signal 6, Aborted.
#0  0x00007fcdce108a75 in raise () from /lib/libc.so.6
#0  0x00007fcdce108a75 in raise () from /lib/libc.so.6
#1  0x00007fcdce10c5c0 in abort () from /lib/libc.so.6
#2  0x00007fcdce1424fb in ?? () from /lib/libc.so.6
#3  0x00007fcdce14c5b6 in ?? () from /lib/libc.so.6
#4  0x00007fcdce14ca61 in ?? () from /lib/libc.so.6
#5  0x00007fcdce14f460 in ?? () from /lib/libc.so.6
#6  0x00007fcdce152e83 in free () from /lib/libc.so.6
#7  0x00000000005e7d26 in ~Pixmap2D (this=0x2b8d118,
    __in_chrg=<value optimised out>)
    at shared_lib/sources/graphics/pixmap.cpp:467
#8  0x00000000005f7788 in ~Texture2D (this=0x2b8d0f0,
    __in_chrg=<value optimised out>)
    at shared_lib/sources/../include/graphics/texture.h:104
#9  ~Texture2DGl (this=0x2b8d0f0, __in_chrg=<value optimised out>)
    at shared_lib/sources/../include/graphics/gl/texture_gl.h:47
#10 0x00000000005e553a in Shared::Graphics::TextureManager::end (
    this=0x1ca0490) at shared_lib/sources/graphics/texture_manager.cpp:95
#11 0x0000000000472944 in Glest::Game::Renderer::endGame (this=0x8901a0)
    at glest_game/graphics/renderer.cpp:397
#12 0x000000000044631d in ~Game (this=0x2eeb5d0,
    __in_chrg=<value optimised out>) at glest_game/game/game.cpp:129
#13 0x000000000049e422 in Glest::Game::Program::setState (this=0x1ca0750,
    programState=0x1000b6a0, cleanupOldState=true)
    at glest_game/main/program.cpp:395
#14 0x000000000043f750 in Glest::Game::Game::exitGameState (program=0x1ca0750,
    endStats=...) at glest_game/game/game.cpp:1336
#15 0x000000000049d5f6 in Glest::Game::Program::loopWorker (this=0x1ca0750)
    at glest_game/main/program.cpp:255
#16 0x000000000049a625 in Glest::Game::glestMain (argc=1, argv=0x7fff5414bd88)
    at glest_game/main/main.cpp:950
#17 0x00007fcdce0f3c4d in __libc_start_main () from /lib/libc.so.6
#18 0x000000000040ad09 in _start ()

The corresponding log file dump is megaglest_btrunk+r1089_d20101011-031113UTC_ptomreyntrunk_tsegfault.tar.gz

I hope these issues are actually all the same. I canhardly imagine that so many new bugs were introduced lately... The game seemed and I'd even claim it _was_ pretty stable before 3.3.7 was released.

469
Another segmentation fault with r1089:

Code: [Select]
Program terminated with signal 6, Aborted.
#0  0x00007f9c4d26ca75 in raise () from /lib/libc.so.6
#0  0x00007f9c4d26ca75 in raise () from /lib/libc.so.6
#1  0x00007f9c4d2705c0 in abort () from /lib/libc.so.6
#2  0x00007f9c4d2a64fb in ?? () from /lib/libc.so.6
#3  0x00007f9c4d2b05b6 in ?? () from /lib/libc.so.6
#4  0x00007f9c4d2b0a61 in ?? () from /lib/libc.so.6
#5  0x00007f9c4d2b3460 in ?? () from /lib/libc.so.6
#6  0x00007f9c4d2b6e83 in free () from /lib/libc.so.6
#7  0x00007f9c45256962 in ?? () from /lib/libdrm_intel.so.1
#8  0x00007f9c45256b9c in ?? () from /lib/libdrm_intel.so.1
#9  0x00007f9c45709ecc in ?? () from /usr/lib/dri/i965_dri.so
#10 0x00007f9c45709f85 in ?? () from /usr/lib/dri/i965_dri.so
#11 0x00007f9c4570b889 in brw_destroy_state () from /usr/lib/dri/i965_dri.so
#12 0x00007f9c45712aec in ?? () from /usr/lib/dri/i965_dri.so
#13 0x00007f9c456c383b in intelDestroyContext () from /usr/lib/dri/i965_dri.so
#14 0x00007f9c456b91f0 in ?? () from /usr/lib/dri/i965_dri.so
#15 0x00007f9c4fc9a6d3 in ?? () from /usr/lib/mesa/libGL.so.1
#16 0x00007f9c4fc74788 in ?? () from /usr/lib/mesa/libGL.so.1
#17 0x00007f9c4ff09092 in ?? () from /usr/lib/libSDL-1.2.so.0
#18 0x00007f9c4ff0cfbe in ?? () from /usr/lib/libSDL-1.2.so.0
#19 0x00007f9c4ff0d1d7 in ?? () from /usr/lib/libSDL-1.2.so.0
#20 0x00007f9c4fefec12 in SDL_VideoQuit () from /usr/lib/libSDL-1.2.so.0
#21 0x00007f9c4fed7655 in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#22 0x00007f9c4fed76ee in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#23 0x00007f9c4fed7f7f in ?? () from /usr/lib/libSDL-1.2.so.0
#24 <signal handler called>
#25 0x00007f9c4e4bfa41 in ?? () from /usr/lib/liblua5.1.so.0
#26 0x00007f9c4e4c12ae in ?? () from /usr/lib/liblua5.1.so.0
#27 0x00007f9c4e4b3805 in lua_getfield () from /usr/lib/liblua5.1.so.0
#28 0x000000000060821e in Shared::Lua::LuaScript::beginCall (this=0x2b735e0, functionName=...) at shared_lib/sources/lua/lua_script.cpp:105
#29 0x00000000004585ee in Glest::Game::ScriptManager::onUnitCreated (this=<value optimised out>, unit=0xb7f7a80) at glest_game/game/script_manager.cpp:182
#30 0x0000000000596a19 in Glest::Game::UnitUpdater::updateProduce (this=0x2b72cd0, unit=0xb7f7c80) at glest_game/world/unit_updater.cpp:1119
#31 0x0000000000596fa7 in Glest::Game::UnitUpdater::updateUnitCommand (this=0x2b72cd0, unit=0x93a7e20) at glest_game/world/unit_updater.cpp:187
#32 0x000000000059ad13 in Glest::Game::UnitUpdater::updateUnit (this=0x2b72cd0, unit=0x93a7e20) at glest_game/world/unit_updater.cpp:134
#33 0x00000000005b1f04 in Glest::Game::World::updateAllFactionUnits (this=0x2b726f8) at glest_game/world/world.cpp:251
#34 Glest::Game::World::update (this=0x2b726f8) at glest_game/world/world.cpp:324
#35 0x00000000004432ab in Glest::Game::Game::update (this=0x2b726e0) at glest_game/game/game.cpp:661
#36 0x000000000049d8c1 in Glest::Game::Program::loopWorker (this=0x1909790) at glest_game/main/program.cpp:297
#37 0x000000000049a625 in Glest::Game::glestMain (argc=1, argv=0x7fff6aef4458) at glest_game/main/main.cpp:950
#38 0x00007f9c4d257c4d in __libc_start_main () from /lib/libc.so.6
#39 0x000000000040ad09 in _start ()

My log file is megaglest_btrunk+r1089_d20101011-021752UTC_ptomreyntrunk_tsegfault.tar.gz

470
I just ran into this segmentation fault on r1089 on a single player game against CPU:

Code: [Select]
Program terminated with signal 11, Segmentation fault.
#0  Shared::Graphics::Mesh::getFrameCount (this=0x34f1e10, t=0, cycle=true) at shared_lib/sources/../include/graphics/model.h:83
83 uint32 getFrameCount() const {return frameCount;}
#0  Shared::Graphics::Mesh::getFrameCount (this=0x34f1e10, t=0, cycle=true) at shared_lib/sources/../include/graphics/model.h:83
#1  Shared::Graphics::InterpolationData::updateVertices (this=0x34f1e10, t=0, cycle=true) at shared_lib/sources/graphics/interpolation.cpp:78
#2  0x000000000060c674 in Shared::Graphics::InterpolationData::update (this=0x34f1e10, t=0, cycle=<value optimised out>) at shared_lib/sources/graphics/interpolation.cpp:71
#3  0x00000000005edfe6 in Shared::Graphics::Mesh::updateInterpolationData (this=0x3490aa0, t=<value optimised out>, cycle=<value optimised out>) at shared_lib/sources/graphics/model.cpp:85
#4  Shared::Graphics::Model::updateInterpolationData (this=0x3490aa0, t=<value optimised out>, cycle=<value optimised out>) at shared_lib/sources/graphics/model.cpp:342
#5  0x0000000000475660 in Glest::Game::Renderer::renderObjects (this=0x8901a0, renderFps=<value optimised out>) at glest_game/graphics/renderer.cpp:1520
#6  0x000000000043f546 in Glest::Game::Game::render3d (this=0x34fb600) at glest_game/game/game.cpp:1403
#7  0x0000000000449d26 in Glest::Game::Game::renderWorker (this=0x34fb600) at glest_game/game/game.cpp:755
#8  0x000000000049d705 in Glest::Game::Program::loopWorker (this=0x22e2b30) at glest_game/main/program.cpp:266
#9  0x000000000049a625 in Glest::Game::glestMain (argc=1, argv=0x7fff366182f8) at glest_game/main/main.cpp:950
#10 0x00007ff7e52d0c4d in __libc_start_main () from /lib/libc.so.6
#11 0x000000000040ad09 in _start ()

The complete logs can be found in my log dump (which is stored in the usual location): megaglest_btrunk+r1089_d20101011-015411UTC_ptomreyntrunk_tsegfault.tar.gz

Thanks for reviewing!

471
MegaGlest / Known issues (and workarounds) with MegaGlest 3.3.7
« on: 9 October 2010, 20:27:01 »
opensuse 11.3:
Trying to install gives "No permission" even though installer file has the x (executable) bit set (chmod +x <installer-filename>) and invocation of the installer was correct (./<installer-filename>). To fix, use sudo mount -o remount,exec /home/media (assuming that you are working in or below of the directory/mountpoint '/home/media'. How to make this change permanent is yet unknown ('noexec' was not configured for this mount point in /etc/fstab, so it is assumed to be a HAL option).

opensuse 11.3:
The default font (helvetica) is missing. To fix, copy the font related instructions from glest.ini to glestuser.ini and replace all occurrences of the word helvetica by * (just this asterisk). Alternatively, install the 'msttcorefonts' package which your distribution may provide.

opensuse 11.3:
The 3D mouse pointer (the orange triangle one) is stuck and will not move. Please make a copy of debug.log and make it available to the games' developers. To work around this issue, add or modify this option in glestuser.ini: No2DMouseRendering=true - this will replace the games' 3D mouse pointer by your operating systems' mouse pointer.


472
MegaGlest / Getting more meaningful traces from Windows builds
« on: 5 October 2010, 13:17:09 »
I'm not at all into VC++ but I just learnt about PDB files and how they can (supposedly) provide better debugging output than 'An error has occurred, do you want to send this to Microsoft?': there's a mechanism called program database (PDB) which contains the debugging symbols in a way that executables which were built with a certain VC++ parameter can access them during runtime to produce a meaningful stack trace. I guess that, unless it notably impacts performance (I assume it does not), we should build all releases (or just dev snapshots if it does impact performace) using this option and ship the PDB file with the application installer.

There's also some useful information on other options here and here. The bottom line is that there are two ways to get access to (supposedly meaningful) traces generated on Windows computers without having to install VC++ or WinDBG on those computers:
  • the standard way of the user sending a minidump to microsoft, which you can then access as a developer through https://winqual.microsoft.com/ - but only after you bought a 1y certificate from Verisign for USD 99,-
  • by adding debugging hooks which will use the drwatson utility (its 32 bit version which was apparently introduced with XP) to generate your trace and then have the user (or a script) ship the resulting trace to you (the developer).

The last option seems like it could work for us...

473
Closed bug reports / [fixed] Bug: Unprovoked out-of-synch
« on: 29 September 2010, 23:18:15 »
Ulti and I just got disconnected from a six humans two CPU/bots game after the two of us died (but not immediately afterwards). The error message on screen looked like 'out of synch' but was badly positioned (lower part of my screen) and cut off. The visible text was also not easily readable. FPS of both Ulti and me were not low, but rather normal.

<titi_linux> I also saw this when we were hunting for out of syncs some time ago
<softcoder> fog of war lifted is bad for network
<softcoder> cause you may still have units
<softcoder> and they will see more on your end than the other players ends
<softcoder> and out of synch
<titi_linux> oh thats why?!
<softcoder> i think so
<softcoder> the unit can still do things
<titi_linux> so its not good it server has lost ....
<softcoder> right
<titi_linux> if server has lost
<softcoder> need to think about that one carefully

Actually I think I had no units left but I assume the logs can tell: megaglest_v3.3.7-beta3-GNUC_d20100929-225145UTC_ptomreyn_toutofsync.tar.gz is avaiable at the usual location.

474
Today I had an issue where the game froze on the menu where it lists available game servers.

What I did to provoke this situation:
1. I started the game and entered the 'Internet game' menu.
2. I disconnected my internet connection (via eth0).
3. I enabled my wireless internet connection (via wlan0), switching to a different internet provider.
4. As soon as I clicked (mouse) on some GUI button the game froze.

I created a backtrace_running.log backtrace by attaching GDB to the running process. This andmy debug log can be found in my log dump megaglest_btrunk+r1028_d20100927-211650UTC_ptomreyntrunk_tfreeze_after_switching_ISPs_and_network_device.tar.gz (available at the usual location).

475
When you select multiple units using a drawbox on Linux, totally unrelated units get selected, too. This is most often experienced when selecting some fighters (by means of a drawbox) which are on the same screen as some workers (which are near an edge of a screen).

If this is indeed a libgl bug then it should probably be filed at http://dri.freedesktop.org/wiki/BugZilla

Pages: 1 ... 15 16 17 18 [19] 20