sanderd17

Walls were never really smashed down. Rams were operated on gates normally, or walls were mounted with ladders or by constructing an earth ramp. Meanwile, catapults were used during a siege, together with flaming arrows, to cause damage in the city and force soldiers to take care of other stuff instead of defending the walls. But, as realistic siege would make the gameplay too slow, that can't be implemented. So our catapults can take down walls to emulate them being siege weapons, and the same would hold for ships: if they could be used to siege cities (keep cities under ballista fire), then the translation of that to 0 A.D. gameplay should be that the ships can take down walls.

Do you have a source for that claim? I can see multiple mentions of supergalleys being able to carry catapults. F.e. on the wikipedia article about the Tessakonteres. I don't have the original source for it, but at least it has a citation, so I guess there's some truth in it.

If you don't know, a forum post is probably better. If you can reliably reproduce your crash, and you can see it isn't reported yet, you can make a ticket directly. Don't forget to give is as many info as possible: steps to reproduce, system info, crash logs, ...

Second thought, that won't work with foundations or mirages yet either. But it would just need #2951 to fix it.

Got something here that you may want to give a try. Instead of switching complete actors, it selects different variants of actors. This way you can f.e. just change some prop for another (and props can be very big, you could f.e. define almost nothing on the base actor, and define completely different meshes on the props to get a full replacement). Here's some code you can put in your mod (it will eventually arrive in the main game too, but it's still experimental, so the exact schema can still change a bit): simulation/components/interfaces/TechnologyVariants.js: Engine.RegisterInterface("TechnologyVariants"); simulation/components/TechnologyVariants.js: function TechnologyVariants() {} TechnologyVariants.prototype.Schema = "<a:example>" + "<Phase datatype='tokens'>" + "phase_village:villageVariant" + "phase_town:townVariant" + "phase_city:cityVariant" + "</Phase>" + "</a:example>" + "<oneOrMore>" + "<element a:help='Set of variants chosen per tech'>" + "<anyName/>" + "<attribute name='datatype'>" + "<value>tokens</value>" + "</attribute>" + "<text/>" + "</element>" + "</oneOrMore>"; TechnologyVariants.prototype.Init = function() {}; TechnologyVariants.prototype.Serialize = null; /** * Clean the technology variants * @param checkTech Used when there's only one tech to check */ TechnologyVariants.prototype.Clean = function(checkTech = null) { let cmpVisual = Engine.QueryInterface(this.entity, IID_Visual); let cmpTechnologyManager = QueryOwnerInterface(this.entity, IID_TechnologyManager); if (!cmpVisual || !cmpTechnologyManager) return; for (let setName in this.template) { let chosenActor = ""; let techFound = false; for (let token of this.template[setName]._string.split(/\s+/g)) { let [techName, actorName] = token.split(":"); if (techName == checkTech) techFound = true; if (cmpTechnologyManager.IsTechnologyResearched(techName)) chosenActor = actorName; } // update the variant if the researched tech was used, // or if there was a total clean requested if (techFound || !checkTech) cmpVisual.SetVariant("technology_" + setName, chosenActor); } }; TechnologyVariants.prototype.OnGlobalResearchFinished = function(msg) { if (IsOwnedByPlayer(msg.player, this.entity)) this.Clean(msg.tech); }; TechnologyVariants.prototype.OnOwnershipChanged = function(msg) { if (msg.to != -1) this.Clean(); }; Engine.RegisterComponentType(IID_TechnologyVariants, "TechnologyVariants", TechnologyVariants); Then the XML part in the entity template can look like this. <TechnologyVariants> <Phase datatype="tokens"> phase_village:villageVariant phase_town:townVariant phase_city:cityVariant </Phase> <Armour datatype="tokens"> tech_armour:extraShieldsVariant </Armour> </TechnologyVariants> The template above has two groups (here "Phase" and "Armour"), you can put in as many groups of selections you want, and the name doesn't matter. Then for every group, the code will look at the list of possible selections, and will chose the last one that has the tech researched. F.e. when you're in town phase, both "phase_village" and "phase_town" are researched, but the code will pick the variant that goes with "phase_town" (in this case, the variant names "townVariant"). If no techs of the set are researched, it should just show the default actor (depending on the frequencies), so as long as "tech_armour" isn't researched, it will show the default, but from the moment that tech is researched, it will show the "extraShieldsVariant". It works quite similar to damage variants (which is why this change was so easy to implement now). F.e. in the iberian fire ship actor, there's a group of variants depending on health (with variants like lightdamage, mediumdamage, ...). And when you use this piece of code, you will need to make groups of variants that match the groups in the template. So the code can pick one variant from the group and not unselect other choices..

Oh, yeah. Actor upgrades were probably a code design mistake from my side. It's not versatile enough and causes some problems. I'd like to design something new that should work better and be more versatile.

AFAIK, the code prevents actor switching. Can you give a link to the actor you use, and tell between which variants it switches?

Most of the game is in the public mod indeed. Gui definitions, most of the simulation calculations, all maps and models, ... So you need a minimal mod to have the game. But the most bare-bones mod is the mod-mod (aka the mod manager). That just contains some GUI styles, a single GUI page, and some minimal needed code. The mod-mod can run without the public mod loaded (but not the other way around, since some of the GUI definitions and scripts are also used for the public mod, and aren't duplicated)

@jonbaer, as the engine is still in quite heave development, it's not easy to target it as an external game maker. And thanks to our open development, I think people who would fork it and start their own game, now first help us out a bit. We also don't document our changes very well yet as it's not feasible to do so. When we hit beta, we should be more stable, and be able to document the changes better so external game developers could build in a more stable base.

Disabling GLSL will also disable the fog. Since A20, GLSL has been enabled by default, that's the only difference.

In what way is Linux holding you back?

Hmm, apparently not, the big icon currently is 94x94, and the small icons are 30x30. But as it doesn't give issues, it certainly shouldn't give issues with a 256x256 image.

There are already 256x256 portraits, and IMO, they look fine: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/textures/ui/session/portraits/units/256 The advantage of halving the width and height in the GUI is that it exactly merges 4 pixels to 1.

I'm wondering if we shouldn't bring all new portraits to 256x256 instead of 128x128. If we plan to display them in a sort of encyclopedia, it could probably take up a bit more screen space than currently.

Making a file browser in-game (with support for all OSes) is a lot harder than letting an application open a certain filetype (like a *.pyromod file). At least if you don't use a standard library (like Qt), which we don't.

IMO, the first thing we should do is making the installation procedure easier: Dowload a mod file, select to open it with 0 A.D. and see your mod installed. The other things (listing mods, voting on them, ...) are things that can also be done by other platforms, like modDB, so it's not urgent to implement our own IMO (though it would always be nice to have our own).

I think this would be less convenient for users, and they may resort to a different chat feature (some already use voice chat to communicate).

The problem with implementing that now, is that we also want some other changes to the obstruction stuff. Like allowing circular obstructions, or requiring a passable gap on certain buildings (so houses can no longer be used as walls f.e.).

I wonder why that inner building is made out of white stone. I agree that settlers would probably copy their own architectural style, but I doubt they'll ship over white stone from Greece to build it. What does it give when the columns are textured with ptolemaic colors?

The list for auras is the same as for techs, with the difference that auras can't replace something (so are useless for some string values like buildable territory).

@stanislas69, it's up to the artists to decide on using the type of damage visualisation per type of building. Important buildings perhaps could use event different meshes instead of fire and smoke prop points.

You know you can make a mod that people can enable or disable (and in the future install) from the mod manager? See http://trac.wildfiregames.com/wiki/Modding_Guide

Stuff changed, and I fixed the new actor meanwhile: http://trac.wildfiregames.com/changeset/18332 But perhaps you also need to update to have garrison flags on the other Seleucid buildings: http://trac.wildfiregames.com/changeset/18321 Basically, I needed to make the garrison flag independent from the animation to support the flag on siege towers, but as the buildings had the "garrison" variant next to the "Idle" variant, when making it independent, the selection contained both the "Idle" and "garrison" selection strings (as "Idle" is the name of the default animation), so it resorted to randomness according to the frequency, and always resulted in the "Idle" state. Edit: but you're right that many blacksmith buildings didn't have a garrison variant, and I didn't add one when altering the variants, as I don't know if the buildings have a garrison prop point (and I didn't feel like testing them all).

You can alter the attack time for the battering ram (if you also alter the damage it deals, so it overall deals the same damage per time). But I indeed think that the fade-in and fade-out won't work on our game. Attacks just happen repeatedly and shouldn't fade in-between.

Good start. Though the wings should stay open when flapping down (try to take as much air as possible), and close only when flapping up again. But don't overdo the closing of the wings, big birds typically keep their wings quite open during flight. I also see that you didn't triangulate it yet, our engine can only handle triangular faces. And for such a low-poly, organical model, it will probably change the shape somewhat, or allow you to produce a better shape with the same number of tris. And how big is the texture you have now? It looks a lot more detailed than the hawk, but then again, the eagle is a bigger bird than the hawk, so it could benefit from a bigger texture. And either the texture or the model is missing some paws, though that's perhaps not very important as the birds are mostly looked at from the top.