sanderd17

It's not recommended to have spaces in your path. I see "0 AD SVN", that's not a good path. There's no guarantee that the tools we use work with spaces. And we even got some problems in the released version when people install it in a path with spaces. Also, when you want to do a multiplayer, you must always make sure both players are on the same revision, by updating SVN, and telling which revision you're at. When you guys play the most, we code the most. So it's perfectly possible you just updated, 15 minutes later you want to play a game, and you see the version doesn't match with your mate. As to what might not work? It's possible the game doesn't start at all. Or more subtle issues like not being able to reach 2nd phase or so. Basically, anything can go wrong. Wrt compiling. We compile the thing for Windows (as compiling on Windows is indeed too hard). In Linux, compiling is a simple "make" command away, so we don't bother with providing a pre-compiled version of it. We do have to manually tell Philip's server we want a new Windows version. Compiling usually takes some time (I think it's currently around 30 minutes), and results in a new version (like this one: http://trac.wildfiregames.com/changeset/15291) providing a new exe. It's possible we forget to fire the autobuild after an important change, so your game will likely spit some errors in that case. It's also possible we started the autobuild, but it's still building while you try to play. In that case, wait a bit. On Mac, compiling is hard too. But you need a Mac to compile for a Mac. And Mac servers are hard to find. So we can't offer that pre-compiled either.

Maybe someone should support us in getting extra monitors. So we can finally test multi-monitor setup

The different GUI objects are all defined in C++. It's not possible to make new ones from JS. Here you have buttons, checkboxes, lists ... http://trac.wildfiregames.com/browser/ps/trunk/source/gui I think chart could be a custom gui object.

The tracker itself might become part of the public mod (if you want that). I don't see the graphs in the public mod though. They're implemented a bit too hacky. If you could implement it using a nice, new GUI object, that would be better.

Makes sense to be able to see the ping time for the hosted games, and if hosts can also see the ping time for people who joined. Maybe open a ticket for it (first check if nothing exists).

The lobby gathers the stats from cmpStatisticsTracker. Nothing more fancy. Maybe your object can also be send, if it's not too big.

It's not that hard. The damage for each statistic is calculated as AttackValue * 0.9^ArmourValueThen the resulting number is summed for the 3 possible stats (pierce, crush and hack), and together, it's the reduce in hitpoints. If an AttackValue for a certain stat is zero, then it causes no reduce in HP. If an ArmourValue is zero, then the reduce in HP is just the amount of the AttackValue. Then you have the bonuses. Which are just multiplicators if the damage in HP. More elaborate damage (like splash damage) is a bit more difficult, as it takes the distance between the two into account.

The classes have no hierarchy, an entity has multiple classes, and a class appears on multiple entities. They're merely tags. Those tags can be used in the code to restrict stuff (I.e. restrict females to attack soldiers), to apply bonuses (I.e. the attack bonuses) or any other use of filtering. So it's nice, when f.e. a technology states it affects military buildings, that you can see in the gui that a building is military. Otoh, some classes are really to broad (like you know what a unit is), and shouldn't be displayed. That's why there is a distinction between visible classes, and classes that are only to aid programmatic filtering, but are really clear to the user without putting it in the gui.

The plan is to remove that info from the tooltips of the gui. Now every unit has a class list which sometimes matches, sometimes not, and is a pain to localised. I first tried with the buildings, to see if it works. But the units should follow. There's a helper function to extract a single class list from the template in the simulation helpers. But that probably needs to be moved to the global scripts.

% territory would probably need some engine code for performance reasons. Looping over every tile in js will be too hard.

A trigger editor isn't for now. But we should try to keep the interface simple (at least the most used cases), so it could be done visually at some point in the future. That's the plan

Right, it was the mainlog I needed. That interesting log isn't very interesting after all. It looks like the resolution is correctly loading indeed. Can you check your system resolution again? And try smaller resolutions if that doesn't work.

When you are modding, I recommend you to mod with the SVN version. So your mod is about ready against the next version comes out. And you have something stable you can distribute to your friends. That OOS problem is known, we've found the cause meanwhile. It's related with firing on someone who's just garrisoning. Difference is very small though, happens only for a split second, and normally (AFAIK), the states come back in sync again. The turrets are in the game (well, the positional part of the turrets, there are still some scripts missing, but it's hard to write code that doesn't get used). We probably won't add a technology that replaces units in the production queue, because it's a bit complicated and error prone. There has to be found a different way to do that.

Can I see your interestinglog.html? See the GameDataPaths on where to find it.

Because the options menu is only a few months old, and most of the options in there make the game crash when you change it in a running game. When you want to change something, you still have more chance if you look into the config files.

You do such an effort to go here on the forums to post your complaint video. But editing a config file was too much? Or reading the manual and pressing ALT+ENTER?

Here, I'd like to discuss triggers (http://trac.wildfiregames.com/ticket/52). The work started by Spahbod, but I've taken over, and redesigned big parts of it. First of all, triggers need to have a big freedom. So in its basic form, triggers are just a script (or multiple scripts) the map loads when all entities and components are initialised. From that point on. Triggers can modify existing components, subscribe for messages, schedule functions for later execution and all stuff you like to imagine. Of course, such freedom is hard to handle. For example. If the triggers need a state to save (and most do), they need to serialize that state to support rejoining in network games and saved games. We'd also like to keep our maps more or less compatible with next versions. So triggers shouldn't modify too much in the simulation either. So there is a special component (the Trigger component) made to be extended by triggers. Functionality in the Trigger component The Trigger component also offers some basic functionality to triggers. It has 3 important functions: RegisterTrigger, EnableTrigger and DisableTrigger. Triggers are a combination of an event on which they're fired, an action to execute, and possibly extra data. There already are a number of predefined events, But they're handled differently in the background. Some events are handled by the Trigger component listening to messages, other events require other parts of the simulation code to warn the Trigger component. The events are made extendible. So we can always add new ones when needed. The action is the functionname defined under the extension of the Trigger component. As part of a "keep it simple" exercise, the combination of event and action has to be unique. So all sorts of triggers can be enabled and disabled without extra keys. This does limit the triggers a bit, as f.e. the repeat time of an interval trigger is part of the data. So there can only be one trigger with "OnInterval" as event and a certain function as action. But it should make it easier if we ever try to make a trigger editor when we have a basic interface. Of course, these limitations are only limitations in the interface of the Triggers component. As the code is completely part of the simulation. You can just call the timer component directly, and register your timers there. But this will require you to keep a key for that timer, in order to disable it again. So there goes simplicity. If we ever want to have a visual trigger editor (maybe something based on Scratch - http://wiki.scratch.mit.edu), we should have an interface that's as simple as possible. Trigger points Another thing added are trigger points. Those will be markers, only visible in Atlas, that can be used in triggers to define positions on the map (without having to calculate coordinates). A trigger point has a reference (A, B, C, ...), and all trigger points with a certain reference can be queried from the Trigger component. Trigger points can be used to spawn units. To give as a target position, ... Currently, they're also the only way to support range triggers. When you register a range trigger in the Trigger component, the Trigger component passes it on to the matching TriggerPoint components. So that component will listen to the OnRange messages (which is a lot cheaper than listening to all range change messages), and will execute the action for it. It could also be extended to territory events (i.e. the TriggerPoint executing an action when the territory under it changed). Trigger points also have an owner. So you won't run out of trigger points very quickly, as you can make a difference between trigger point A for player 1 and for player 2. (De)Serialization (saved games) By extending the Trigger component. There are no problems at all with serialisation. All functions should be defined under the Trigger prototype. Like Trigger.prototype.MyFirstAction = function() {/* Do something here */};Those will not be serialised, but rather be reloaded when loading the game. So they should not have a state (i.e. not change throughout the game). For saving states, that can just be done as with all other components. By using the "this" keyword in functions registered under the Trigger component. F.e. Trigger.prototype.MyAction = function(){ this.myState = "start";};When serialising the Trigger component, they get serialised with it. Helper functions Something I'm still unsure about is the filesystem organisation. Map triggers can be placed anywhere in mod/maps/. As I'm now imagining it, a map with triggers should have one map-specific script (probably having the same base name as the xml and pmp files, and being in the same directory). That specific script could do actions on specific entities of a map. And then, there could be multiple helper scripts in maps/scripts. Those scripts could be added when needed, and provide small to big utility functions, s.a. getting the owner of an entity to spawning units from a certain trigger point, to really complicated, but still general stuff. Those helper scripts won't be loaded by default, but should probably be organised per topic. So if a map-specific trigger wants to use a method from those helpers, it can just include those helpers. I hope, with the current design, we keep the simple cases simple (so many people can make triggers), but we also allow for great customisability of maps.

It would be nice to test the UPnP issue at least. If that makes every multiplayer game unplayable. Either UPnP should be disabled on the mac build (IIRC, there's a flag for it), or it should be fixed. If there are no other gameplay problems for Mac, I think it should just get released.

It could be coming in the near future. But I haven't heard anything from trompetin in those 3 weeks. I hope he picks up the work again. There is a possibility to run a random script in Atlas though. Those normally create forests you can move. But of course, you need to start from one random map, as you can't move between different maps. One other possibility is editing the XML file directly. Either changing the name of the entities in there (like replace a pine with an oak tree), or copy-paste parts of XML to other XML files. But know that you'll copy-paste the exact location too in that case.

http://trac.wildfiregames.com/ticket/96

Hmmm, there seem to be no entities for player 1 and 3. A lot of trees belong to player 2 and 4, but I don't see any buildings for player 2 and 4 either. Also, qbot doesn't exist anymore. It's better to leave that empty, so it takes the default.

That's more formation handling than animation. It should be possible in the long run. But it will require some iterations of formation handling.

Uh, this badass is a Belgian. A quite well known statue on the market of Tongeren (Limburg), statue of Ambiorix, leader of the Eburones. https://en.wikipedia.org/wiki/Ambiorix The statue is made in 1866, some 30 years after the independence of Belgium. And it was made to depict the Belgae as an ancient and powerful people to justify the independence. The De Bello Gallico, where Caesar describes the Belgae as the most fierce of them all was very popular in those days. So it might be best to question the rest of that source too.

1. Place skirmish entities. S.a. the skirmish CC, skirmish infantry or other skirmish buildings. They'll be replaced by civ-specific buildings on game start. 2. That's not possible (yet?).

Second warning to this topic. Keep it on topic now. And no more personal attacks.