gudo

Done and done! (By the time you read this that is >_> hahaha)

Oh nice. How do I set that up?

I've seen some board where users could make their own title. Perhaps we could get that for people who post enough? Otherwise, Roman ranks is the way to go IMO

Hmmm... If you had a similar problem with minecraft, how did you fix it? Also, could your friend try and host it?

I'm pretty sure this project is dead. After poking around in the project's change log, it looks like the code hasn't been updated since February.

I think we should leave the Hindu/Indian names out till the new faction is actually in IMO. Looking at the Alpha 11 Roadmap makes me think that proper Mac support (and perhaps gates) are the the order of the day. Is there any ancient "K" word for apple?

Pathfinding and AI are indeed the slowest parts of the game, though the AI has improved in speed quite a bit over the past few releases. Pathfinding is slower than AI at the moment. The other thing that slows the game down is the fact that it can't take advantage of multiple processors. Everything (render, simulation, pathfinding, AI, etc) all has to pass through a single processor. If the code were re-factored to be able to use multi-core processors, the speed should improve. Pathfinding, iirc has a larger impact on speed than anything else though, so splitting the game into multiple threads wouldn't speed the game up more than pathfinding allows. At some point in the future however, there should be both pathfinding optimizations and multi-core support.

In my work to flesh out my (shameless plug) WIP credits, I ran across just such a centralized resources, the Team Profiles sub-forum. It's a great idea, the problem is keeping the thing up to date.

Yeah, a suggestion sub forum would be the way to go. It would also help if there was a bit more moderation in it, to enforce descriptive thread titles. (eg when someone makes a thread "Great Game, just one idea" or whatever, a mod would re-title it.)

I can reliably reproduce this bug with trees, stone, farms, and metal mines. I haven't tried it with hunting. It also happens reliably whenever you task two women to construct a farm (only one actually gathers resources when they auto harvest.) Interestingly, this bug doesn't happen when gathering berries. (The only difference I can see is that berries are gathered in multiples of 2, while each other resource is gathered one unit at a time.) I can not reproduce this bug using CitizenSoliders instead of Women. When using women, I can reproduce this bug even after waiting long enough for the first woman to deliver a full load of resources. To reproduce, it helps if you assign each woman to their own control group, and only use two women. I'm using latest SVN.

I checked it out, looks good and works well. Just thought a few very minor changes that could be made to your patch. In your modified Commands.js, as of r11620 there is a new class "Citizen" that should let you replace if ( cmpIdentity.HasClass("Worker") || cmpIdentity.HasClass("Female") || cmpIdentity.HasClass("CitizenSoldier") || cmpIdentity.HasClass("FishingBoat") ) with if ( cmpIdentity.HasClass("Citizen") || cmpIdentity.HasClass("FishingBoat") ) Also, an extra space between the resource amount and worker count would help with readability. Though depending on the resolution of ticket 1349, you might be using "Worker" instead of "Citizen"

Thanks Jeru I've seen "Stu" in a few places, glad I finally have a name to go with it. Looks like I have a bit more work wading through the concept artists. I'll add 'em to the todo list

Well, he's on the list now

Hmmm... We just might get both walls and tech in A10! That would be @#$%in indeed.

Zsol is on the list now. I try to keep up with patches and updates on SVN, but this one slipped by me. Thanks!

it's either that, or input.js. They're both related somehow, I notice both files usually get modified in the same commits...

Nice progress so far 1) Take a loot at Identity.js line 103. Perhaps you could first filter your list for all entities with the class "worker". If I remember correctly, all entities with "worker" can gather resources. (Females aren't the only gathers, "CitizenSolider" can do it too.) If it's not the case that all entities that can gather resources have a common class, I would propose adding the "gatherer" class say, and looking for that. Or, you could look for entities with class "worker" || "female" || "citizensoldier" || "fishingboat" 2) We should handle Females, CitizenSoldiers, and FishingBoats all the same. Check and see if the entity is gathering. If it is, add it to the count. No need to complicate things. I would try and get basic functionality working for basic gathering units before worrying about the edge cases (trade carts, units collecting loot, and abilities that give resources eg Satrapy Tribute.) 3)Hmmm... I recall that quantum solved a problem with garrisoning in qBot by checking to see if an entity's position was defined. There are many cases that would cause a worker to quit gathering. It could be converted, or tasked to build, repair, attack, etc. And what do we do if the worker is tasked to gather a different resource? It sounds like you're making a list of entities, then updating the list. Why not just start the count from scratch every time we update the player display? Then we wouldn't have to worry about such things. It shouldn't be too resource intense if we can filter the entities to be checked. Or we can update the list every 3rd time the display is updated.

I would consider looking at the code for the "Find Idle Workers" button (Added in commit #9140.) Perhaps you could re-purpose the code to checking to see if the worker is gathering instead of idle, then add to an appropriate counter. I think the hard part would be checking to see if the worker is gathering a certain resource. I'll see if I can find something that would help there. Also, you need to consider trade carts and ships. Even though they aren't gatherers, they still deposit resources. You could just put a //todo line in the code I suppose...

Hmmm... I'm not actually sure that you can place rally points on resources. If you normally can, than this is indeed a bug. If you normally can't, then we should write up a ticket to have it added as a feature. I'll do some testing, and open the appropriate ticket if nobody beats me to it.

Thanks for reporting this. It's been fixed since the last alpha (see ticket 1254)

[EDIT]Never mind, answered my own question.[/EDIT]

Wow Jubal, nice to see ya again As far as work goes JuBot, I would try to implement some novel features (wall building, perhaps ranged cav hunting.) But like you said, the problem with having two AIs in development is there is a ton of duplication of effort. One thing that I would look at would be implantation (even if at a proof of concept level) of one of the planned features. Things like ramming for ships comes to mind. An improved click-drag wall placement system would be outstanding. Or Auras for heroes. Special abilities (i.e. a targeted "conversion" for priests. I think working gates might fall under this. The "Open" and "Close" ability would toggle passibility on the structure and play an animation.) A new game mode/victory condition (i.e. "Regicide") would be welcome too. Even a mostly working, sorta buggy implementation of the above would have quite the impact on game-play I think. There are also plenty of behind the scenes things that could use some work. There's a new sound manager in the mix, people have been asking about scripting events for maps and so on. I'm not really sure how involved those projects would be, but most of the other suggestions (AI work, RMS, etc) in this thread seem pretty well covered.

There's a thread for Rise of the East here with the latest progress reports (most recent was Jan 2, 2012.) That is still the only download ATM. The project webpage is http://www.sciondevelopment.com/

Was qBot an ally? I've noticed that qBot likes to try and farm allied farms now...

Nice! Everything looks fixed to me.