sanderd17

I like your code, but it's not following our code conventions wrt code blocks (http://trac.wildfiregames.com/wiki/Coding_Conventions) Also, why do you have a note about "uint32_t that should be entity_id_t" when entity_id_t is just defined to be u32. It would be clearer to leave out the note there, and just use entity_id_t. "Magic" also isn't the most descriptive term. Something like "latestRangeCall" would be better I think. As it tells you what the latest range call was that had this entity. And if the latest range call is equal to the current range call, it means you already added it, so you don't have to add it again. But apart from that, very nice.

Hi Kay, normally, it's best to upload patches on Trac (http://trac.wildfiregames.com/), the patches get a nicer formatting there, so we don't even have to download them to read them. As for the spatial subdivisions, that code is likely to change, as there are a number of problems with it (s.a. a fixed, and easy to reach limit on the number of entities). I'll take a look at it.

First, you give a name to the hotkey in the cfg file (as you'll find a lot of names in the default.cfg). Then you make sure the GUI listens to that hotkey by adding it as an object. If you're using SVN, I just split-off the hotkeys, see http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/session/hotkeys. Either add a file (that's better when you have a mod, the file will be automatically loaded, and when we change the hotkeys, the change will also go to your mod). Or modify a file (if you're wanting to get it into public, or make a total conversion mod, so not relying on public).

You can also just make 2 versions, one with open gates and one with closed gates (gates best as a prop, as they need to be an actor later on anyway). It won't have the nice gate movement, but at least, players will see if the gates are open or closed. You can use animations to switch props. So there's no problem with this approach.

Just could reproduce the issue. Tasking a lot of units through a maze of small gaps caused the game to freeze 1 to 2 seconds, and indeed catching up the next turns. This was without the map revealed. There's nothing very bad about that catching up, but the engine should only catch up a few turns, and leave the rest as is.

We don't have a very "responsive" UI. So most of the time we need a variable text length, we either use tooltips (history screen, unit train tooltips, ...), or we use scrollbars (lobby and game setup chat screen, or game manual). Setting the size of a gui element based on its content is a difficult calculation that depends on the font size, language, ...

Can you try purely ASCII paths? Without spaces or dots too.

Can you give the exact error message, and the procedure you used to launch?

That's just an example. I could log the map settings JSON from there, so I can use it for decisions too. That's already closely related. There's a simple onRange trigger, where you just fill in a few details, and you get feedback when a unit entered the range you asked. The difference between the two is indeed only in the loading stage. In the game itself, there's no difference between regular triggers and victory conditions.

Map sizes are defined here http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/data/map_sizes.json Expressed in number of tiles (or vertices, that's only 1 difference). And it's also supposed to be the resolution of the image you're importing. All maps are considered square btw, with the corners hidden to make them round. I'm not sure about what programs you can use to render height maps. But the openStreetMap wiki has a lot of info on rendering stuff (mostly real world maps from real data). You do want purely greyscale images, as atlas only works on greyscale.

Should be fixed now: http://trac.wildfiregames.com/changeset/15339

Philip occupied him with it, and it's solved now.

Or just type "eyecandy" in the search box to find most of them. A note though, you'll find all models under the actors selection too, but none of the models there will change gameplay (and they can even be disabled with a setting). So if you're placing forests, always take your trees from the entities list.

Ok, worked out the details of victory conditions and triggers. Not fully implemented, but enough code to see it will work nicely (see the attached patch). Basically, if someone wants to make a victory script, he places a requirements-checking script inside gui/gamesetup/victory_scripts. When #2622 is in, all those scripts can be loaded automatically. Those scripts give basic GUI info (name to display, description for a tooltip, ...), a function to check the requirements using the game settings (i.e. everything set in the map JSON data part + specific settings for that game, s.a. starting resources, number of players, ...). As the variables in that JSON part are free, a victory condition may require a certain specific variable to be set before enabling the victory condition. And as last thing, the script also gives a list of trigger scripts that must be loaded in order to enable this victory. The list has a different name than the default trigger scripts, but they can be loaded the same way as the current trigger scripts are loaded. This way, general victory conditions can work (by just always answering "true" to the requirements check), dynamic victory conditions can work (by checking existing data, or requiring a non-specific key to be set in the JSON), and specific victory conditions can work (by requiring a specific key in the JSON). We also need to make the map settings available to the trigger scripts (either making it global, or through the triggers component), so the victory scripts can ask some data for it. For example, a "king of the hill" victory condition might require a "hillToCapture" variable be set to a trigger point reference. Something like { ... Preview: "anatolian_plateau.png", CircularMap: true, HillToCapture: "A", XXXXXX: "Optionally define other things here."}So the requirementsCheck would check for the existance of "HillToCapture" in the map data. And the trigger script would query the value of "HillToCapture" to see on which trigger point its trigger should listen. With that figured out, I think we should go over to comiting it pretty soon. victory.diff

The problem isn't with the tests, but with the code. When you would run long and/or big games, you'd see the same problem (see http://trac.wildfiregames.com/ticket/2481) The source of the problem is known, a solution to it isn't.

Does it happen after a certain event (town or city phase upgrade, hero creation, ...)? And can you reproduce it every game?

No need to murder http://xmonad.org/ http://herbstluftwm.org/ http://awesome.naquadah.org/ http://i3wm.org/

Basically, Village phase is the phase where you try to build up your economy (so also try to slow down the economy of your enemy). Town phase is where you build your empire (claiming new pieces of unclaimed land, and fight for the pieces of unclaimed land). And City phase is where you try to concur already claimed land from your enemy. So yes, you're not supposed to attack buildings with simple soldiers. You're just supposed to slow down your enemy at that point (go around his towers, attack his economy). Once you get to city phase, you can make siege engines, and then you're supposed to try to gain territory from him. Of course, we're still trying to work out a nice balance for all this (how long each phase should take, and how easy or hard it should be to break this typical pattern by attacking earlier). But this is about the general idea. When you really need to get down a tower in phase II, well then you're a bad player, as your opponent shouldn't have been able to make a tower there in the first place. Towers also have a big disadvantage: when you go around them, they don't come chasing you, as opposed to an army.

For modding, it's quite simple. Every file with the format lg.somthing.po is loaded for a particular language. So mods can add their own po files (in any subdivision scheme they want), or overwrite the public po files with their own translations (but if they do so, they must replace the whole file, you can't replace string-by-string).

For point 3: I see Atlas offering you a fixed set of events (as they come from other code, it would be hard to create new ones), and a premade list of actions, that can be extended by creating extra actions (either by combining existing actions, or by writing JS code for it). Atlas itself would write the code to a trigger script, and to some custom data format (closer representing the UI). That custom data format could be read by Atlas when a map is opened (to allow editing of triggers). But Atlas shouldn't be able to interprete the JS code (that would be too hard, even if we keep it simple). I see it working a bit like Scratch, where you also have a predefined list of actions and events, and can combine them. Scratch can write JS, but it can't read it. In Scratch you can make new methods (actions), but no new events. For the same reasons I think. So pretty much what Spahbod said. About point 4: We can have a directory with JSON files containing info about possible missions. The JSON files would say what requirements they have for the map, and the map should list the fulfilled requirements. This is one level deeper than offering the list of possible missions in the map JSON, and because of the splitting per file, it would allow mods to add their own (as long as they use standard criteria). When certain missions are selected in the game setup, the scripts associated with that JSON could be loaded.

I think it's nice, for comparison, to add some numbers to it. I counted these by just grepping the lines that countain said path. So multiple occurences are counted multiple times. Like "Yes" appears 18 times in the gui, but that's probably the most extreme example. I didn't want to invest time in better calculation methods. The results for the current proposal are: Campaigns: 17 (should probably become bigger in the future, but not in the near future)Civilisations: 699Gaia: 134Gui: 1053 (of which 917 in "gui/" itself)Help: 106Logic: 30Maps: 567Quotes: 117Structures: 580Technologies: 719Tips: 136ToS: 39Tutorial AI: 80 (might completely disappear in the future and be replaced with a set of tutorial triggers)Units: 985I think the "Gui" situation is the most strange one. Gui should only have stuff inside "gui/" IMO. Splitting up gui/ seems fair enough, else you end up with over 1300 strings in one category. This is my proposal: Civilisations: civs/ (699 strings)Gui-ingame: gui/session (385 strings)Gui-gamesetup (anything setup and loading): gui/gamesetup, gui/aiconfig, gui/loading, gui/text/quotes.txt, (375 strings)Gui-lobby: gui/lobby (123 strings)Gui-manual: gui/manual (109 strings)Gui-other (summary, pregame, settings, ...): gui/ minus the stuff above (403 strings)Templates-units: simulation/templates/template_unit_*, simulation/templates/units/ (985 strings)Templates-buildings: simulation/templates/template_structure_*, simulation/templates/structures/ (580 strings)Templates-other: (286 strings)Simulation-Technologies: simulation/data/technologies (719 strings)Simulation-other: simulation/components, simulation/ai, simulation/data/game_speeds.json, simulation/data/player_defaults.json (145 strings)Maps: maps/ (597 strings)The only problem I see here are the unit templates. When we have some sort of in-game encyclopedia, we will probably also have to translate the "history" tag of the unit templates. Which means that for every unit, we get a quite long string extra. Maybe an other way of splitting up the templates could be per civilisation. Currently, there are 1851 template strings. With the histories added, this could easily go to 2500 or even 3000 strings. So when split up per civ, it would give you 12 civs + common strings, so on average 190-230 strings per civ. Which is a nice number IMO.

When we have capturing, it's quite possible captured units will transform into slaves. Maybe they could also be traded in some way. Not sure about that.

Wait for triggers, then your maps can set the sim rate, and all you have to do is launch the maps.

Except that we can't offer methods to read the mouse or camera position (as that's non-synchronised by design), we're about just as powerful. I think you could write an entire AI in triggers. And apart from setting the height map or textures, placing entities as in RMS'es is also possible. The only think I want to keep simple is the default interface. But behind the scenes, Triggers have complete access to all scripted simulation.

Compiling code is turning the source code into something executable (the exe for Windows). Not all code needs to be compiled. JS f.e. is interpreted at runtime (and thus also slower). But C++ code needs to be compiled. When we only modify parts that don't need compilation (like JS code, or even data files), we also don't need to do a new autobuild. Sometimes, when we modify source code, it even makes no difference in the behaviour of the game, so we also don't compile a new Windows version. As such, it's normally no problem when the last autobuild is a bit older than your current version. Just when something odd happens, notify us. Also, SVN only updates when you ask it to, not while playing a game. You can even tell SVN which version to use (in case the latest version is really broken).