sanderd17

I don't think that adding a step in-between can make the UDP traffic that much faster than a direct connection. After all, it's not the bandwidth that matters most (the packages are rather small), but it's the latency that matters. And latency will only increase when you increase the distance and the number of devices in-between.

@wowgetoffyourcellphone, better fix it like it should IMO. @iNcog, not sure how including an external service would help with this ...

This is not a bug in the main game, but either you're using the current main game with an outdated Millenium AD mod, or there's a bug in the current Millenium AD mod.

400ms will give a better feel in the start of the game (when calculations easily fit in that time), but it will make the lag worse in the end-game. The values are defined here, if anyone is interested: http://trac.wildfiregames.com/browser/ps/trunk/source/network/NetTurnManager.cpp#L41 Both the host and the client will have to change that value and recompile to test it though.

500ms is really needed for the average multiplayer over the internet. So adjusting the hard-coded value probably won't happen. But I do understand that it's a bit much for a lan game, where the lag is lower. A turn needs to be short enough to register commands quickly, but it also needs to be long enough to fit all network traffic and calculations. Else the game time would start to go slower, and everything would start to happen in slow motion. So these values are a compromise to support the average game.

1. The turn time in MP is set to 500ms, while in SP it's 200ms. This is to allow the network connection to send the commands in time, so you don't get game lag (game time taking longer than real time). The disadvantage is that commands indeed seem to come through with a bit of a delay. It should indeed be possible to reduce this value in the case of low latency connections (like on a LAN). But that's not possible yet since the value is hard-coded. There are/were plans to make the value dynamic: test the latency every once in a while, and update the turn time to match it. Though that's not implemented yet, and I don't see it happening very soon (as it's not that easy to do). 2. Clicking at the top of a building or unit works fine for me (except for foundations that being build). Maybe that's an OS-specific issue? Is there any correlation between those reporting the issue and the OS they use?

I made such a slow-delete feature here (as a mod): But so far didn't get any feedback on it. There are of course different ways to implement it: stop at 50% CP or not, make it possible to stop the destruction, how slow should the destruction be, ... But it would also be possible f.e. to require 90% CP, then players will be less eager to delete their structure. And thanks to things like territory regeneration, it shouldn't be a problem to let a building reach 90% when it's not under attack. So if some want to test it (in single or multiplayer), go ahead.

It's nice you want to spread the word. Though I don't know if we will be able to monitor the group closely. So as long as it's for discussing some strategies, sharing games, ... that's fine. But if someone actually has a bug to report, or a support question you can't answer in your group, it would still be best to guide them to the forums, trac or IRC.

Most online tools we have are hosted on a single server (the downloads, the lobby, the forums, ...). And the game is quite large (larger than most other applications). So if everyone would download the game directly from the server, we would most likely hit our maximum bandwidth (certainly right after a release), which would cause issues with about all our tools. But currently, about half of the people seem to use torrents to download the game. Torrents don't take a lot of bandwidth from our server (it just sends some statistics and checksums back and forth). Instead, torrents enable the sharing of the game directly between people who already downloaded the game and people who want to download the game. It's correct that one download directly from the server doesn't matter, and won't cause any problems for the server. But I hope you understand why we prefer torrent downloads, and thus why that button is so much bigger than the link.

The game settings also have an option to set a "cease fire" time if that's more what you want.

You can always put the AI difficulty level lower (in the AI settings before you start the game). If you set the AI to sandbox, it will never initiate an attack (but just gradually expand).

@oshron, just to be sure. You realise that the big download button says "torrent download", and that there's a smaller link below that says "direct download"? Did you click the torrent download or the direct download? That said, we prefer you use the torrent download since the game binaries are now hosted on our own servers (after some other open-source projects reported their binaries got hijacked by sourceforge, and filled with adds). The direct download is only there for people who can't get torrents to work. Luckily, the downloads page also links to the BitTorrent FAQ which explains in detail how to install a torrent client, and why it is important to us to download it via that way ...

That is being worked on: http://trac.wildfiregames.com/ticket/3899 (to be included soonish)

How can a feature that is available for both parties break the balance? A feature like that can be annoying (make a game too slow or too fast, cause too much micro, ...), or it may make the attack or defense easier or harder. But if it's available to all players, it can't unbalance the game.

@wowgetoffyourcellphone, you mean a restriction where the tech is only available if the civ of the template matches the civ of the player?

Using techs on a captured building isn't implemented yet, and when it's done, it should be done carefully (so we don't get unexpected stacking of almost similar techs). What you propose (using the civ requirement) indeed seems like an option. Perhaps we should review all techs so they get a civ requirement, and then the technologies can just be enabled in the production queue. This is the line that does the check: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/ProductionQueue.js#L155 So if you check all techs in your mod, and you override that function in your mod with that check disabled, it should have all techs when a building is captured.

Clarifying @fatherbushido's comment: it indeed can't work like that for the following reasons The Player has no owner (but it is the owner), which makes the code in a lot of different places just a bit different The auras were first made as only range-based auras. And as a result, the aura-giver must still have a valid position.

The datatype="tokes" thing in the xml is missing.

@niektb, you can reuse a lot of the tools we use to translate the game. If you're interested, do let us know.

This works since a year or two, but it was a small fix. Before that fix, every component had its own scope, so you couldn't modify the code of a component in a different file. Which is safer from a code POV, but doesn't work as well with mods, since they have to replace complete files that way, and possibly have to maintain pieces of code that are hard to maintain (imagine you add some different states to UnitAI and you have to maintain the entire UnitAI file for every change we make to it). Now, the component prototypes are global variables, so once they are created, you can modify them from any other file. Thus if you make that your file is loaded after the original file, it's quite easy to add methods to it, or replace methods with different code. In some cases (like when you add listeners to other messages), you have to re-register the component with a call like Engine.ReRegisterComponentType(IID_Player, "Player", Player), else the engine won't pick up the extra messages. Btw, this is also how triggers work (extending the existing trigger component), and trigger scripts can acually extend any component they want ... but I guess when you need that, it's better to make a complete mod.

Apparently, the AI code already used a term for this, so it's now called "ExclusiveAlly" (and "ExclusiveMutualAlly").

Not really, since techs can't modify stats on other players, and auras would need modifications to be put on abstract entities (like the player entity). So neither is currently adequate to encode team bonuses with.

Actually, think about it, this is an ideal way to show the moddability of the game. As a mod, you'd only have to create a file simulation/components/Player_MyMod.js with the following lines in it, and it would work (note that the file needs to be alphabetically loaded after Player.js, so that's the reason to use an underscore and not a dot). Player.prototype.IsStrictAlly = function(id) { return (this.playerID != id) && this.IsAlly(id); }; But since we could also benefit from this code, we'll just commit it to the public mod, so you don't have to bother with it.

The player is always considered as his own ally. The Auras code just uses the terms of the diplomacy code directly. Changing the diplo code would probably result in some bad bugs. And using the same terms for different meanings would be annoying too. Perhaps making a new diplomacy term, something like "StrictAlly", that excludes the own player would be the best. Any suggestions for names (or other solutions)?

Do you want your real name in the credits too? And I guess the 2D art would be the best category for your contributions, do you agree?