sanderd17

If you get errors, it's best to copy paste them into a separate report (like a new thread). See http://trac.wildfiregames.com/wiki/GameDataPaths on where to find the different logs per OS (note that logs are overwritten when a new game is started, so it's important to copy the logs immediately after your game with errors)

Setting capturing as the default attack (certainly for this version) was a definite decision. Else the feature would go unnoticed, and players wouldn't know what was happening when someone did start to capture their buildings. Capturing is meant to have a bigger advantage against an enemy, certainly when the enemy isn't defending a structure properly.

You can use SVN if you want incremental updates. But patches and binary files is a difficult combination. We prefer to put our time into other features.

There is no MP server. Anyone who starts a game becomes the server, and needs to allow incoming connections. Unless you mean you can't connect to the chat server. So some questions: how do you try to connect (via the lobby or via direct ip)? Are you and your friends on the same network, or on different networks? At what point does the connection fail, and what message do you see?

The plan is to have a mod repository at some point. We probably won't host the mods (as they can be huge), but we can index mods and make them accessible to the players from inside the game. The mod manager would only need a download button and an implementation for downloading. And of course we need the server infrastructure, and a way for people to register mods.

Btw, the invulnerable thing in armour.js is used temporary, f.e. when promoting. It doesn't block others from attacking it, the attack just doesnt do damage. Using this for permanent invulnerability would seriously confuse players and the ai.

1. No, there isn't yet, though I would like to have that setting too, but it might complicate development when we don't have the ability to delete an annoying tree or Bush in the dev overlay (f.e. one that blocks the ai). So we need to be a bit careful with this feature, and the ai would also need to understand it can't delete something. 2. It should be possible by just not giving an armour component. However there are probably some bugs with this, as it's never used in the main game. Health is also needed for capturing, as it influences the capture speed (though we could also assume default capture speed when no health component is present.) 3. See the other two. Having delatable as an entity property somewhere would also open the door to easier implement deconstruction as a unit action that takes time and/or resources. Not sure if we want that, but opening the door for mods to implement this isn't bad for sure.

I should mention that with the new pathfinder, the infinite chase issue has returned (not directly because of the pathfinder, but because of the changed interface with the unitmotion component). It is something we should probably fix before A19, but for now, that makes the speed of units a lot less relevant, as even a very slow unit can successfully flee from fast units.

The colors in Atlas are not restrictions, they are just hints. You can also place a building where it appears red. But indeed, in the case of the special buildings like walls and docks, they're bad hints.

This post is over 7 years old. There's no need to necromance it. The chances that someone is working on a 7 year old post is very close to zero. I'm closing this topic now. Archived topics shouldn't contain new information. If you have stuff to show us, open a new topic.

Thanks for these voices, there's indeed no Germanic faction planned for part 1. So they will not immediately be useful (there's no work started on part 2 yet). However, they might be usable for a mod meanwhile. Also, as the time range covered by proto Germanic is rather big, and it has quite some sound shifts during the time, did you focus on any particular timeframe?

Gallic fields implements something like a common/neutral enemy. Though it's still possible to fight each other normally.

Anyone can add units to the game, like when creating a mod. I just wanted to know if you tried it.

Did you try getting some units in-game? The easiest way to donate units would probably be to create an archive with your source files (models, animations, textures), and release it under a license like CC-BY-SA 3.0 or compatible.

Hi Arunas. This form isn't really needed for programmers. It's better to just write some code and come to discuss it on IRC (#0ad-dev on quakenet). Or the other way around. If I understand you correctly, you want to write unit tests? Maybe also other tests? That would be very handy, as currently, most of our components are untested. Thanks for wanting to help out. See you on irc.

These structures are used in the plane demo map (yes, 0 A.D. has airplanes, and they shoot burning ballista balls).

Gaia is the godess of the earth (https://en.wikipedia.org/wiki/Gaia_%28mythology%29), so in our game, everything that doesn't belong to a specific player, belongs to the earth or gaia.

Air units are a bit of a problem, as they will always target the footprint when attacking (and hitting the footprint will count as a hit). Turrets would be easier to support in the current state. Though there are different forms of turrets, on different sorts of entities. That makes it a bit hard to implement correctly. Note that there is a ticket open which describes the current problems with turrets, and solutions to some of those: http://trac.wildfiregames.com/ticket/2577 (it should be possible to get turrets working for the biggest part using scripts only).

Running the AI on every computer makes it impossible for the host to cheat with the AI. Deterministic AIs also make debugging easier, as we can reproduce AI behaviour of a certain game and see what went wrong. Determinism is generally something wanted in multiplayer development, and thus enforced by OOS errors.

The wiki is open for everyone. So if you can document it (perhaps with a link to an example), that would be great. As I have never tested this feature, and the public mod has no examples of it, I find it hard to add documentation.

It's indeed possible to delete a file by adding .DELETED to the end of the filename. So if there's a file template.xml in the public mod that you don't want, putting a template.xml.DELETED file in your mod will remove it (the contents of the file doesn't matter).

I made it a bit easier to add new backgrounds, and you can decide which layers tile and which don't. Currently, you can add up to 5 layers for a background set, if you want more, it's easy to change. To add a background set, you just need to add two small files. See the files in http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/pregame/backgrounds . First, you have to make a .xml file in that directory, similar to http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/pregame/backgrounds/hellenes.xml , there you define a sprite for every image layer. Every sprite must have a unique name, and define what texture to be used. The first sprite is an example of a tiled sprite, the other two are non-tiled. Best is to at least make the background tiled, so that people with big screens get a nice view. Foregrounds can be tiled or non-tiled. A non-tiled sprite should always have a 2:1 image resolution. Else there will be some strange stretching. Then, after the sprites are defined, you need to add a simple JS file, similar to http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/pregame/backgrounds/hellenes.js . That JS file defines the order of the layers (the background should be placed at the top). You also define whether that layer is tiled and which sprite to use for the layer. The offset defines the layer motion as a function of time and the screen width. The Math.cos function makes it oscillate to the left and right (note that for tiled layers, you don't need oscillation, and you can just keep scrolling to one side). An offset of 0 would make the image centred on the screen. The constants are there to define the speed of oscillation, the width of the oscillation, and the average offset to the screen centre. I hope this makes it easy enough to add backgrounds in a way the artist (and not the programmer) likes. EDIT: if you add backgrounds, and you want to test them, it's obviously annoying if they appear only randomly. The best way to stop loading other backgrounds is by giving the other JS files a different extension (f.e. "*.js.backup"). That way, they won't be read.

It's because we moved away from the _generic_ phases. See http://wildfiregames.com/forum/index.php?showtopic=19838 The problem was that, to add a civ-specific town or city phase, the according _generic_ technology had to be edited, as it had the civ-specific techs as a requirement for autoresearch. This meant that it was impossible to combine two mods that both had a civ with a civ-specific phase (as one mod would overwrite the tech of the other mod, resulting in a civ that can't research one of the phases). So we moved to the "replaces" key, in which a tech can "replace" a different tech, and unlock all its content without applying its modifications or its cost. So currently, the _generic_ phases are removed, and the effects are stored in the regular phase tech and the athen phase tech, while the athen phase tech replaces the regular one, so unlocks the same features. See http://trac.wildfiregames.com/changeset/16678/ for the commit that removed the generic techs.

That is the plan, we're currently making an announcement draft that should explain the changes so regular players can understand it.

Hmm, I got this error too, but it's gone once a cache is build for the actor (so it doesn't happen a second time, unless you modify the actor). This is something strange for sure. EDIT: and the iberian dock and cc are missing some materials (and for a big part transparent).