sanderd17

In 0 A.D. towers work without men in it, however, they work better when additional men are garrisoned in it (an unmanned tower isn't worth a lot). The animation can indeed be done a bit better, currently it only shows a flag when there are some men in it. for building the siege engines, getting it from a building has some advantages. You can't boom the amount of siege engines you have, as you'd need more fortresses for that, and as you can create multiple siege engines in one batch, it's less micro. So it was a design choice to do this in a building. However, it's perfectly possible to let soldiers build siege engines in a mod.

I tried some things in Atlas (I think that's what you mean with editor), but all I tried seems to work. Could you give exact steps to reproduce?

How will you fight invisible units? F.e. if we add a unit, that also adds graphics, and it might make a civ stronger, thus we may need to reduce the stats of other units. AFAICS, only full checkouts are possible, and that's already possible when you convince a few players to play on the SVN version, which can be updated every day.

Farmers generally do their very best to have fields with straight edges and right angles, only deviating from that because of natural reasons (like streams). Even without machinery it's easier to work in straight strips. However, crops tend to grow worse near the edge, and certainly near the corner of a field. But then you get weird stuff when you place two fields next to each other again.

So idea for adding low bridges: * Change Obstruction component into an ObstructionModifier. Instead of just adding a general obstruction, this could add or remove obstructions of different size per passability class. * Implement a virtual terrain, bridges could modify the virtual terrain to let units follow that instead of the real terrain. By default, values are null, but when non-null, these terrain heights are preferred over the non-virtual terrains. This way, a bridge could enable units to pass through a part of deep water, while it could disable boats to pass there. As such, influencing the pathfinder (that shouldn't know about heights). While the virtual terrain could be used to lift units at those position up to the bridge level. It could also make stairs possible, where the passability of mountains can be edited by the stair. This wouldn't need a virtual terrain though.

It all depends on your definition of art. I don't think I see art when I look at many modern and post-modern things. In Dutch (and related languages like German), art is translated as "Kunst". Which is in its term derived from the verb "kunnen" or "to can". So art in its pure form is reduced to someone who can do something special. The English art has similar relations to "artisanal", which is also about the ability to create stuff yourself. Art is a skill. In that view, I don't see a lot of post-modern art to be art, but many games are certainly art. It's obvious to me that the textures, 3D models and music are art. But also the storyline, and even code can be considered as art.

The gcc directory is created by the update-workspaces script. And you do need to run the script in the terminal, so we can get some error message out of it.

The skeleton movement is looking very good, but I seem to miss some wobbly parts. The ears should flap a lot, and as dogs run mostly with open mouth, the lips should also flap. Also, dog skin tends to be quite loose, and drops on every jump. So the bottom part has wrinkles and the top is stretched when touching ground, and the other way around when at the top of the jump. The loosest parts are around the shoulders. I don't know for how far these things are possible to implement though.

But remember that licenses are your responsibility (as mod maker). If you use mix any art from 0 A.D. with other art, that other art has to be released under CC-BY-SA too. So you probably need permission for that.

I don't think lack of precision will be noticeable at factor 8 already (I didn't notice it in Atlas at least). At factor 8 it's precise to around 1cm, which is still better than real-life measurements of many soil types (certainly natural ground). But indeed, if you exaggerate with the factor, you can get to a point where it does matter. @Erik, not sure what sort of screenshot you really want.

With sounds and sound effects, we normally mean stuff like mouse clicks, battle sounds, animal sounds, shouts, ... This requires being creative with the materials you find, or how you use your microphones. It appears you're more interested in making background music instead. That's very different from creating sounds.

Units going over each other will never be supported. The pathfinder is 2D, and the position component doesn't store the height, but calculates it based on the terrain. So if you place a bridge over the water, you must be sure that no boats can pass under it, or that no other entities (like fish) are at that place. For roads, the new pathfinder will be faster, because it uses a uniform speed grid. That uniform grid allows for certain optimisations severely reducing the number of calculations needed. When that grid would be non-uniform (f.e. because speed is higher on roads), then the new pathfinder will be worthless. The possible intermediate way would be that the pathfinder ignores, but that the speed does increase when units walk on roads. However, that would require a lot of micro to keep the units on the road.

Yesterday, there was another complaint about how our maps are limited in height (see http://wildfiregames.com/forum/index.php?showtopic=19727 ) So, as the maps from A18 aren't compatible with the maps from SVN now anyway, I though it might be a good time to change that limit. The easiest way to alter the maximal height is by altering the precision. The height is encoded in 16 bits for every map point, and you can use more bits for precision, or more bits for a bigger reach. That way, the height stays stored as 16 bits, and it won't alter the performance. In the current situation, the maximum height is 89.5 meters, and the precision is around 1.4 milimeter. So I don't think that I need to explain there's room for lesser precision and a bigger reach. The best way to handle this would be to multiply both with a power of 2. That way, the change boils down to shifting a few bits, and we won't run into strange rounding problems. The drawback of this change is that it will break all current maps, but I made a simple script that should convert your map from the old A18 format to the new format (whichever scale is chosen). So my question to the mapmakers is, what factor would you like? Here's a small summary of to what values different factors would lead. factor 1: precision = 1.4 mm, max height = 89.5 m (current situation)factor 2: precision = 2.7 mm, max height = 179 mfactor 4: precision = 5.5 mm, max height = 358 mfactor 8: precision = 10.9 mm, max height = 712 m Currently, there are a number of maps in our repo that almost hit the maximum height, so where it's not possible to make tops higher, or add hills on certain plateaus. One of these examples is Death Canyon (you can easily try to add a hill on the plateau). This is an example of how high you could go on Death Canyon with a factor 4: http://i.imgur.com/QdpsAWv.jpg For more technical information, or to test some stuff (testing would need manual compilation), you can take a look at the ticket: http://trac.wildfiregames.com/ticket/3112 I think factor 4 would be a good value (still precise enough, and have a reach that's probably good enough for all use cases), but I'd like your opinion on it too.

That only makes the compilation process faster, not the game. The game still isn't made to use multiple cores.

When Ben comes online, and fixes this stuff, you won't even need that small patch.

I don't have sans-bold-stroke 16, so I don't think that exists. But I think I found the issue, and it's not an ARM issue. It looks like you're able to render all stroked fonts, and these are exactly the fonts that are rendered in the RGBA colour space. The non-stroked fonts are rendered in greyscale (to save memory). You can see it in the fontbuilder: http://trac.wildfiregames.com/browser/ps/trunk/source/tools/fontbuilder2/fontbuilder.py (see the font list at the bottom) So there would at least be a rather simple workaround for the fonts: build all fonts in RGBA. This is as simple as adding "colour":True to line 189, and rebuilding the fonts. But that's not even needed. Ben / Historic_Bruno changed something to texture handling recently: http://trac.wildfiregames.com/changeset/16439 And what do we see now? Everyone with an existing installation will not have a problem (because the png textures are cached to dds), but everyone with a new installation will see broken greyscale fonts So I guess I'll ask Ben to fix it. It won't take long before we get new complaints. Thanks for the report.

It's strange that some work and some don't. Our fonts are actually textures (see http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/mod/fonts), and regions of these textures are just used to make a text. We use PNG textures in the SVN version, but these get converted to a dds for distribution (and also for rendering). So it would be interesting to know if you use the SVN data, or the distributed data. It would be interesting to know which fonts work, and which don't. Maybe the problem starts when the files reach a certain size. This is the XML file defining the start-page: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/pregame/mainmenu.xml Could you modify it a bit, and test with different fonts?

Pull = get something Push = send something Commit = give a version number to some change Not sure what fetch is, or when you need it For Branch, you have to know that every repo has at least one branch (usually the Master branch). You can copy a branch into a new branch. That way you can work on something, without interrupting the master branch. When your work is done, you can merge the two branches again.

It's all the border cases that matter. What happens when you only select a part of the formation? Do they disband, form 2 formations, or does the entire formation listen to the new command? Should you be allowed to make mixed formations?

Basically, when you create a map that looks good, is balanced, in some way unique, and you tell us that you want the map in game. Then it can be included.

How did you install the game?

Would you mind coming to the chat? It's easier to explain these things live. https://kiwiirc.com/client/irc.quakenet.org/0ad-dev

That would need some code, but it wouldn't be very hard either. Do you have people that can code in your team? We could give a bit of guidance. It also depends on the details of course, like what happens when the changing unit disappears, should it only change the look, or should all stats be replaced too, stuff like that. An other way is to give the building a bigger obstruction, so the player can't build it near to trees (or other buildings) anyway.

So @Katsuyori, if you'd like to keep working on it, it would be better to start of in the sound engine instead. I believe you know C++, so it wouldn't be that hard. In this case, I would suggest adding parameters to the sound settings (like http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/audio/interface/select/building/sel_barracks.xml), which can be read by the sound engine ( http://trac.wildfiregames.com/browser/ps/trunk/source/soundmanager ) I hope this helps.

Hmm, I think we set off on the wrong foot, mostly due to language, which is a pity, since the things pointed out seem to be correct (though I'm a true programmer and have no artist eye at all). kicking_bird, I think it would be best to convince us by creating a mod with some modified textures. Either replacing/modifying existing textures (if they fit in the same context), or making new textures that can be used on new maps. If you want more help on how to create a mod, please join the #0ad-dev chatroom on quakenet: https://kiwiirc.com/client/irc.quakenet.org/0ad-dev It's easy to merge mod stuff into the main game, so it's not because you're starting as a mod that it won't get included in the main game. Mods are just a good way to showcase new things.