Jump to content

UV_Completion

Community Members
  • Posts

    16
  • Joined

  • Last visited

Posts posted by UV_Completion

  1. I just ran a quick test with recent svn on Oasis II (qBot Carthagians, Marilyn Hellenes). The game segfaulted (without a useful error message) before the game was finished, but it looked like Marilyn got the upper hand towards the end. qBot had the better start but its attacks were too uncoordinated and slowly Marilyn gained ground.

    There was one (non-fatal) java script error in Marilyn:

    WARNING: It appears there is som sort of enemy army in my territory
    WARNING: New land attack found.
    WARNING: Asked for dropsite for wood at 439.1544189453125,394.7325744628906
    ERROR: JavaScript error: simulation/ai/Marilyn/map-module.js line 18
    TypeError: p is undefined
    ((void 0))@simulation/ai/Marilyn/map-module.js:18
    ((void 0),[object Array])@simulation/ai/Marilyn/terrain-analysis.js:108
    ([object Object],[object Object])@simulation/ai/Marilyn/Attack_city.js:373
    ([object Object],[object Object],[object Array])@simulation/ai/Marilyn/military.js:1040
    ()@simulation/ai/Marilyn/marilyn.js:154
    ([object Object])@simulation/ai/common-api/base.js:117
    @:0

    It seems to be reproducible so if you need more information, let me know.

    PS: The shortcut for the developer overlay (Shift+D) is non-functional at the moment. Somehow scrolling right has been assigned the same shortcut. Is this on purpose?

  2. He has quite some days left so no need to hurry.

    Also, I strongly disagree. The best reason for me to donate would be to know that this would get some "unfancy" but important work done, first of all optimizations (and stabilization, but the game seems pretty stable to me already). I also think that Philip is right to spend quite some time on reviewing patches. If 0AD gains only a single regularly contributing person by this, it already was totally worth it (and even if not, you have at least some nice improvements made, even if they come with a more-than-necessary amount of work.)

    To make it clear, I actually think that Philip's work is in fact quite fancy, especially the new profiler and the network stabilization work.

    Philip while I do understand the trade-off you described between features, bugs, performance, number of lines, readability, maintainability, cleverness, etc. that a programmer has to face, and the importance of reviewing patches (there's already a number of awesome changes coming up in the new alpha because of that!), I think for the purpose of fundraising it could be a good idea to pull out a new feature in the remaining days that you have. New features, as you said, are the most visible improvements to players (/donors) and could therefore make the biggest impact on the effectiveness of future pledgies I figure. So if possible something along the lines of wall placement, viable ship pathfinding, healers, or any other direly needed feature could prove to be some good piece of advertisement?

    In the end, after this month, you could make an impressive list that way:

    'Implementations that are directly perceivable by the player:

    - New feature X

    - Saved games

    - Reviews of patches allowing for trade, barter, rally point marker lines, etc.'

  3. With the most recent qBot, I get the following Java script error:


    ERROR: JavaScript error: simulation/ai/qbot/qbot.js line 82
    TypeError: this.toUpdate[i].update is not a function
    ()@simulation/ai/qbot/qbot.js:82
    ([object Object])@simulation/ai/common-api/base.js:92
    @:0

    The error appears after roughly two seconds on every map I tried and repeats itself over and over again.

  4. I put some debug code in Hotkey.cpp:HotkeyInputHandler() two weeks ago but haven't been able to trigger this bug again since then. This is kind of strange because it happened on an almost daily basis to me before. Either it's a weird timing problem which would make it impossible to debug for me because I have no detailed knowledge about the inner workings of that code or some third party dependency got updated in the meantime (I'm on Debian Testing and perform an update every day). I'll try without debug code again as soon as I find time to do so (may take a while though).

    Thanks for the report; it'd be great if you would look into this!

    It could be a problem within SDL, but that's a bit less likely because it seems to happen on the OS X backend, too.

    If you see any gremlins lurking within out input handling chain (starting at lib/input.cpp), I will be happy to give it a look and/or apply a patch.

    Incidentally, if you see this problem again, it should be possible to work around it by pressing+releasing the same `stuck' key.

    I'm pretty sure I tried this and it didn't work. That's the reason why I suspect HotkeyInputHandler() because there is some code which prevents key up events from doing anything under certain conditions (which I do not truly understand).

    The problem does not arise with mouse scrolling because we check each frame whether the mouse is near the border. Once the mouse returns elsewhere, movement will stop immediately.

    This makes sense.

  5. I tested the latest GIT and hit some problem in the tree map code:

    ERROR: JavaScript error: simulation/ai/common-api/base.js line 36
    TypeError: name is undefined
    ((void 0))@simulation/ai/common-api/base.js:36
    ([object Object],[object Object])@simulation/ai/common-api/entity.js:177
    ([object Object],[object Array])@simulation/ai/qbot/economy.js:267
    ([object Object],[object Object],[object Array])@simulation/ai/qbot/economy.js:330
    ()@simulation/ai/qbot/qbot.js:70
    ([object Object])@simulation/ai/common-api/base.js:91
    @:0

    I was playing against two JuBots and a qBot on a random map.

  6. I agree that villagers should remain conquest critical, but to avoid tedious searches when playing versus an AI opponent the AIs should implement a surrender condition. The minimal condition could be something like no dropsites left and not enough resources to build a new civ center. A more elaborate condition would be to compare the strength of the own team with the strength of the other team and give up if the situation is hopeless.

  7. I tested the (almost, due to git lagging behind the subversion repository) newest JuBot and am quite impressed with the progress made. Apart from more strategical improvements (building new civ centers, building drop sites more efficiently, counter unit types, ...) I would propose (as Pureon pointed out already) that JuBot builds more siege units and does it much earlier. It really makes a huge difference if attacking fortified positions.

    Apart from this, I also ran into performance problems when I destroyed the civ center of one of the JuBots before destroying any other building. It then tries to find a place to build a new one but doesn't succeed, so it tries again and again (I don't know why it fails, something with territories perhaps?). To find a building site it calls addInfluences for any of its buildings which seems to be quite expensive. The real fix for this is of course to find the reason why it doesn't find a building site but even then the finding procedure should be optimized.

    A proper but probably difficult to implement fix would be to calculate the influences map only once and update it when a new building is constructed or an existing one is destroyed. But there are some easier optimizations (I didn't profile this, so I don't know which one is worth trying). The most expensive operation is probably the square root in the distance calculation. You could switch to a quadratic (rather than a linear) fall off to get rid of it or use some approximation (see for example http://www.azillionm...t.html#distance).

    Another easy performance improvement would be to reduce the influence radia, at least for some buildings (houses!). Probably you even could ignore houses altogether in this calculation.


  8. this.lastGoodPosition = org.zeroad.splitbot.core.Point.arrayPoint2Point(this.getCivicCenter().position());
    while(true) {
    this.lastGoodPosition.x += Math.round(Math.random() * (width + 10) - (width + 10) / 2);
    this.lastGoodPosition.y += Math.round(Math.random() * (height + 10) - (height + 10) / 2);
    if(!org.zeroad.splitbot.helper.MapHelper.isObstructed(this.lastGoodPosition,width + 10,height + 10,["building-land","foundationObstruction"])) return this.lastGoodPosition;
    }

    Couldn't this end in an infinite loop? And I think a random walk from the civ center is not the most efficient way to find a building space.

    Are you sure that you multiply with/divide by cellSize at all relevant places?

  9. I tried your Bot in a random map and it put up a lot more resistance than JuBot, nice work!

    The only obvious flaw I could spot is that it builds an insane amount of units before it attacks which hurts performance a lot (it may be that not all of its attacks are that huge because I played with more than one qBot and they probably attacked each other earlier in the game). As I started an attack on its base it threw literally hundreds of infantry units at me, in the middle of an almost equal number of females. I didn't check the code but maybe you could lower the number of units it gathers before attacking a bit.. at least as long as the performance impact of large armies is so high.

    Other things I noticed: One of the qBots tried to build a farmstead directly at my border (far away from its civ center). And the bot could probably build some defense towers, if only for aesthethic reasons. But I know that you just started working on it (and yet it's already quite impressive).

    EDIT: Just had a brief look at the code and noticed this piece of code in military.js:


    gameState.entities.forEach(function(ent) {
    if (ent.owner() === i && (ent.hasClass("CitizenSoldier") || ent.hasClass("Super"))){
    count ++;
    }
    });

    And then he tries to build an army twice the size of the strongest enemy army.

    I don't know Java script so I just assume that === does a comparison ;)

    But if you play with more more than one qBot this code could probably lead to an arms race between the two qBots (which explains the fact that in my game the second qBot only attacked when I had reduced the army of the other one significantly).

  10. I have almost no knowledge about modern Windows versions but shouldn't it be easy to at least run pyrogenesis.exe in a command shell and check the standard output?

    I am also a bit puzzled by the debug instruction page. Is the Windows binary a debug build by default?

    Hmm that sounds a bit like another problem with DELAYLOAD, but more information is needed. Are you comfortable trying to debug the game, to find out what it's doing?

  11. I seem to have encountered this as well, on OS X. Which OS are you using?

    I'm on Debian GNU/Linux and using the most recent git version.

    Edit: the scrolling code is in CGameView::Update (source\graphics\GameView.cpp).

    Thanks, I will take a look as soon as I find time. But as I'm not familiar with the code I can't promise anything.

  12. If you scroll around using the keyboard sometimes the "key up event" seems to get lost so that the game scrolls forever in one direction. I haven't been able to find a workaround for this other than aborting the match. If you try to scroll in the opposite direction you can compensate the scrolling as long as you press down the key but there seems to be no way to restore normal conditions.

    This bug is difficult to reproduce. It seems to me that it occurs primarily when the game lags for a short moment while scrolling. It does not seem to happen if one uses the mouse for scrolling.

    I could try to give further information if necessary or even to look at the relevant code if someone could point out to me where it is located.

  13. I really enjoy playing this game, great work!

    I found a minor glitch in the map Savanna Ravine: One of the stone mines in the center do not belong to Gaia, but to Player 1 and is therefore attacked automatically by Player 2's units. The following trivial patch fixes this.


    --- binaries/data/mods/public/maps/scenarios/Savanna Ravine.xml
    +++ binaries/data/mods/public/maps/scenarios/Savanna Ravine.xml
    @@ -777,7 +777,7 @@
    </Entity>
    <Entity uid="167">
    <Template>gaia/geology_stone_savanna_small</Template>
    - <Player>1</Player>
    + <Player>0</Player>
    <Position x="367.37629" z="294.94001"/>
    <Orientation y="2.35621"/>
    </Entity>
    @@ -3987,4 +3987,4 @@
    </Entity>
    </Entities>
    <Paths/>

×
×
  • Create New...