Radagast.

Community Members
  • Content count

    1,391
  • Joined

  • Last visited

  • Days Won

    16

Radagast. last won the day on September 6 2014

Radagast. had the most liked content!

Community Reputation

287 Excellent

1 Follower

About Radagast.

  • Rank
    Primus Pilus

Profile Information

  • Gender
    Male

Recent Profile Visitors

840 profile views
  1. Sorry, I can not test which makes me pretty useless. :|
  2. 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)!)
  3. 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)
  4. 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." ;-).
  5. 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.)
  6. 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.)
  7. 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.
  8. @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).
  9. @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.
  10. 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.
  11. 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
  12. 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
  13. 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)
  14. 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.
  15. 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?