Community Members
  • Content count

  • Joined

  • Last visited

  • Days Won


Radagast. last won the day on September 6 2014

Radagast. had the most liked content!

Community Reputation

296 Excellent

1 Follower

About Radagast.

  • Rank
    Primus Pilus

Profile Information

  • Gender

Recent Profile Visitors

916 profile views
  1. @stanislas69 Please excuse the wording which sounds little friendly! I am aware of the fact you know GuiInterface as shown in the Diff you took over. My proposal serves to show that no hide,show is required and targets specially the target click thingy as "project leader" now prefers - which is different to waypoint of your https://code.wildfiregames.com/D557.
  2. Great, Lion, comrade. If it really helps, maybe provide the .blend and I'll debug edge cases. I might be good for finding weird new model|actor|template errors - even if I'm pretty useless as always. Edit: But please first try the proposal in my previous post. For the learning effect. If that fails, too, then I'll debug it.
  3. OK. IMO duplicate waypoint (rally point) XML. Allows to create variants as needed e.g. when interacting with the mouse with walls or if supplement info like context (e.g. rotating exclamation|question mark 3D model should be shown [as prop to be explicit as we both like :)]). This then'd only be a matter of selecting the correct variant using a GuiInterface call. It may be wise to allow more such graphical-only (unselectable, non-interactive) quasi entities per player at the same time for the case that the animation has not finished playing all frames when the knightly player already clicked other units to its target positions|interaction points. Else one could simply add one such entity per faction,player with position set to -1 by default and on demand moving it to the correct place, showing it via GuiInterface call, selecting the correct variant depending on GUI interaction context. (Maybe my friend to make it easier this single entity approach is a good start?) Edit: May be even better to always keep the quasi entities ingame, but the non-looping (!) animation's rest position being far below ground level. This way no timeout is required to hide the entity|move out of world. Neither is moving into world required then (saves 2 of 3 engine calls, good for performance). So no show,hide and instead: Move to cmd.target coordinates. Select animation which triggers it to play once (making it show and disappear like in your great model and animation, @stanislas69. High quality works. Thanks man!)
  4. Surely nice to have. Usefulness could be questionable if one considers all the lines crossing all over if you give more queued orders for multiple units|groups. Stan, you are in the GUI, this means you have to use GuiInterface to interact with the simulation (if you want to add a simulation entity). There are other graphics only ways of course but I'm of no help as I am overwhelmed with thousands of code issues myself. That's the thing with virtual world - it adds to the real world issues. haha. Which is why I wish to reward all those altruistic open source contributors.
  5. 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).
  6. norse

    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.)
  7. 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!).
  8. 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.
  9. Sorry, I can not test which makes me pretty useless. :|
  10. 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)!)
  11. 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)
  12. 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." ;-).
  13. 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.)
  14. 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.)
  15. 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.