quantumstate

If you use the svn update command this will only download the things that have changed.

Something subtle you should know about the shift click training is that it decreases the training time. So training one female citizen take 10 seconds, training 5 takes 37 seconds. So you can have fewer training structures at the cost of increased queuing. Building hotkeys are a planned feature but aren't implemented yet. I agree that wasd should be rebound for that. We have location hotkeys on F5-F8 (Ctrl F5-F8 sets the location), keys can be rebound by modifying a config file (default.cfg) currently which isn't too friendly but does work. Do you have the svn version of the game? If not it might be worth getting it to be more current with the features as they get added.

We talked a bit on irc (http://irclogs.wildfiregames.com/2013-12-03-QuakeNet-%230ad-dev.log from 21:53:05). I think it sounds like a good idea.

What if you have multiple units selected with different toggle states? Also there are factors like lag, so even if ti is really obvious graphically I still find it easier to just hit a key and know what state I will end up in.

Just a side note. Anything toggleable should have two hot keys. One for toggle on and one for toggle off. It prevents you accidentally getting into the wrong state

I prefer keeping resource regeneration rate constant. It is simple and also means that you don't need to manually manage your workers to optimize the gathering rate. As long as there are several regenerative resources the workers will use up one, then move on to the next etc. With a sigmoid version to get the most resources workers need to be pulled off the resource before it runs out and put onto resources before they have finished replenishing. This adds lots more actions for the player to perform which are mechanical and don't seem to give any interesting gameplay.

Design thread

Some resources which already exist on the map (fruit and fish) will recover resources over time when they are not being gathered. The rate of regeneration needs to be decided. 1. Constant regeneration. This is very simple, the amount of resources increases by the same amount each second. 2. Sigmoid regeneration. This varies the regeneration rate based on the current resources. When the resource is close to empty then the rate is slow and when the resource is nearly full the rate is also slow. I have attached a diagram showing the two methods, constant is in orange and sigmoid is in green. Discussion thread

Unfortunately this article just gives a very basic introduction about how to use the AI API for SC2 so isn't at all useful.

What failure do you get with LTO?

NAT sounds like a good thing to be working on to me as well . I haven't quite caught up with my irc log reading yet. If you need a server for testing NAT punching I could set up some limited access to a VPS that I have.

That sounds good, hopefully you will be able to contribute something . Can you give a better idea of how much time you will have available for the project. You mention 3 weeks but do you have an estimate of the time available per week?

Some thoughts about a forest brush that I had The simplest idea I have for a forest brush is to have a density setting and a single tree type selection. Trees would be collision checked so two trees cannot be placed in the same location, so to get a mixed forest you would pick a low density and then go over it multiple times with different tree types selected. For multiple tree types at once the simplest is just multiple selection in the entities box. What would be nicer would be a whole new GUI page so tree sets could be created. This would make things easier for users since they can just pick presets, and advanced users could create their own sets. The GUI would just have a list of trees with a list of proportions. For the painting there are two ideas I came up with, first (which I prefer) is that during one mouse press if you overlap the previously painted area it won't add any more trees, this could easily be implemented with a buffer the size of the map which would be painted and new trees could only be added to unpainted areas of the buffer. The other idea is to only add trees in the area that was not covered by the brush in the previous frame. This means if oyu went back over a area that had been painted it would add more trees.

The hotkey explanations are incorrect, I have fixed the wiki page. Our system is consistent (at least this bit of it), shift is a modifier which means add to current selection. This allows you to select control groups 1 and 2 which is not possible under the starcraft scheme.

People with very small bandwidth allowances or really slow download speeds might find it useful. Some people like to have physical copies of games since then you have a nice box etc. I have bought physical copies before when the price was close enough to download cost. Though I think that the ebay sellers are unlikely to have produced a nice quality box and the download is free so that last reason shouldn't apply if they know what they are buying.

They could go to the trouble to writing a new thread because it actually isn't much trouble. The only additional effort is writing a title which is probably a good thing to have anyway since it should neatly summarize the question. It makes things so much easier to view for anyone reading the forum, one massive question thread means that questions are throwaway, people can't easily go back and look at answers. Also you get cross talk when multiple questions appear so replies are interleaved etc. Bear in mind that at least tens of people will read stuff that is posted, so one person spending a small effort to make things more organised is worth it since it helps tens of people read it.

Why not just start a thread for each question? Otherwise it just becomes an complete mess like the suggestions thread.

When some work on the glsl shaders was done by myconid I remember people reporting a variety of glitches with linux opengl drivers. Linux is a significant target currently especially for developers so we should be very careful about dropping support.

That looks nice. Very pretty. For maps designed to be played as normal games you should have 1 large stone and metal mine in each players base. Otherwise it really distorts how the game plays.

qBot uses the population limit for dynamical numbers. If it isn't doing this correctly it is a bug somewhere.

This seems sensible to me, I remember finding it slightly confusing when I started playing, probably because of AoE.

To do this properly it would need to be more of a mod than a game mode. The heroes would need special abilities to make things fun.

That looks great .

With the quadtree you lose efficiency when height is added since you need to search a larger area. Significant uses in our game are for culling what will be rendered and detecting units under the cursor for mouseover and selection. These are both 3d operations, 2d spatial filtering for gameplay already exists in CCmpRangeManager and the slowness here is not due to the spatial data structure at the moment. So the argument for using an octree is that it should be more efficient for the '3D' operations I mentioned since it will be able to filter out more stuff. It is hard to say which will actually be faster in practice though.

bigscreenshot is just a really high resolution screenshot, it doesn't work very well since it tries to stitch together multiple shots. Quite a few in that thread are actually made in Age of Mythology. To get a whole map screenshot you can use Alt-D to open the developer console and uncheck limit camera and enable reveal map. You'll have to manually position the camera at the right zoom. Then use F2 to actually take the screenshot.