quantumstate

There has been a breaking change in svn, with the scout tower being renamed. It is a simple fix, I just thought I should let you know.

I think it will be much better to have this happen automatically, rather than each AI having to implement entity collection maintenance. Putting it into the API also allows the code to be easily changed for performance improvements without having to change everyones AI scripts. Of course it is possible to create entity collections the old way and manage everything yourself. Adding some form of notification about changes would be useful. Currently there is the array of events for this, but it is fairly limited. The game is built on a turn based system so I think the AI's will always be restricted to a turn based system like they are now. Callbacks are still workable though. There are some things which you would need to consider though. The main thing is that the games' state will have changed by the time the callback is called so this might cause issues with specifying parameters for the callback.

The only bot still being developed that isn't in svn that i know of is Marilyn (plus SplitBot). There is a link to it somewhere on the forums.

Sorry, I'm not quite sure what you mean by this. Could you elaborate a bit?

You can use the in game console (F9) and then enter Engine.SetSimRate(0.5) which would play the game at 0.5 times speed (any number should work though it does funny stuff if you slow it down too much). I don't think that it is possible to get animated water in the Scenario Editor.

I have found that recordmydesktop works fairly well. I have a slower processor but better graphics card, so I would expect this to be ok for you as long as the game runs normally without lag.

The main thing is basically persistent entity collections, along with a group of preset filter functions which make it easy to use. This would be done in javascript initially, I think performance should be good enough. For performance though, the dynamic properties are important because without the automatic updating we are in exactly the same situation as now, and there are lots of position changes every turn so performance will be poor without filtering by dynamic property. Metadata on buildings makes sense, I think we should do that. The water information is linked to accessibility testing and pathfinding. It would be helpful to have, I think it would be best to leave this until Philip has finished the current pathfinding stuff and then come up with a decent AI interface for the whole section. Buildability should be fairly easy to expose. An event system would be a pretty big change. I currently can't see much use for it in qBot, but i haven't given it much thought. It should be possible to implement in the common-api code which would make it fairly straightforward to add, it would just run events at the start of your AI's turn.

No, that hasn't been done yet. Also I put some of my ideas here http://www.wildfiregames.com/forum/index.php?showtopic=15410 . Any comments would be appreciated.

Here is an example: Engine.PostCommand({"type": "gather", "entities": [178], "target": 897, "queued": false}); You would put it into the console (F9) assuming you have the correct id numbers for the units.

This sounds like a nice idea. Currently there is only ever one resource type gathered from an entity though, how would you suggest changing the UI to show multiple resource types on a single entity?

The game already supports non-latin scripts for the unit names, so it should be ok to translate into Persian when we are ready for translations.

I don't think this would help particularly. In terms of hardware support we are aiming to support reasonably old hardware. Even if we only supported dual core chips, a theoretical 2x speedup probably still isn't enough for a four player game to run smoothly. This combined with the extra implementation difficulty means it probably isn't worthwhile. To make use of extra processing capacity it is easier to run separate parts of the game onto their own cores e.g. AI on one part, pathfinding on another, etc.

The map editor, atlas, is better for setting up tests, you can easily add units and then quickly run the game in preview mode which can then be reset.

Svn keeps a full history, this just removes the files from the current checkout.

My main thought was actually that the palm trees look like flowers at this zoom, so you can pretend the map is actually pretty tiny, with a few puddles and some curious little model buildings exquisitely modeled and dropped on the ground. On a more serious note, it is fairly difficult to think of significantly varied designs. One idea is to have two players put close together with a river flowing around them. Then they have to expand if they want resources but are under constant threat of attack by a very close proximity neighbor. Another thing I think we should try and fix the performance problems with trees so we can have proper forested maps. This might be difficult and programming time seems to be fairly limited though(which reminds me that I should start doing more).

Control all units is a tool to help developers. So there is not much reason for us to improve it unless you can show there is a common use for it, what you described sounds unusual.

When you take a screenshot it tells you where it saved the file at the top left of the screen, so just take another random screenshot and read the location from there.

I can't find a ticket for this either. It does sound familiar though. I also thought that the building foundations were being extended so this was less of an issue.

I use svn so it isn't a zip file, it is just in a normal folder.

I made the texture a 256x256, which doesn't lose much detail, there is a bit of a seam where the tail joins the body but shouldn't be noticeable if it is scaled similarly to the chicken (also the bit under the tail is a mess but you can't see that. The texture came from http://en.wikipedia....acock_ramon.jpg which is CC-BY-SA so we should probably add something to the credits if we use it. I modified the chicken rig, it could probably do with some work, the neck especially seems to be hard, it has a tendency to kink a bit. peacock3.zip

It doesn't seem to work on Linux. I tested by running pyrogenesis, opening atlas via the main menu, generating a random map, modifying the random map script and saving it, then generating the random map again. This produced a random map without my changes. Closing atlas and reopening using the same process results in the modified script being run.

This is because plot_field_new_2.xml has been put into the svn since Alpha 8 was released. So it is nothing to worry about. Corrals don't have full functionality yet, currently they just train wild animals. Putting actors in does seem like a strange choice though.

Ykkrosh's rig seems to work best. For ease of animating it would be easy enough to set up a convenient rig with a small rotation locked bone which you would apply the script to.

Does that look about right?

There is a thread http://www.wildfiregames.com/forum/index.php?showtopic=15491 where someone asked and it has some information listed. Part of the problem is that even the devs don't know what will get done for the release, some stuff is fairly definite but others aren't so easy to judge. There are also plans for a dev blog which should allow you to follow development without having to read commit logs (assuming people have time to write things for it).