sanderd17

If a unit can build a dock, it can start to gather too. Or start to trade with merchant ships. If a player has only a CC, and no resources to make a unit, he's lost too. Currently, we use a ConquestCritical flag. As long as there are ConquestCritical entities left, the player isn't defeated. Every unit, and all unit producing buildings have such a flag. It's easy to count (as we can't afford too long calculations every turn to see if a player is lost or not), and it's easy to understand. We might want to remove the ConquestCritical flag from the units. Though that could mean some players are defeated too early.

Mods can overwrite any files you want. So you can overwrite the ptol.json file to have both under one general civ. I don't think that's such a great idea though. It's only ever visible in the history screen (so not a lot of people notice it), and the Ptolemaics would be more related to the Macedonians than the Egyptians.

The game has entities, and entities consist out of components that hold a state and do actions. There's one very special entity, the SYSTEM_ENTITY. That holds data for the general game (like the terrain profile, the available templates ...). In A16 and before, the components on the SYSTEM_ENTITY used to be hard-coded. Now, you can register new components on that SYSTEM_ENTITY by using the RegisterSystemComponentType. I made that available so mods can also register system components.Apart from that system entity, every player in the game is also an entity. And every unit, building, tree or other object in the game is also an entity. All those have templates. In those templates, it's defined what components they have, and certain stats of those components. Here's the player template: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/special/player.xml So to add your component to all players, just put it in the player template. It will be initialised once per player, and have one state per player (excluding gaia). You see the statisticstracker is also registered there. Exchanging data from the simulation to the GUI should indeed happen via the GuiInterface. Either expand an existing function where it fits, or make a new one. In case you make a new one, don't forget to register it publicly. Else the GUI won't be able to use the function.One remark though. The GUI isn't synced between different players on a network. So functions called by the GuiInterface shouldn't modify the state of the components at all. Else you get Out-Of-Sync problems. I see in your code below that the GetChartData will stop the timer, and thus modify the state. This shouldn't happen. You just return the information, and let the timer run. The code looks good, apart from that state issue I mentioned above.

This will be part of the simulation, right? You can register a timer in the Timer component. A repeating timer is perfectly possible. But if you use OnUpdate, it will be called every simulation turn. The message passed also tells you how long the turn took (which is different between multi and single player, and might change in the future). And you do need to add it to an entity too. To add it to the system component, you can use the RegisterSystemComponentType (only in svn). Or else you need to add it to the player template.

The problem with props is that they're only graphical, and not network synchronised. So to have turrets, it must be placed on a fixed offset wrt the main entity. Placing it on a fixed offset from a prop point gives you the same problem again. So can it be used to pick up weapons? No, it can't be placed relative to the soldiers arm. Can it be used to have a fortress demolish part by part? Yes. But this requires additional scripting. Visibly gaining units on walls and on any other structure is possible and already implemented. For moving things (like boats), I need to look into the obstruction too. As now, units on boats will most likely hinder the boat movement because they have their own obstruction.

We should ™ have triggers in A17. With triggers, map-custom scripts can mark players as won or lost at any time they want.

You can send them from the GUIInterface to the AIInterface directly, like this: GuiInterface.prototype.PushNotification = function(notification){ this.notifications.push(notification); var cmpAIInterface = Engine.QueryInterface(SYSTEM_ENTITY, IID_AIInterface); if (cmpAIInterface) cmpAIInterface.PushEvent("Notification", notification);};Querying them from the AIInterface also works. But then you need to figure out when the messages are pushed and when they get flushed again (they disappear from that list when they get in the GUI I think). I think the notification.type should be "chat" in case of a chat. But you'll also get all other sorts of notifications (like building failed notification). I don't know much of the AI code, so I can't check if these events come through. But if you know it's working, I can commit your patch.

You should be able to reroute the chat from the GuiInterface to the AiInterface (in public/simulation/components), and pas the message on to the ai like that. Well go through the cpp part, but that's very liberal. It just clones objects (which is needed for future parallelism), and passes them on.

The API is scripted too (for the biggest part). And if you add something, just give us a patch. If it doesn't break other code (which is unlikely when only adding a feature), it will get committed.

No, it doesn't. We usually have a lot of pathfinding requests per turn. Because of the number, every pathfinding request could be calculated without parallelism, but the different requests could be executed in parallel. So the algorithm doesn't have to be prepared to split in multiple instances, but the interface to call the algorithm must be thread-prepared (i.e. start calculating a bunch of paths together). That interface is already prepared for multithreading.

I can't reproduce this. Can you confirm it's still present in SVN?

Font sizes are pretty hard-coded. You can change a font file, so texts will look bigger, but this will change all texts that use those fonts (including the buttons), so it will lead to texts being too big. Maybe we can introduce new tags (like [h1], [h2], [emph], ...) that will be replaced with user-configurable fonts. Not sure how good this will work. In your case, you could also edit the resolution of the game in the config file. Normally it should be stretched when playing in fullscreen. So your fonts will appear bigger.

It's a bug, but they don't deal extra damage, they just deal it earlier. To let the formation stay in formation while fighting, all units give damage to the enemy unit that's next to the formation. So also units in the back of the formation deal damage to it, though they technically can't reach it. This is intended behaviour. The problem is, when a formation attacks a single unit, it still has "attack power" left. Some units didn't do the attack, because the target was already dead. So it's coded they search a different target in that case. But for the new target, they should check the range, and that's forgotten. As a result, the if the formation reaches one target, it can kill all nearby targets until the attack power of that formation is up. After that attack, the formation does split again, and everything works as it should. So some 3 to 5 units will be killed too early, giving the testudo a big power.

The API is only an experiment that grew by accident. So you can let it grow more. Normally, the first AI programmer to want a feature is the one who adds it to the API. But do watch out for localisation. An AI can chat to the player in his local language. So the AI should somehow be able to accept local messages back, without causing problems when multiple people in a game have a different language.

Well, please first check if the games you see actually differ. We already found a cause of OOS in our code, and fixed it locally. But that cause normally shouldn't cause different games. It should only show you an OOS message.

Hephaestion and leper will probably cooperate on a mod manager. Probably for A17. There isn't a lot left to be done. Only a gui and some changes to the VFS for a correct initialisation. Users would still have to place the zip in the right directory, but the launching the game with the mod should be easier.

Mythos_Ruler, just a technical thing. Right around the base, everything is clear, so you the random map knows it can place a stone and a metal mine there. While further on, stuff is distributed according to random patterns. So it's possible the RMS wants to put the mine in a forest, finds no place for it, and gives up. In that case, it's not sure at all the player will have a mine near to his base. On skirmish and scenario maps, this is no problem. Maybe it should be better to have a small stone and metal resource next to the CC (so the player certainly has something), and just distribute the rest randomly.

It's a null pointer. That's very hard to debug, as the game crashes immediately, without leaving any logs from it. The only way to see where it comes from is by running the code in Visual Studio. Maybe you can first try to update your graphics drivers? Not sure if that will help.

It could be a building to train the champions, like Athens has the gymnasium.

That's quite unlikely, as we can't even get A16 compiled for Mac. If you check the version in the main menu, you probably have Alpha XV Osiris. Anyway, that's the least of our concerns for Mac now. So it probably won't be fixed for a while.

In your terminal, go to where the pyrogenesis binary is (I don't know the installation paths on a Mac), and execute that command "./pyrogenesis -editor" (without the quotes). And I think you mean A15 with the newest version. As we recently released A16 for all platforms but Mac, as it's seriously broken on Mac due to their upgrades.

What version do you have? Can you try opening atlas via the command line (./pyrogenesis -editor)?

You can open the pathfinder, unitmotion and obstruction overlay (via the developer overlay: ALT+D). That shows you the various aspects of the pathfinding. It marks tiles invalid for the long range pathfinder (the red tiles), you see unit obstructions (as squares that don't rotate), and building obstructions (as more precise rectangles). You also see the long and short paths when moving units. You see when a unit reaches a new waypoint (given by the long range pathfinder), and calculates a new short route to the next waypoint. It's quite interesting to see how it works now. You can experiment with gaps that are small, with units in the way.

iNog, no reason to unnecessary clutter other topics. Pathfinder discussion belongs in the pathfinder topic. Nantchev, don't worry about that pathfinder stuff. It's a programming thing. Welcome to our forums. I'll send a PM to Enrique so he comes take a look here. Enrique is our art dept leader and is the most important person to know. You can take a look here and see if something fits you already: http://www.wildfiregames.com/forum/index.php?showtopic=17730 Animating for the game isn't the easiest thing to do, and animations were broken for a long time (originals lost, and unable to recreate the bones needed to make new animations). But Enrique figured this out just some months ago (so we have some recent animations on old meshes, like the testudo animation). Anyway, he'll know more about all that stuff.

What if the gap is just wide enough to fit one unit, so you can't do that parallel path thing. Or what if a row of units is blocking it. Also, all moveable entities have axis-aligned obstruction squares. That means the obstructions don't rotate with the unit. This is done for performance, as a simple position + offset is a lot easier to calculate than a rotated offset. Rotation requires you to calculate a sine and a cosine, causing it to be a lot slower than a simple addition.