Jump to content

wraitii

WFG Programming Team
  • Posts

    3.395
  • Joined

  • Last visited

  • Days Won

    75

Posts posted by wraitii

  1. The best thing is that Quantumstate implemented correctly something I was too bored to implement: counting how many gatherers work an any supply. I think i'll steal that code in return ;) .

    I'll have to test the new qBot, it's probably going to be a great benchmark for my new economic implementation in Marilyn.

  2. Allright, following Pueron's advice, I'm revising the economic manager, and making interesting progress. The new idea is that I keep a list of resources that I want to collect from for each resource type (ultimately, perhaps subtype too), and then I'll assign the most efficient workers to each. Still much of a WIP, but I think it can be very efficient.

    And as it seems like Quantumstate added a way to count the number of entities working on a resource at any given time, I'll probably get some inspiration to do that from him.

  3. Wraitii, the high-contrast effect is due to the fake HDR, which is half-necessary for the bloom effect. I could reduce it, but I kind of like it this way ;)

    Oh yeah, should have remembered that from when I tampered with HDR on Ogre.

    I still think the effect is too strong, because for example in your screenshot the whole ground is bloomed... at such a scale bloom should only happen on extremely white stuffs, I think (which should solve the 'units lose their shadows' problem). But hey, that's for the art department to decide, and anyway, it's very cool :) .

  4. Yeah, the effects might be a tad too strong (it looks like someone upped the contrast a bit too much), but it does give this sort of "I don't know what they're doing, but it looks niiiiice" feel that is really cool.

    Not applying SSAO to the terrain would indeed fix the halos. My guess is that most units wouldn't require it either (or as a setting for really advanced graphics, since that would computationally be slower.). Afaik, specular is dealt with on a case-by-base basis already, can't SSAO be done that way too? Buildings could use finer SSAO, while most units hardly benefit from it.

    For the terrain, you could have, on the contrary, a very rough filter that would have the effect or pretty much not detecting units, but would make the inside of forests darker or something (perhaps a huge downscaling, or something, I have no idea of the technical details behind all this).

  5. Yes, all assignments with objects or array in javascript are by reference.

    Good to know, thanks!

    Out of memory is a nasty one to debug, currently there isn't a good way I know to debug them. One that I came across before which hit some GUI javascript was a mismatched profiler start/stop which lead to the profiler tree continuously growing.

    Allright, I'll keep watching.

    No problem about the technologies, take all the time you need, better done well than rushed.

    Another thing about the API: I see you use "VectorDistance" for "ByDistance" filtering... I've done checks in the past, and at least on my computer (but I'd expect on most), it was faster using SquareVectorDistance, even with the added multiplying (though by very little). Since afaik this will trigger for every position change for every entity in any entitycollection that requires it, I think it could be a, however little, welcome addition (if for some reason, one comes to do it 1000 times per turn in some extreme cases, it could make a difference).

  6. I've got to say, I didn't really try to reproduce it... It's a weird bug for sure, I didn't either notice anything that would have caused a recursion... Perhaps it was a special case cause by something I did that was unexpected in Javascript...

    I'm really unsure what the circumstances of that particular crash were, though it was when an entityCollection tried to attack a gaia unit (iirc). Unless it comes up again, I think you can ignore it.

  7. Allright... This being my last day of holidays before at least 3 weeks of hard work ( :( ), I'm releasing Marilyn in its current state as a "proof of concept", if you will. Please report any error, suspicious warning, or weird behavior, this will allow me to tackle them when I have time. Note: it should only work with SVN.

    There is one non-lethal known bug: sometimes, the game will freeze for ≈10 seconds, before resuming with lots of "out of memory" errors. Afaik, there is no following crash or problem, I don't know what causes this, any help is appreciated. If it causes a crash for you, please report.

    Otherwise, I haven't really thoroughly checked, but it should be mostly working, at the very least in the 15 first minutes. I haven't actually played a game much longer than that since I started recoding, so I don't really know what could happen :) .

    It does about all the things the former Marilyn did:

    -Attacking. It will create armies, and will send them after the strongest enemy (I think), though it might get stuck sometimes, perhaps.

    -Defend. Marilyn will reliably attack any incoming army, and will deal with animals and lonely scouts. I'm not too sure what happens if one of its unit is out of its territory, but that should be a fairly rare case. I think the defense manager is actually more reliable than the former one at this point, even though it's not yet fully implemented.

    -Build stuff, much like the former Marilyn, only it chooses the templates dynamically using a system of roles.

    -The economic aspect of things is basically the same, I haven't touched it much, but because the plan manager is not yet perfect, it may have a few troubles building enough villagers in the mid/late game.

    What it doesn't do:

    -Raiding... And some things during attacks, such as responding to being attacked. I haven't had times to recode this, as I've basically scrapped using the old Tactics Manager, and haven't really coded anything new to replace it.

    -It's completely oblivious to technologies. Do not be surprised if Marilyn builds a fortress as its first military building.

    -It won't build towers or fortresses for now (though most civs will likely build a fortress as its first military building, bar perhaps the Persians).

    What it does better:

    -The Defcon system for defense has been revamped, and now Marilyn will garrison/ungarrison females. The defense manager is also more clever, it's able to pause attack plans if it takes their units.

    -It's not "better" per se, but Marilyn is now mostly dynamic for unit training and building. All civs are supported. This doesn't change much compared to qBot, but you'll notice Marilyn training champions for its attack plans instead of anything, and building fortresses instead of Barracks, things like that.

    Technical side of things: I use entity collections everywhere. In the two "census "files, which are the unit/building info manager that Marilyn uses to know what it has/what it can build. In the defense manager, for enemy targeting/knowing which of my units attack. In the enemy watchers, that keep track of enemy armies. It's very neat, and very dynamic.

    Quantumstate, if you read this and have some time, I think it could be interesting to look at the code (most notably in the attack plans/defense manager), there are likely some stuffs that you can put into qBot.

    There might be a git repo in the file... Ignore it, I haven't updated yet.

    Marilyn.zip

    • Like 1
  8. Good idea.

    Not sure if that's actually feasible, but I think using the resource icon and not the name would improve readability. Ever so slightly, but still.

    Also: it might make it look a lot like a Christmas tree, which would be bad, but have you tried coloring more and more red as the resource lacking are important (with alpha)? So that at a glance, we'd now how much we need more. If it works from an aesthetic point of view, it could be useful. I think the effect can be quite potent even with small differences in the alpha, so that it looks good, and useful.

    Edit: I also recommend changing your code in Unit_command.js to this:

    if(guiName == CONSTRUCTION || guiName == TRAINING){
    selection.hidden = true;
    var totalCosts = {};

    var multiplier = 1;
    if (guiName == TRAINING && Engine.HotkeyIsPressed("session.batchtrain"))
    multiplier = 5;
    for each (var r in ["food", "wood", "stone", "metal"])
    totalCosts[r] = Math.floor(template.cost[r]*multiplier);
    var neededC = Engine.GuiInterfaceCall("FindCostNeeded", totalCosts);
    if(neededC.length){
    //only put on the red overlay if the button is not already grayed out
    if(button.enabled != false){
    button.enabled = false;
    selection.hidden = false;
    }
    button.tooltip += "\n[font=\"serif-bold-13\"]Insufficient resources:[/font]\n"+neededC.join(", ");
    }
    }

    It will show red properly if the user clicks on "shift", which is much more intuitive. It doesn't take into account the batch size, though, I'm not too sure how to get that.

  9. Not sure if it always happen, but i've had this crash while making an entity collection attack:

    ERROR: JavaScript error: simulation/ai/Marilyn/entitycollection-extend.js line 10
    InternalError: recursive object
    ([object Object])@simulation/ai/Marilyn/entitycollection-extend.js:10
    ([object Object],[object Object],[object Object],[object Array])@simulation/ai/Marilyn/attack_plan.js:252
    ([object Object],[object Object],[object Array])@simulation/ai/Marilyn/headquarters.js:1545
    ()@simulation/ai/Marilyn/marilyn.js:128
    ([object Object])@simulation/ai/common-api-v2/base.js:122
    @:0

    (It's using Marilyn but the code is the same in qBot, as far as entity collection attack() is concerned).

    Replacing it by this fixed it:


    EntityCollection.prototype.attack = function(unit)
    {
    var unitId;
    if (unit.id()) {
    unitId = unit.id();
    }else{
    unitId = unit;
    }
    var idArray = this.toIdArray();
    Engine.PostCommand({"type": "attack", "entities": idArray, "target": unitId, "queued": false});
    return this;
    };

  10. Perhaps when ringing the bell, soldiers would deposit their resources to the nearest dropsite, and instead of garrisoning inside, would start fighting.

    I guess a variable could be used to store which entity they were working on before, so that they would return to it after the bell 'unrung'.

    It'd be nice to have a list of dead units though (something along the lines of (lost 10 stone workers, lost 5 food workers...)), since otherwise the player would have to count manually.

  11. Hi Quantumstate... A few more questions about the API.

    First, I'd recommend adding the "NOT" filter. It can be useful to check something like "Not a worker".

    Filters["not"] = 
    function(filter1){
    return {"func": function(ent){
    return !filter1.func(ent);
    },
    "dynamicProperties": filter1.dynamicProperties};
    };

    Secondly: you give every entity collection a "this._ai" property... It works as a reference and not as a copy, right? Javascript is messing with my brain about those things.

    Third: I sometimes get a "length NAN" error with entity collections if I don't ask for the length immediately after the entityCollection's creation. I guess that's an initialization error somewhere.

    Finally, and this is perhaps more of a general question, it seems that after some times, using a lot of entity collections, I get a "out of memory" error in GUI/sessio.js, in an (eval) or something... It doesn't always happen, and judging from the profiler, the AI script doesn't seem to overload. And there is no following crash. Any idea what this error is?

    edit: oh, and any ETA on AI support for technologies?

  12. Okay, I've done this 5 good days of work during my holidays... I'm getting close to being on par with the former Marilyn, but not quite. I've also redone a ton of stuffs, because some things weren't fully logical, or simply to make it better.I'm using entity collections pretty much everywhere, it's fairly nice.

    I'm going back to school in 3 days, and I'm going to have a lot of work for at least 3 weeks, I'm unsure how fast I'll go.

    I'll probably also try to support technologies before releasing the new version.

  13. More/changed textures/props sounds like a plausible compromise yeah. We'll see what Michael and the others come up with though, I don't want to promise anything on their behalf ;) Also, imho it's one of those things which are nice to have, but imho isn't a priority if there are other things to do that will further the game more :)

    I do think that some visual indication of the phase progres in the main GUI (i.e. apart from the one you get when you select the CC) would be nice to have, again I'll leave it to Michael to come up with the best idea though ;)

    I do understand it's not the highest priority (though something in the GUI would be fairly neat)... it's simply something, as far as art is concerned, that should be considered, and imho done at least to some extent. It's sort of "expected" in a game like 0 A.D. Since 0 A.D. is set on a fairly short time period, and given that it's "village->town->?", it makes sense to try to convey the feeling of more activity instead of redoing everything, which anyway would be a bit too hard.

  14. There could be some sort of graphical change when you grow in phases though... Like dirt tracks becoming true roads, perhaps more "actor" props in things like markets (more merchants)…

    It's very much a graphical thing, but it does look very cool... And I think it's better for 0 A.D. not to have building meshes change (à la AoE) but rather small textures/props change to reflect the passage from village to town etc.

    Also: it's nice to always now which phase you're in, having the progress bar in the top bar would be a good addition.

×
×
  • Create New...