quantumstate

If you click More Reply Options then the preview button should appear.

Are you sure? I deleted them all and it didn't make a noticeable difference for me. I think the choppiness is probably because the simulation update is what is being slow so you get a few quick frames then the simulation step runs then a few more frames etc. The profiler is generally more informative.

Ah I see. Calculating them yourself sounds like fun to me as well . Mythos: normal and displacement mapping can make a huge difference. Left is normal and displacement mapped, right is not. Though it would be quite a lot of work generating the maps for them.

We should put something like this in game at some point. Yes, I disabled the attack component though, normally stuff would have died much earlier.

I am not very knowledgeable about this but I was wondering if it would be possible to have blender use the same UV unwrap for the normal map as for the standard texture then you could reuse the texture coords.

We can also hook stuff into the rest of the simulation system for more fun. I spent a while trying to work out how to get the resources gathered stat in the AI and then realized that it would be dead easy to add some code to the statistics component.

Most of this has been suggested before. I can't blame you for not reading the 90 pages (plus other threads) though . Renewable resources have been discussed in depth before at http://www.wildfiregames.com/forum/index.php?showtopic=15181&hl=regrowing&st=0 . Hopefully without sounding too abrupt I would say that most of your suggestions aren't going to be implemented for the reason that 0 A.D. is an rts combat game (think AoE, Red Alert) not a city sim (think Settlers). After these two things I will make a few more detailed comments. It is planned that heroes will give a boost to units they are attached to. The size of farms is a design feature so you are forced to expand to place them. This will be exaggerated when we limit the number of gatherers (likely 6 per farm) and make farms infinite. Units on buildings and ships are features that we want but are going to be pushed back past the first 0 A.D. release in the hope that we will actually manage to make a release if we don't have ridiculous amounts of planned features .

There will be a violent characteristic which historic_bruno mentioned recently when talking about stances, but I can't find the thread. Basically it would mean that violent units would be likely to just wildly attack units without obeying your orders which sounds about right. I can't remember the details though. Edit:This thread http://www.wildfiregames.com/forum/index.php?showtopic=13725&st=0 should contain more detail. This would be nice but it would likely be quite tricky to implement. Might get implemented depending on time constraints. I like this idea. It would be a risky tactic and would add uniqueness to the Celts. Edit: OrganicHallucinosis says this would be inaccurate historically. Personally I don't care about historical accuracy (not a 0 A.D. team view) so this is up to others in the team to decide. Neutral units have been suggested quite a lot. I don't really know the status of them. They aren't a high priority feature, personally I am pretty neutral about them. This might happen if there is an autorepair option implemented. I don't think this would be a default action though. Units should do as they are told, only taking initiative in certain limited circumstances. Patrols are planned. Patrolling a border is starting to sound like feature creep but sounds interesting.

I thought it would be useful to get some stuff graphed for testing AI's. Basically I added this to my AI so in this case it graphs the number of units that the AI has. log("graph::units:" + gameState.getOwnEntities().filter(Filters.byClass("Unit")).length + ":" + gameState.getPlayerID() + ":" + gameState.timeElapsed); units and gameState.getOwnEntities().filter(Filters.byClass("Unit")).length are what you would change. You can graph lots of stuff simultaneously (though you need to add more colors to the styles variable in the python script). Then I wrote a quick and dirty python script to graph it using matplotlib (comes as part of scipy). import re import pylab as p f = open('{path to logs folder}/mainlog.html', 'r') log = f.read() r = re.compile("graph\:\:\S+\:[0-9]+(\.[0-9]+)?") vals = re.findall(r"graph\:\\S+)?\[0-9]+(\.[0-9]+)?)?\[0-9]+)?\[0-9]+(\.[0-9]+)?)?", log) #print vals a = {} for i in vals: key = i[0] + " Player " + i[3] if not key in a: a[key] = [[],[]] a[key][0].append(i[1]) a[key][1].append(float(i[4])/1000.0) f1 = p.figure() p.grid() count = 0 styles = styles = ['r-', 'g-', 'b-', 'k-', 'm-', 'r--', 'g--', 'b--', 'k--', 'm--', 'r:', 'g:', 'b:', 'k:', 'm:'] for key in a: count += 1 p.plot(a[key][1], a[key][0], styles[count], label=key) p.legend(loc='best') f1.savefig("out.png") And thus you get prettiness.

I get about 10fps after waiting for it to settle down, this seems to take more than 10 seconds for me, sim interpolate is high initially and then drops (I am assuming this is slow because the game just loaded, I don't know for certain though). On Mint 12 with an ati HD4830 and some AMD 3 core AM2+ desktop processor. What is your profiler breakdown? (Shift-F11 will put profile.log into your logs folder.) Here is a truncated version of mine showing what I consider to be the interesting bits. So for me it is the sim update which causes most of the slowness. I had trouble finding the cause of the ComputeShortPath taking up lots of time. I tried deleting everything that looked like it might eb causing issue and generally it didn't seem to help much so I would have to conclude that it is just lots of units all gathering etc. Profiling Information for: root (Time in node: 182.141 msec/frame) Name | calls/frame | msec/frame | mallocs/frame | calls/turn | msec/turn | mallocs/turn --------------------------------------------------|-------------|------------|---------------|------------|-----------|------------- |-sim interpolate | 1.0 | 18.298 | 0.0 | 1.0 | 14.265 | 0.0 |-sound update | 1.0 | 4.024 | 0.0 | 1.0 | 3.760 | 0.0 |-render | 1.0 | 46.530 | 0.0 | 1.0 | 43.851 | 0.0 | |-render submissions | 1.0 | 32.902 | 0.0 | 1.0 | 34.365 | 0.0 | |-gui | 1.0 | 3.368 | 0.0 | 1.0 | 2.999 | 0.0 |-sim update | 1.0 | 109.420 | 0.0 | 1.0 | 88.084 | 0.0 | |-ComputePath | 41.8 | 1.035 | 0.0 | 44.0 | 1.612 | 0.0 | |-ComputeShortPath | 47.1 | 55.529 | 0.0 | 43.0 | 54.960 | 0.0 | |-AI script | 1.0 | 11.139 | 0.0 | 1.0 | 1.489 | 0.0 | |-ExecuteActiveQueries | 1.0 | 4.471 | 0.0 | 1.0 | 3.906 | 0.0 | |-Move | 407.1 | 3.585 | 0.0 | 407.0 | 4.298 | 0.0 | '-unlogged | | 26.527 | 0.0 | | 14.384 | 0.0 Full log in the spoiler.

Units running is planned but not yet implemented. Terrain modifiers aren't planned. One problem is making it clear to players where the bonuses will apply, along with educating the players without overwhelming them with massive amount of complexity. I'm not convinced that there is enough benefit to having these kinds of bonuses.

No the AI will not use technologies for Alpha 10. This means it can create advanced units and buildings faster but doesn't get the benefit of technologies giving better attack and gathering rates.

In scenarios there can be existing structures placed on the map which are not Village structures. 5 isn't too many. You can reach that pretty fast with the standard starting resources. I haven't done much testing yet though. One balance issue is that come civs have houses worth more pop that others though.

Maybe we should consider rewording the tooltip to be more explicit about this. I'm not sure how to do that without being very verbose though.

Town Phase "Requires 5 village structures of any type.". 5 houses do count, I wrote the code for this .

Houses count as village buildings so that amount of population you suggest would necessarily require the current requirements. I think the idea that you can naturally build the required buildings with houses and dropsites, or that you can build unnecessary buildings to upgrade more rapidly gives an interesting tactical choice.

This function isn't the prettiest code which I have written. The main idea is to predict the next 20 items which will be produced from the queues and return the resources needed by these items. The parameters for recurse are: queues: A list of queues to pick items from, e.g. ["house", "villager", "economicBuilding"]. Initially this contains all of the queues that QueueManager controls. The naming is confusing so I shall now call the queues in this parameter cQueues. qm: The QueueManager object (I should probably remove this parameter and use the self=this; style) number: The number of items which need to be picked from the queues. Initially this is 20 depth: This stops infinite loops (Probably an indicator of the not so great code quality) So what we want to do is use the priorities to work out what proportion of those 20 items should come from each queue. This is done by weighting each queue according to priority so totalPriority is calculated and each queue's number of items is just given by 20 * priority/totalPriority. The problem is that the queues only have a limited number of items. So at this point we probably don't actually have 20 predicted items. So this is why the function is recursive. All queues which had all of their items picked are dropped fom the cQueues list and then the function calls itself to get the remaining 20-(#picked) items. Writing this made me realize that there is a bug since the number of items taken from a queue is not stored so the first items in a queue will be picked repeatedly. The general approach is not great though since it should be taking the cost of items into account when using the priorities since this is what the QueueManager does. I don't think i intended this to be permanent code, but ti works reasonably so hasn't been replaced yet. I thought I should also explain this nasty looking line: qm.queues[queues].queue[j].getCost()So qm is the queue manager, and qm.queues contains the Queue objects (queue.js) for each of "house", "villager",.. queues is the cQueue we are currently looking at so qm.queues[queues]is the Queue object for the current cQueue. A Queue object has a list of items in this queue which is stored in the queue member so .queue[j] is the j'th item from this queue. Each item has a getCost() function which returns th cost of the item.

The source is cross platform, so the windows source is the same as the linux source except for a very small number of files. The main size comes from the data files for the game not the code.

The main economic boost is due to me running a test match vs the latest Marilyn and finding that qBot's economy was not strong enough. So this gave me some nice "inspiration" (or copying), so thanks to Wraitii. The main change was building farms only when other food sources had run out (plus as a side effect I fixed some bugs which affected finding the closest resource to a dropsite, this also improved performance a little).

No this has been completely superseded by the queue manager which handles resource distribution.

Normal and parallax mapping would be great to have.

As far as I know this is because qBot has run out of wood or can't find space to place the fields. Of course other bugs are possible.

Have a read of https://github.com/q...ucture-Overview hopefully it should give you an idea of what the queues are for. If not then feel free to ask more questions. This is only used for working out where fortresses should be placed. To work out the placement it is necessary to know what they are trying to defend so this is a crude estimate of the most important stuff to defend. Yes, they are now used extensively throughout qBot.

The bug where qBot sends far too many gatherers to a single resource should now be fixed. Also the other gathering code should be slightly improved, there was a bug in finding the closest resource to a dropsite.

1. sounds like a good idea. It should be easy to add. 2. I don't like this. I give an ungarrison command so it should just do that. Also you can ungarrison single units and units of just one type and ti would be annyoing if it deselected the building when i want to ungarrison more. Only selecting the ungarrisoned units when all were ungarrioned would be inconsistent behavior which is bad.