Leaderboard

Units standing on walls dont get targeted automatically, it seems like one has to target them manually. Units standing on Iberian gate-towers seem to be non-targetable at all.

Hi all i'm a c++ programmer, coming from Ogre3d and then unreal i discovered this project by searching a RTS open source, hopely to help here to program and building in blender buildings hi Neva

-Casos/y/gorros lusitanos em desarrollo; Gorros; (Para;) (infantería ligera) 1. Lancero; ---------------------------------------- (Scortamareva) 2.Hondero; ---------------------------------------- (Trokalobutiam) 3. Espadachín; ------------------------------------ (Caetranan) 4. Escaramuzador; --------------------------------- (iovanan) y (Caballería ligera) 1.Jinete con lanza;--------------------------------------(Epones Pretre ) 2.Jinete con venablos;----------------------------------(Epones Aeiste ) Modelos fase 1; (No llevarían nada en la cabeza, irían con sus peinados tribales al aire) (Gorros)Modelos fase 2; (Gorros)Modelos fase 3; -Intento que se parezcan a los originales aunque por ahora parecen gorros frigios (como los que usan los persas), haber si consigo consigo la forma de una vez.Las partes en blanco cambiarían de color según la facción. Los lusitanos fabricaban cascos , cotas de mallas , grebas y escudos con umbos y piezas metálicas pero , no las usaban todos los guerreros , porque preferían ir ligeros o solo los que podían pagar los(aristocracia) . Referencias; Cascos ; (Para;) Unidades campeonas; 1. Aristócrata; ------------------------------------- (Arimo) 2. Emboscador; ----------------------------------- (iabarannta) 3.Bandolero;---------------------------------------(Epones Arimos) Cascos ; (Para;) Héroes; 1.Viriato;--------------------------------------------(Virilos) 2.Cauceno;-----------------------------------------(Kaikainos) 3.Púnico;--------------------------------------------(Apimano) - Los cascos siguen en desarrollo...¿Sugerencias , críticas...? Disculpen las molestias*

Also, I think the gate could be wider to allow the passage of elephants and covered rams.

https://forums.taleworlds.com/index.php?threads/research-iberians.247627/page-3 (Yo soy John-of1999) Vuelvo a copiar el mismo enlace aquí porque, después de leer fuentes con mayor seriedad académica ("Armas de la antigua Iberia" de Quesada y el suplemento "Guerreros de la antigua Iberia" de Despertaferro), he cambiado la mayor parte de imágenes que publiqué y también he añadido información. (*Todo en inglés porque es el idioma en el que hablan los modders.) (*También aclarar que no copio y pego aquí la información directamente porque me llevaría mucho tiempo.)

Hi @Nevarim! Welcome to the forums. For programming tasks you need not apply, you can just get the source code and start working on engine patches. Please join us on IRC on the #0ad-dev channel, and to ask any question you might have. Best regards, Stan.

I see this in discord.

Hmm, yeah. Did not try with javelins. Their attack range is too short to overcome height difference for units on the gate. And yes, I tested with archers they attacked automaticaly units on the walls.

Bom dia ou tarde; -As muralhas são inspiradas nas que foram construídas nas citanias no final do século III.(mais ou menos antes dos conflitos com os romanos) Desculpe-me pela incoveniências*

There is an important caveat: splitted repos should be in sync via some relation mechanism. Someone doubts?

Splitting anywhere else than project boundaries is a bad idea IMHO. For the sake of argument let's assume binary assets are an issue or are anticipated to become an issue then lfs is a superior solution to some hand crafted custom setup. For me engine and game are two different projects. Two projects can live in the same repo in theory but it takes a lot of discipline. In practice this rarely ever works. Let's have a look at 0ad premake.lua with the lofty goal of building multiple static libs so they can be used on their own outside of pyrogenesis. In practice there is tight coupling, even plenty of cyclic dependencies, further stuff in third_party was made dependent on pyrogenesis as well. Then look at the directory public, supposedly the game, which contains plenty stuff which belongs to the engine making the engine unusable without the game. The engine having a proper API one day is pretty much out of reach in such a setup. pyrogenesis has 0 cve listed, so the most secure piece of software ever ...

This would not, in any way, prevent a SolarWinds scenario - the releases were properly signed in that attack. You'd have to have a second, separate, build chain rebuilding releases to compare output hashes to catch it. What I personally tend to prefer is uploading private (as in, not widely published, not that they're hidden) package repositories. Gitlab, at least, has several built-in package repositories (NuGet, maven, PyPi) that can be used for uploading/hosting these kinds of things, and I believe several other CI systems do as well. And in some cases that's not necessary - recent versions of cmake, I believe, can grab git repositories as project includes (assuming the referenced project also uses cmake). I personally feel no build output should ever be persisted to a repository, and no third-party binaries if you can avoid it. Back when I made my few contributions and also saw the earlier git/svn debates, my feeling was that an artists'/testers' script was the way to go, too. I think my only recommendation here is to make it so that you could pass version numbers to be able to work against a particular build (just stating what I assume was implied). For that matter, it's possible to install hooks into various parts of git (I don't know about svn, but possibly there too) - UnrealEngine, for example, has a script that you're supposed to execute on first clone; thereafter, any time you switch branch or pull updates, it downloads the relevant third-party dependencies and common content. I personally prefer working with git, being a programmer, because it makes diffs and branching so much easier for text assets. In most common cases, assuming submissions are based on branches/pull requests (instead of submitted diffs), there's usually not much visible difference between git and svn, though - it's only once you have multiple people modifying the same file that git and prs really help. Other than switching typing `svn` for `git`, I don't think artists would really be affected.

I still can't do good animations for gates, and unfortunately I'll have to discard for now the gate created by Duileoga. Fixed parts of the walls (https://github.com/0ADMods/Lusitanians_civ), I think a roof on top of the towers would be a good thing @Duileonga.

What are the current limitations and what are possible solutions for that? The current limitation is that Phabricator is no longer actively maintained by its parent corporation. This is it. This is the only major cause for action that I can see. So, we need to be careful to avoid creating new problems in our suggested approach to solving this major problem What is required from the version control system and CI? Security Reliability Longevity Companies involved are allies of FLOSS instead of enemies Ease of use, particularly for newer contributors Development data is not fragmented Which features are required? A solution for storing binary files What is only nice to have? GPG signing of commits or at least tags and pull requests 2-factor authentication End-to-end encrypted backup of data Easy export of data What are the pros and cons for them? I will address two of the traits that are, in my opinion, key requirements: Security and Ease of Use. Security Solarwinds was hit by malware that targeted the build environment. It was described in some articles as "IT's Pearl Harbor". I encourage people to personally examine the security of the build environment, if only briefly. If you can think of vulnerabilities then so can the bad guys. One step to achieving security of the software supply chain is to cryptographically sign patches or tags and pull requests, as well as releases. Also, a fundamental method of achieving security is to minimize the attack surface. Don't use unnnecessary software, and don't use overly complex software. Some of these CI/CD systems have more than 1 million lines of code. Do you think they've been reviewed? Do you think they've been designed with security in mind? I like the advice, "Trust, but verify." If you weren't involved in the development process of the CI/CD tool, and you haven't read the source code, then you're trusting something but not verifying it. Ease of Use We need to address the wants and needs of stakeholders who are not participating in this conversation, but who are nevertheless valued contributors to the project. We have more than 20 developers and artists, and probably a handful of them have strong IT skills. Visualize a scenario where you have little knowledge about source control system inner workings and little free time to learn about them. You just want to make content or contribute a feature or bug fix. If the VCS is complex with a confusing user interface and inconsistent or invalid metaphors, are you going to spend a lot of time reading documentation and watching tutorial videos in order to contribute your improvements to WFG? Or, are you going to throw up your hands and not contribute the improvements at all? That decision depends on the individual, but the decision about which VCS we use can have an impact on how many contributors we have in the long term.

Awesome stuff!

Hi, thanks for the report! Can you provide us with a replay of that match, please? And was there anything written in the interestinglog.html? (See https://trac.wildfiregames.com/wiki/GameDataPaths.)

.