wraitii

Would you happen to have a date/date range in mind for that? I've described my current idea here, for the record.

I'm going to try a new format for the spatial subdivisions which would remove the need for uniqueness sorting, potentially improving efficiency. Basically it's like spatial subdivisions but subdivisions would be a lot smaller ( like about a big bigger than a building footprint, so that most entities boundaries are smaller than a single subdivisions). You only add entities to the subdivisions their center is in, and when you range-query you return the subdivisions around your query too (see schema) sp that you're sure to get it. Entities that are too big would not be put in the subdivisions but at the basic level, so all entities would be considered "close" to all other entities. If we can manage to have few enough of those, this should work well. On the schema, the black lines are subdivision limits, the red square the range query, and the reddened squares are what would be returned by the existing query system, which needs to be sorted for uniqueness, while my method would also return the green squares, but won't sort. So maybe that'll be faster, maybe it won't be, we'll see. My hope is that if we make subdivisions just bigger than most item bounds, we'll have small subdivisions so we wouldn't add too many items, yet it'll be quite efficient since it's still all vectors and mostly static, and we won't have to worry about doubles and stuff like that which would allow faster queries. Maybe.

Hey lucas, usual procedure is opening a ticket on Trac, starting with [PATCH] since you'll post a patch too. It'll then be reviewed and if it's good we'll commit it. However right now trac is down.

I'm all for reverting that particular change. I've got an idea for a change in the structure of that, some sort of custom tree.

I've fixed the errors that occasionally popped up when AIs built a new civil center, and I've improved the AI logic. It should now make dropsites better, and will try to grab terrain a lot more (probably needs some tweaking).

There's definitely something great about the fact that each artist can give his own touch to the game in his own personal way. But this is also not really an artistic project, so we need a bit of coherence in the big picture, and the fact that it's free and open-source doesn't mean it's free-for-all, we have requirements for arts, defined mostly by what the art leader likes (we had to draw the line somewhere ). Maybe it would be interesting for artists to let their minds run freer in their own mods, in a "skin the game" way sometimes, when you disagree with the game's current design. Just a thought. This is a great place to learn and get feedback on your stuffs, don't be taken aback by criticism, however hard it may be. Even if it doesn't get in the game in the end, you'll have made progress, which is also sort of what this project is about (Mythos would rightly argue that we first and foremost want to finish it, but still).

Yeah units would count. I'm not really sure there's a real performance downgrade memory-wise if we do this conservatively. Vectors are guaranteed to be continuous, and we could use a sensible limit on init (counting the number of entity in that subdivision) that would probably be enough once and for all, yet retain adaptativeness. Though we probably could use a cleverer data structure anyhow if we could figure one out.

Enrique: did you manage to use self lighting? I found nothing that should be obviously wrong.

We could support a "replace unit from production queue" technology which would achieve just that… Isn't there one yet?

We could also add minor variations to the texture files…

Interesting On my macbookAir it'd probably lag like hell. Anyway this would be a good map to try graphical optimizations and settings (such as disabling actor rendering…)

That's some more debug I forgot to remove.

I don't see any, I haven't yet started doing stuff with formations.

For purely technical reasons, I'm looking forward to this map. I think just from the broadcasting of messages it'd be too slow.

And it's a lock! This is getting uncivil and I don't see it coming back.

Nope, that's me committing debug by accident. I'll fix it.

I just committed a somewhat important change to the way workers choose dropsites. Please report if you notice the AI acting weirdly, or seemingly getting stuck (if possible, post your commands.txt for those games).

That does look very good (in a sort of mystical way because of the very green feel)

Actually it does make a bit of difference. The more often we use the same textures, the faster rendering will be (because of a process called batching, basically).

Historicbruno: because it looks a lot better I'm not sure what might cause your issue but OSX drivers sometimes suck. I'll see if changing the function somewhat cleans the issue for you later.

In my opinion it's still too static. I can only encourage you to try to make as many "intuitive" movements as you can, nothing should really stay static, even if it's just to slightly rotate it. For example the head should sway a bit too. You might also want to create some variations.

Don't worry about it too much, the game would have been slow even with actors once the map is over There's no way to do such a thing so far, but it would be an area of work to treat some entities as more dormant when they are unused.

I've done extensive changes to some functions so I couldn't really reproduce, I'll try otherwise.

Pathfinder is definitely not made to handle such big maps right now. Graphics can probably scale up way better as long as there are not too many entities (frustrum filtering is slow) and there are many stuffs that are repeated (several of the same tree…). Range Queries should hold up somewhat well, though again as the number of entities grows it'll suffer. AI is probably similar.

For the record I tried importing and reexporting and it failed differently/