Radagast.

Do not give up! (You have made the hardest part already.) The error message tells that there is not a "single set of polygons" (1 mesh). Do you really have only one object selected? (blender is tricky here: Select all layers and unhide all objects via ALT+H. Hidden objects or those on other layers still may be selected.) Join multiple objects (CTRL+J) if necessary but revert this step before saving .blend (but after exporting .dae) using undo (e.g. CTRL+ALT+Z + click on previous state). Also maybe remove the material slots, too (not just the material). Use the minus sign right to the material as on the screeny I quoted. In general there is no need to triangulate manually like "the myth" proposed (the COLLADA exporter does it if the option is enabled as it is in your screenshot).

Couldn't one prop each oar to prop points. Animate twice (or run animation in reverse for one side of the boat). Let props (oars) inherit parent animation). About the license: It is legal because 0A.D. is non commercial as long as you provide the correct license with the file (i.e. the boat). If others use 0A.D. for commercial purposes we can check if they did remove the files that do not allow commercial use. (Good for 0 A.D., bad for sharks.)

Not complicated. Just a lot of work. What is complicated are the underlying hard working algorithms (performance) - nothing to worry about on the first hand in a 0 B.C.E.(mpire Earth or Universe mod). Also complicated is the overall design as in real life, "the concept" - e.g. what is needed, where to start [I am for stone age here until open end (future)], ... 0 B.C.E. employs the principles of time continuation and guided history (weak or strong needs to be determined, I personally favor weak, i.e. do not force historical events if out of context e.g. if Philip or his wife has been killed before giving birth to Alexander then no Makedonian Leader Alexander The Great). Isn't open cut mining what the stone piles in 0 A.D. actually symbolize? Coding snow is harder. And we need snow, rain, mud, ... (don't worry, I'm at it) IMO: No. Really. I was thinking the same back then when I was active. 0 A.D. is about pitched battle warfare - it's interesting, because high tech civilizations are pitched against each other. What counterdicts this design|concept is the evermore balance effort - which makes things boring (IMO! opinions differ!).

That's what is world developers' intent to fix by: * creating a real world base (living standard) for the active, contributing open source community (distributed food production, free(dom) emergency aid, ...) * showing that it's easy to switch between code project flavors (e.g. libav vs. ffmpeg, walker vs. roller, 0 A.D. vs. 0 B.C.E., mod public vs. mod public_mod vs. public_mod_mod, ...) fixing such quarrels that you quote (e.g. ffmpeg vs. libav package war of Debian maintainers). * creating a real world bot net to protect freedom of goodhearted, lovely, freedom peaceful fighters, ... (real world physical, psychological security) * hardening against crises (emergency trade one good type vs. another good type, maybe independent open source driven virtual currency for far distance trade of perishable goods that can not be sent easily). - - - - - - - - Hopefully D517 , then D295 and then your (@wowgetoffyourcellphone) changeset 19673 - related to ticket #3212 (structree equivalent for units) - gets in. Thanks for your work.

Sorry, I can not test which makes me pretty useless. :|

mhm. From this video nothing is evident. Even if not using group pathfinding it could still cache the found path of one unit and reuse it (at least for the long pathfinder that is how it looks like). (No information about grid resolution is given either.) Also the enemy units are fully static. (Apart from that it's a pure murder video without much value.) With many moving obstacles this'd get interesting. Unfortunately the only moving entities in the video are the attackers while the enemy is clustered at static positions (every officer of course would be very happy with such soldiers dying with so much discipline, moving not even one inch ;-)). Sad no dynamic obstacles are placed either. (in contrast to the video of @jeffnz, such debugging info would be helpful in the video of the giant storming of the static defender castle) Actually a good example of a pathfinder is already within pyrogenesis (despite maybe some bottlenecks at certain circumstances). Drunk on Nectar has a versatile pathfinding for flying units but even that one may require up to 3s (timeout) per unit per tic (of course a tic is way shorter, it's just a time out). Making that work with pyrogenesis' supported amount of moving entities is hardcore. (Yet the dynamic collision avoidance is fascinating and has many applications in the real world open source projects (where often there is just < two bot per computer whereas pyrogenesis' pathfinder deals with the thousands of entities within one part of one thread's time)!)

At first view, using garrisoning in addition to an aura may sound easier because as Skhorn suspected, it may be difficult to affect only units in the back as an aura can not be of irregular shape. While that also had the benefit of being able to handle the shield + its assigned|garrisoned soldiers as kind of "battaillon", the big issue would be to propagate the move animation. I have no idea about 0AD code in this regard. => Thus it may be easier to use just an aura as Skhorn said -- attached clearly towards the handles (i.e. move the center of the object away from the vertical shield towards the handles' ends, maybe somewhere inbetween). Then fine tune the Aura's range depending on the distance of the object's center to the shield. Then it should only target (player) units behind the shield. @mike82 What do you mean with you have to order every vertex one by one, actually this sounds like you are using a python script to order the vertex according to its index (BMesh?) - actually I think that's unlikely, so which order exactly do you mean? Or maybe pinning vertices and then Unwrap again may help you? (spacebar -> enter "pin" with mouse hovering UV/Image Editor)

The idea to make citizen soldiers very weak by default (knife) looks like it'd solve the puzzle, such that we do not have to remove this beloved functionality. Of course when deployed|called in in an organized manner then the armor + weapons are more powerful, it takes time though, as takes training, therefore even with the weapons they will have a hard time against the organized|well-trained army that it has to oppose. This alone would require to decide on a strategy, i.e. keep the units in economic affairs and only allow them to capture some very weak targets (due to their weak fighting capabilities) or to call them in and train them properly. Actually warfare is all about planning. And that planning is what we want when we have our civil "city plan" laid out. (as DarcReaver said, first some time for economy, being wary of some neutral forces like bandits and friendly trader tribes or at least only having to fear certain early-rush capable player-controlled enemy factions - which makes intelligence more important early on, too, as you need to figure out which faction your enemies field.) Edit: To not make citizen soldiers too useless, the rank-up system could improve the stats so significantly that it'd be quite cool to have such a champion citizen soldier at gathering as it'd be a stout defense (but surviving long enough to gather enough XP to become a champion is seldom anyway => very unique and good for surprises for enemy raids, e.g. "Oh hell now we again were stopped by this single Champion soldier, take it out." ;-).

I do not disagree on that fact. That's why - in the Gameplay Guideline topic - I proposed the button to hard lock a formation. Add another one for hard locking every formation and to only produce formations (batch train + code [1]) and there you have only formations and no mix anymore. Yves conducted research into that direction and that I know the code well enough to support his findings. I am a proponent of an soft formations code because: soft -> hard formation is way easier than hard -> soft [1] Restricting the entire gameplay to hard formations: * Only allow batch "production" > formation_member_count_minimum, * Add code to put them into a predefined formation directly after on TrainingFinished event. * Lock it (and prevent unlock globally to not have it dissolve). * Allow formation gathering | propagate build orders, ... * (Of course this will only become really useful when what Yves' FormationsWip proposes or improved formation handling and pathfinding is added.)

Many nice ideas. Definitely tying 1 market to a civic center and to limit the traders / CC or / market could do the trick. Trading system ideas merge|summary: === In the ideal case, DarcReaver's Option 2 patched with Justus', av92, Hannibal_Barca's tether idea could be merged with Option 1. As a consequency we get rid of the hard-coded, maybe random map problematic, new structures "trade centers" (following realism): 1) Slow down caravans (long way, slow speed but continuous). Increases time for interception. (XML edit) 2) Trade routes just depend on the geography of the map. (neither new code nor new art) 3) The trade routes are what is fought for, like the "checkpoint" system in the real world. Also nice for guerilla tactics. In the real world you just open another checkpoint and do not by all means try to capture one of the existing. Surprise is your friend. (neither new code nor new art) 4) The coins at markets for now should be replaced with tying 1 or 2 markets [1a] to the civic center and limiting to 5 traders / market as well as max distance of market to the CC [1b]. (XML edit) 5) (optional) Resources should not come out of nowhere ideally. Somehow wounded|dead units' items must be recycled. [2] [1a] If 2 markets shall be allowed per city, then a large min distance constraint is required but lower than 2 * market<->CC max distance. De facto this will lead to 1 market most often unless the city is really huge. When combined with reducing the territory gain of expansive buildings to just a few meters and allowing them to be built outside of this city border too, then a new strategical decision arises: EITHER construct the city e.g. stretched and linear and then have two city quarters exchange some goods. OR construct it more spherically and live with 1 market only, then likely closer to the CC. Note the linear <-> spherical decision is subtle as buildings can only expand the city borders (territory) very very little. [1b] Maybe we could get rid of the CC<->market max distance by making the market one of the very few buildings required to be built inside city borders? [2] When a soldier dies or a wagon breaks apart, the metal of its wheel circumverence (could be a speed increasing tech) will not simply disappear magically. This is not a fantasy game. (As a workaround for now maybe add these resources to Gaia resource spots that are not harvested by any player? May be unfair though.)

Let me relax the situation a bit DarcReaver wrote: > I can of course submit random tickets changing files. But to be honest: Whats the point if there is noone on the time who says "yes, we'll support the concept and it should be put in place." ? Just to warn you, this has happened before. Id est I wanted something like a "blank check", a bit of freedom like Ykkrosh (a very talented coder) de facto had, before for exactly the same reason: Gameplay features. Now that I am somewhat a hardware coder and have been active as C++, JavaScript, XML coder and 3D artist in the Council of Modder + one of 3 of the mod selection functionality coder and yet I failed to get this "blank check" or what it should have been called "guarantee of support for some experiments", be warned that you do not commit the same mistake as I did back then. In this sense, your work is appreciated. Do not get Hannibal_Barca or others wrong. It is easy to misunderstand what was said by developers (do not only eye on the "team" label, it's just a label, do not overestimate it, they|most of them are devs like wowgetoffyourcellphone, Agentx, ...). It's a community project with lots of freedom of operation. The team question gives rise to many quarrels and sad community members. It's just unnecessary hierarchies. We are not in battle. Go fork, mod, ... (see next paragraphs for a maybe help to get your planned changes started) Concerning the trac tickets. In my opinion you are in sync with current potential game developers by the following means: 1) Having surrected the game design document. 2) Reading and considering the existing 0A.D. design docs. 3) Having discussed the made statements openly. (Gameplay Guideline) Now the next step is to isolate your changes: "sie ins Klare zu schreiben", also einzelne template Änderungen in binaries/mods/public/simulation/templates/ Then you can easily provide these XML patches and I think there are quite some chances to get most of them into the game after some discussion and fine-tuning. Otherwise you can still copy the files to a mod e.g. gameplay_guideline/ folder within mods/ next to public/ (maintaining the directory structure of course) and distribute the mod until it is polished enough that it convinces players. To get you started, one such XML patch could be to: * Reduce the unit diversity in all CC := civic centers within templates/structures/ by searching for civil_centre to get something similar to public/simulation/templates/structures/athen_civil_centre.xml public/simulation/templates/structures/mace_civil_centre.xml public/simulation/templates/structures/ptol_civil_centre.xml public/simulation/templates/structures/brit_civil_centre.xml public/simulation/templates/structures/rome_civil_centre.xml public/simulation/templates/structures/iber_civil_centre.xml public/simulation/templates/structures/pers_civil_centre.xml public/simulation/templates/structures/maur_civil_centre.xml public/simulation/templates/structures/sele_civil_centre.xml public/simulation/templates/structures/hele_civil_centre.xml public/simulation/templates/structures/spart_civil_centre.xml public/simulation/templates/structures/cart_civil_centre.xml public/simulation/templates/structures/gaul_civil_centre.xml public/simulation/templates/structures/celt_civil_centre.xml Look for ProductionQueue and remove the entity template identifiers from the list of tokens. * Reduce unit speeds in e.g. template_unit_* by searching for UnitMotion within files e.g. on trac or on the github mirror if you prefer it (best of course in the file system, easily possible on UNIX|TNX systems (Linux,BSD,MacOS,...), no idea on windows). -- Edit: I do not understand people being unhappy with how formations are coded. It is epic! Exactly the correct approach. We just some tweaks to it, actually my view is pretty much in sync with Yves'. His FormationsWip trac entry gives evidence that his imagination of how it could work is more detailed than mine.

@Undying Nephalim: You are the most undying nephalim ever Chasen. I am looking forward to these crystaline lattices. I will do what I can to help you. I also am working on drone armies, so there is some overlap between your and my works. Not only in terms of required functionality, also artwise (it will take a long time (decades?) till our time machine 0B.C. reaches the extraterrestrial phase though).

@J.Avramenko: This is exactly why I support your and wraitii's idea to transfer the "territory" to a city core. 0A.D. is about city phases, not about territories. A city core fits it nicely and as I already said the civic center distance constraint already supports this idea. Thus it is not too difficult to convert the "territory" into a city core by reducing the territory gain of every expansive building drasticlly (just a few meters for more visually pleasing city borders as I said above)! Combine this with longer enduring units (wounded and only randomly killed) and the slow down + exhaustion and the gameplay gets a lot deeper, actually its Roadmap|design docs as mentioned by DarcReaver are already very good.

DarcReaver, your observations have been brought forth before. The military system is under attack often, also for renowned games like Total War there are still unrealistic issues (check the internet for critics). I like the direction the document promotes. It is just that it is a very complicated endeavour. I have literally spent weeks working on increased realism. 0 B.C.'s capability system allows entities to have Goals, Plans and follow a civilization's state of knowledge (no phases, it is continuous). Such untertakings are possible but they are tedious and easily fall behind: * SVN compatibility * getting things to work (UnitAI et alia, complicated) * getting style right and catch up and maintain compatibility with new functionality upstream * being tested well enough So indeed the community - we - must do more to convince a farther spectrum of developers that more realism should be one of the more dominant goals to get steer the general development towards fixing the issues piece meal. > One thing I disagree about is the dynamic line of sight taking too much performance. Warcraft III, released back in 2002, 15 years ago, already had this mechanic that buildings, cliffs and trees limited the sight range of units. This is more a matter of efficient coding than a real obstacle. Of course you need someone who can code this efficiently. But there we're back to the kickstarter option. Such sophisticated functionality is already employed conceptually, entities have a vision range as have ranged entities individual reach. Also auras have individual range. Dynamic Level of sight in terms of height, weather conditions et alia also are possible. Its powers may not be fully unleashed (at last performance is a limiting factor I'm afraid as we are bound to 1 thread for good reasons and many entities are desirable for realistic tactics to become possible). Actually 0A.D.|0B.C. is very powerful. Thus raising a kickstarter for art works looks way more important to me (considering that animations play a huge role in conveying a realistic smooth battle tactics atmosphere). Coders know logic, maths well enough to make a living in other oceans. Also open, free of charge coding is common among world citizen coders or rookies that are keen to get attribution. Open art stands in contrast with this. The ego of an artist is very fragile due to the very artistic nature. Thus very few are strong enough to engage in open source projects. > the role of women Women as population provider approaches real world facts, which makes sense. Women as morale boost also makes sense for the same reason which is why the morale boost makes sense. See guys working when a beautiful woman is close after they realize she's taking notice of them. And everyone thinks it's him. haha Even more, a nice balace of #men, #women is required for a population to work. There are civilizations where women are seen as costly (provide gift to marriage, ...). e.g. China has a lack of women (Germany also has had roughly half amount of women than men according to BayernPortal since many decades). A balance is not only important to avoid quarrels among men (which may have been more common in barbarian times than nowadays). Also too many women or men in a homogenous group might get distracted, chat too much, leading to injuries and reducing efficiency. A man operates a machine more carefully when a female is close than with a about female joking male companion. (own experience, I have seen more than one people lose their eyelight almost entirely only due to that) The real world is dangerous. Not only in battle. But also for battle morale, knowing or at least believing females waiting for one at home increases morale and endurance (in addition to what you said about endurance). wraiti wrote: > -forbidding farms inside territories (or possibly dividing their efficiency considerable) Vote for the latter. If we achieve it the realistic way, i.e. that the ways towards fields, food storage (which has often been outside in the wilderness) and animal handling are longer, then this divides their efficiency. Now that there is free space available inside the territory|city core and not everything full of buildings, this complicates things. A solution could be to introduce a "claim" system similar to how property can be purchased nowadays (the city could have claims to all territory, such that farms have long ways to go if their farm building is constructed inside it. Increasing the role of fertile lands - not only for crops, but also for animals, may also help. The grassland could decrease in fertility once it is within city territory or depending on unit traffic | proximity (maybe an aura on buildings nearby). >-Actually using the concept of provinces from the original design, where the map was divided in provinces and you could conquer those in a largely predetermined way to acquire their resources. This feels limiting, but now that I think of it it's actually probably a much better way to handle this. That being said, it kind of implies larger maps, as do a lot of other things. Artificial regions will lead to issues no matter whether in the concept of provinces or territory. Provinces could nevertheless be a natural realistic addition when military dominance zones or "control" - as the Institute for the study of war calls these regions - can be strengthened. This could be achieved as side effect of the slowing down of gameplay and thus increased emphasis on strategic movements, e.g. close this high pass over the Caradhras with a mobile unit (that gets exhausted up there quickly and recovers virtually not at all, thus must be rotated at times) and the main valley entrance with a military force dug in. Et voila, the region is secured, becoming province of the empire. Now our tax collectors can visit the inhabitants following reconnaissance. > To prevent players from simply sending out their first soldiers to expand everywhere, [...] Again, it may be wise to counter this like it is countered in the real world: supply. You cannot build a base with resources from the city center when you are far away unless you have a train of supply and of course adequate protection for your convoy. Early on this is very difficult to achieve. And as civic centers are not allowed to be built close to each other, there is (and should be no way to increase your city core to spam the whole territory). Building close to the territory border could still increase territory but very subtly, only some meters, e.g. for a house just enough to place another house, not more. These small outbursts into the wilderness away from the busy city core will make the overall appearance of the territory more visually pleasing. > BFME also used neutral creatures like trolls, spiders, Orcs or Wargs to protect settlement points. As you said, in the case of historical accuracy, the neutral creatures could be represented by native inhabitants who may not be happy when a civilization settles in their old, beloved traditional lands. The choice is to either convince them in some economic|diplomatic way or to keep them under control militarily (costly!). Otherwise they will lay fire to your construction site or kidnap your workers or will send animal herds to create chaos and stop construction or what not. Looks perfect for triggers or HybridAI. > To prevent maps to be overburdened with neutral units everywhere, I think the provinces should be connected to map size. I agree with the prevention of too many native units (not neutral or at least only neutral till your units enter their region - at latest when construction starts!). In terms of provinces in general natural geography should - again - be the guideline as this is exactly what the historical community is interested in. We may also want to pitch the ancient civs on artificial or generic random maps but generally we want to see if we can manage to defend this or that realistic territory with all its advantages and disadvantages. Once in the role of the Romans, once the Persians, once the Greeks, and so on. Having all "provinces"|regions balanced could become boring quickly. This is what your proposals also promote, i.e. more flexible paths of development and strategy. I.e. when we have the nasty spot which is overly exposed or has few resources, then we must make the best of it and adapt our strategy. This is how life works. Adaption. From your critics can be derived, that currently there is no adaption, instead there is a clicking rush and respamming of units that directly find death after some minutes of seeing the day of life instead of smart tactics and overall strategy. Grugnas wrote: > but that siege is too hard to defend because enemy units can easly pass through the first line and destroy the catapult True, the penetration of the front lines is one of the more frequently criticized military issues. Shieldwolf with DarcReaver wrote: > > I’d strongly suggest of battalions with multiple units in a single entity. > Yes, something similar to Rise of Nation’s infantry units. You’ve made a good observation in that it would feel you are striving to become an Emperor instead of a glorified village chief. In my opinion this is lost developer effort, because formations are battaillons - just more flexible, so be happy. And rather let's work on how these battaillons could be controlled more efficiently|exclusively et alia. (Maybe a hotkey for selection formations only - and also an option to lock formation members, i.e. to not dissolve and do not resupply?) It is known that I agree with shieldwolf that children have to be added. Maybe together with women as population providers. Both leper and wraitii are right, it is possible but it also is pretty difficult to get a directional combat system work and function beautifully. Shieldwolf said: > I disagree on it being timed, and being permanent. That button will make it the player’s choice to have his citizens be an economic unit or a military one. And - to add DarcReaver's suggestion - have it either lose all resources that it bore or have it bring them somewhere or hide them - depending on personality|global directives (e.g. player decret "Save on resources! We have little."). In 0 B.C.E. due to capability system (complex beast and not working yet!) it is possible, in 0 A.D. not so much as resources are just numbers and can not be transfered to another entity (unless as loot which might somehow be possible to transfer it as loot to e.g. a badger burrow entity). > depending on where the unit is (units travelling in roads are faster), or the seasons (units in winter have slower speeds), the unit’s speed changes. Epic! Attack value randomization could turn out very difficult to balance. (Ranged accuracy already is influenced by spread. Maybe melee will get more interesting with the penetration <-> armor system + then inflict the damage, as also has been brought up often before but not found its way yet.) DarcReaver wrote: > From Feudal Ages to Knights and castles to Gunpowder and Renaissance. In 0 ad there is no such Age Advance. And exactly this is why the units currently die way too early. It no more realistic to spawn random new units out of nowhere than to have some grow up quickly. > "free villagers", afterall this would remove player control on using pop cap. From company of heroes call in system I know that this mechanic isn't >always the best, even if its free hmm.. in my opinion children should be actors only, maybe props to a women, reducing its efficiency but after a certain amount of time (long! because of city phases, not ages), this then should increase the popcap and the female be at normal efficiency again. This way females have a purpose. It's very nice to have them in the simulation (it's so much more realistic). What about a compromise? Make units endure longer (harder to kill, wounded instead -- only randomly transfer them to nirvana, the others immobile on the ground - another strategic resource) and yet include children (because a city is not build within one generation generally and even if, then its flourish point is some generations later - without condition of general validity). DarcReaver about shieldwolf's civilian<->soldier button proposal: > Not sure, then it's pretty much the same as it is now. Either right click a field, or right click an enemy. True. Which is why I think the real issue is timing. The time from citizen to soldier is way to short. If transformation time (in both directions) was longer, then scouting was more important. In that sense. Great ideas and as so often we'll be stopped by the complexity and the fact that it is a lot lot work to get any of these proposals developed in a way that pleases most of our people involved. > Yes, but from my experience artificailly slowing down units is not a fun concept for players, it's more annoying. CoH 2 had a "blizzard" weather system which caused winter storms that made units immobile and have no vision while it lasted. The feature was removed due dto massive complaints from the community. Nobody liked it. If that is artificial, then even the speed of the units as they are now are artificial. Actually everything is artificial as we are coding a simulation which is an approximation at best. When Napoleon (disputed) or the Nazis (fact) got stuck in the snow before reaching Moscow, leaders also were in rage as were the soldiers, e.g. when Nazi officers burnt newly arrived coats to avoid quarrels among the soldiers. It is this kind of events like blizzards or vulcano eruption which is fun for a history interested community as long as it is used very sparsely and not necessarily leads to immediate annihilation|immobility. (Note this is my personal opinion.) > base accuracy increases to 100% upto minimum distance (say 4 or 6). after which it decrease again to 50% due to getting meled. An approximation of this already exists if I remember the code correctly. (Especially if units are wounded and not die so often, this could be a useful addition to have the archer at least take one last enemy unit out wounded before being wounded by melee himself.) The combined elite-military, economic|architectural purpose of the Stoa according to Thorfinn the Shallow Minded, J.Avramenko sounds sensible.

Impressive artworks. Now that you earn 900+ $ a month is there a chance you find time to finish this mod? https://www.patreon.com/undyingnephalim

I'm sorry for that. @Niek: Actually I like you, leper & co pretty much. Maybe it was due to that that I was so hurt back then in the Council with the internal conflict. So let's put some nice fertile soil above it. Please never take my criticism personally. I am only fighting people's logic. I never fight people, I am only there to protect the good ones. And if you were in serious trouble (e.g. real world live endangering situation), be it Niek, leper or any other here, that tries to contribute something to the world, then I'll be there to help you out to my best and my death - even if I'm that a nasty guy when something contradicts logic or is inconsequent. I guess this is a point I will never learn to accept, that people become inconsequent to protect their minds., I hope you are doing better than me, as Emma Watson once nicely put it. So I did not share code, true. Pretty inconsequent, but logical in the bigger picture: So when we manage to get our code projects at worlddevelopment cleaned up, then we'll open our sources as the throng votes and logic says yes to opening sources as soon as the project is out of the woods. Then we'll also publish releases. Worlddevelopment's hardware projects also serve to protect what wildfiregames tried to contribute to - to a world of freedom, rights and justice. Actually the Age of Kings mod is a very great contribution. Thanks for that. And the screenshots people provide in this thread with these great optics enabled with their cool hardware also looks epic. Bare bones lost guys as me will not reach such screens ever. Have a nice day. Prosper, be happy and be evermore objective. Yours old lost comrade, in peace

To find your hardware you can also use lspci | grep VGA lspci -v | less lshw -C video -- MORE POSSIBILITIES Make sure there are no other wrong graphics drivers installed (this is a common problem on many if not all operating systems): sudo apt-get purge <vendor>* ... Reinstall Xorg to rule out the possibility that something went wrong after updates or hardware change (exchanged graphics card or similar): sudo rm /etc/X11/xorg.conf sudo apt-get install --reinstall xserver-xorg-core libgl1-mesa-glx:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:amd64 libgl1-mesa-dri:amd64 sudo dpkg-reconfigure xserver-xorg Restart the system (e.g. sudo reboot now)

What does dmesg tell you about your xorg graphics driver loading? Use the following command before starting X: watch -n 1 'dmesg | tail -n $((LINES-10)) or because you are on fedora: dmesg -wH Else use dmesg | less and search for your graphics. You can also check other logs available to you if you prefer but you need to hunt down the driver issue. It might be a hint in the logs that shows you what causes the issue, maybe a dependency is missing. Could be llvm or anything that mesa depends on but is not available.

Can you provide some information like the output of glxinfo As ben said, might be a driver issue. Do you have GL Desktop activated? Or anything else that might deactivate hardware acceleration? Does glxgears run? Since when do these issues arise? What did you do since it last worked?

There is some crucial information missing artists should be aware of before we will be able to unleash the full powers of the new code: It is not guaranteed that the equal-ID animations are chosen because a later variant can override those name's mapping, replacing all the animations found in an occurrence of a variant with the same name in an earlier examined group. (one variant per group is chosen) We will be responsible to ensure that there are no animations from other variants that overwrite those that we linked using the name,id combination. THIS IS DESIRABLE BEHAVIOR because it allows for removing the via ID linked animations by providing an animation with the same name but without an ID. This may be vital to understand. Of course the name,ID link animation can be overridden per actor by defining an animation within an equally named variant that also defines the same name and id combination. Note the variant name must not necessarily be equal for linking animations as long as the animation names and ids match and the animations are loaded. VARIANT NAME CASE NOT IMPORTANT Furthermore note that the Variant names case does not matter while the animation names' does. Use lowercase to avoid random errors. For consistency we may want to use lower case for animation names too? (attached a patch to #2324) Or is there a special reason for keeping its case other than confusion? I could not find a place where these names are transformed to lower case internally in comparisons with e.g. State which means that the simulation code has to use lower case and the animation names too but this may be fragile. Correct me if I got something wrong. I did not test it ingame if it works, I only read the code and thought this should be clarified so that artists do not have to read the code themselves. MANDELBROT ACTOR DEFINITION of course is bogus. My workaround is to stop at a certain number recursions as defined via extra attribute. This is neither correct behavior nor useful other than for chaining actors like oriental carpets randomly by defining a recursion number. And even then it is only linear stacking, so it may only suit for constructing a modular tower to the clouds if settlers wanted to do this.

Good work. Still got no farther than to the infinite loop and fixing my vim which also segmentation faulted suddenly. The latter is fixed now. This Model, Object, prop relation and animation picking is complex, the animation name is rewritten at all corners, e.g. with the m_State. I still know this from the Animation rework. So I wondered how it could be so easy by reusing m_AnimationName as sander coded it. That's the first time I saw sanderd17 err on something. Though I liked his easy solution, simplicity rules and the major benefit still is that we do not need a new actor format version in 0 A.D. as in wraitii"s first version. MANDELBROT ACTOR DEFINITION I start to wonder if instead of fixing the infinite loop it was not easier to redesign to allow entity on entity which not suffers from this. This is getting mind twisting to fix. Not sure if it is worth the edge case of same actor as a prop of the same actor definition again. Mandelbrot actor so to say. Might be useful for procedural actors like chaining / interconnecting orient carpets. Edit: It might be wise to restore the idx kind of anim handling as before the 2 commits by sander and code the ID attempt freshly to be sure of no further regressions though I saw you evaded the m_AnimationName conflict.

Thank you then. Got 0 A.D. working on voidlinux and it looks like there is something wrong. Depending on the actor XML it can even lead to a segmentation fault.While the Animation system differs from 0 B.C. I saw there is an infinite loop. Somewhat unrelated to the sync issue though. SYNC / EQUAL ANIMATION ISSUE And when the animations not even are picked accordingly as you two said then it is also excluded that the Desync speed variation to not have units look too uniform is responsible. Maybe I can get to something when I relearn the 0 A.D. code. If so then I will provide the patch(es). It was bad enough that I did not provide the water patch back then because it was such a small issue that it was embarrassing and I was sure people would take me apart when I provided such a small fix. This way Ykkrosh could get the gems that he deserved much more because this is a coding giant. Apropos, he is still working on 0 A.D.? Helping you busy history colleagues out is the least I can do. If someone else is quicker so, don't hesitate to fix it. It will okay to me, I do not need credit, for me it's enough if those busy people is being helped.

Finally under version control, how could I come to think this is impossible: foolish me. https://htmlpreview.github.io/?http://github.com/worlddevelopment/virtual_time_machine/blob/master/status_functionality_ideas.html

Stan, now I think I understand. Now with trigger scripts. you can do it, just add points to influence your settlers when the map creator wants a special behavior of the settlers or you wish increased danger for e.g. avalanches. (predefined events) (In later The Settlers versions the units were mere actors without collision and not assailable other than by wild animals, isn't it? Do you think these were just following these predefined waypoints to relieve the pathfinder computations? And that the wild animal attacks also were some kind of trick because I can not remember if those civilians just have run away from the wild animals or if they took damage.) DYNAMIC EVENTS In contrast to predefined events things like traps are not on the fly manually added by e.g. hunter units. (dynamic events and better not solve this using auras because only if an entity knows of the trap then it will avoid it, so there is some flow of information) For sitting on a bench it may be easier to just check the unit's will to sit on a bank it comes by randomly. If the will is low then a friend could still be the convincing factor. The checks should be simple and few for performance. THE ROLE OF ROADS, BRIDGES The "way points" for traveling between garrisoning in and out could be roads, bridges. This has the advantage that they are destructible what trigger points are not. And if you want an additional RPG like feeling then place a trigger point and predefine the event in the trigger script and wait until your target unit (heroine controlled by player) comes by your trigger point, or? In the script it then should be checked though if the bridge is still existent taking replacements/ upgrades into account, this could be tricky so maybe just check if the region is traversable or if there is a kind of building there. For the school example you gave, this could be made happen similarly with the difference that the parents will need to send the children to school first. This depended on the culture and time of history if I'm not mistaken.

Colleagues, you always again surprise with extraordinary mazes. How epic is this palace? Is it really put directly into the rock. Subtraction construction instead of addition/stack construction. -- Thought about migrating this community functionality wishlist to version control but the colors are an obstacle here. I'd miss them. xD As worlddevelopment has a throng tonight to decide whether a permanent forum may make sense or whether existing channels (blenderartists, wildfiregames, opensourceecology, buildtheenterprise, allbaoutcircuits, ...) will be reused, which supports single source principle and would make world populations' life easier not having to check another forum, password and so forth. Another argument that will be fielded especially in terms of 0A.D. where tension is far bigger than worlddevelopment's good relations to opensourceecology et alia is that `sister project` makes more sense than `opponent`. My subjective view has come to understand that both sides will just tolerate each others quirks and find a common denominator which is historical accuracy among others. It's no good open source community fighting each other. So I guess the decision will be pro "not reinventing the wheel" and personally I must say I missed the historical discussions and plan forging here a lot. So I may be found here from time to time for historical reading and maybe at times trying to help here and there. Do not expect too much because I'm deeply struggling with getting started functionality in the virtual time machine 0 B.C. to work which is no less mind twisting endeavor than 0 A.D. while having diverged significantly (and time resources for the open source virtual time machine are far less than the open source engineering). Note no interest here in team or whatever. I consider team and the hierarchies of 0AD a quirk as you find your quirks in me. Either all develop the effort jointly and level or it is not real open source neither. Just like the binary blobs all over in open source hardware. My quirk is that sources are published on release which also is not uncommon a open source quirk. A release date depends upon progress. Then you will have your stack entities #28, transition animations, weather, seasons. 0AD is old, and it will survive the next decades too if we extrapolate its existence. See it positively: waiting for virtual features is better than waiting for e.g. your girlfriend returning from the graveyard. So I can not really understand all the aggression against a pretty typical open source principle: provide sources to a release. The last years have been quite chaotic: after having lived in the car in university due to no more funds for the flat for 2 years, being homeless shortly after my studies again when I lost my job as patron, actually in the time of my major quarrels with 0AD, having lost people I loved so extremely that it turns me apart, several bankruptcies had to be overcome, being under pressure by state regulations, having found asylum in a farm upstream from where I can still conduct my patronages (community strain is put on people like crazy), but which was already partly force-taken by the state authorities and bankrupt again, almost all material things breaking too (I know it can always become worse and I won't complain, but believe me, I am no gentle person anymore and thus my patience may vary. Especially I don't understand fun that well as you might understand a bit better now.). I had virtually no time for 0 B.C. which was another reason to drive me crazy with things spinning out of control and not even have a distraction. But hey, it's under control now. And now we even have a huge base for worlddevelopment and epic fantasy affairs. Finances have balanced and we can even hire some fellows and I asked Stan for help several times but I understand his full commitment to wildfiregames. And now we have to increase efforts to get the world safe and peaceful again because we want an epic world. Then we will find our own peace too. --- The functionality wishlist is not up to date.