All Activity
- Past hour
-
@ThalattaThanks for you comprehensive review! My point is that I try to not substantially modify fundamentals in game mechanics just add a slight touch of more complexity. Salvaging allows getting resources in an emergency via a separate path (not trading, not gathering which might both not be possible in a situation). I'd prefer "salvage rate" so in the end it amounts to "salvage rate × condition = refund". It is a bit complex but I believe we should keep the ability to fine tune. Here we have rules we can turn on and off and also adjust some parameters ("when not sure make it configurable" ) I wanted to have configurable options so there might be a reason why certain types of buildings are excempt (chnged it to exclude fields but not exclude wall segments and towers anymore). So the mechanics is there and it can be configured to exclude what ever building we want - or none. The building shall be recovered only in peace times, i.e. it is not under attack and hasn't recently (15s, configurable). I wanted to make really sure it s not being attacked and not being taken over and is not partially "owned " by someone else, hence the multiplicity of rules. Destruction must be carried out by someone nearby (presence of a unit in 20m, configurable) I also thought about your proposal to let workers destruct (unproduce) a builidng (same animation like construct), but I consider this confusing to see exactly the same animation taking down as building up ("in the heat of the game..."). Absolutely - good point! Will remove that. Walls segments and towers are back in. Same rules as for all builidngs apply. I wanted to avoid adding another icon that might clutter the user interface. Let me experiment if we can "auto-salvage" ships and sieges. (click delete icon (means slavaging) and the ship or siege goes back to the nearest dock or depot where it is dismantled). No, its all of them. At the moment, buildings that don't satisfy the condition (unit nearby) are destroyed exactly like before, but no refund. Destroying with refund takes 10s (draining their health condition until they collapse - and only then there is a refund. The process will be cancelled by any attack). But they are not queued - so if you slect a group of builidngs, hit delete and have a unit nearby each, it takes 10s. I suggest modifying the general delete mechanics to take a few seconds both for structures - and also for units. Let me test if that works.
-
Jaishumane joined the community
-
Implementing forces in Unit Motion (HELP WANTED)
Stan` replied to Atrik's topic in Game Development & Technical Discussion
Maybe @Alexandermb has some time, you might have to contact him via PM though so he gets an email or something. -
Map making support and conversion tool: post-Atlas
Grautvornix replied to Grautvornix's topic in Scenario Design/Map making
Thanks! Very good - I'll take that on board. Oops! Good point as well. Needs to be changed. You are right, was just lazy and tried to keep it initially simple for me on a local repository. Will change that. - Today
-
Asher started following Map making support and conversion tool: post-Atlas
-
Good. Just give a name to the first percentage, it's salvageability, but maybe you can think of some other name. You could start with a 50% default for everything, to be fine-tuned later on if wanted (and food maybe could be ignored, because it's weird to salvage it). Incredibly complicated! And why? Why shouldn't walls and towers give a refund? Their stone was among the most salvageable resource. You said it yourself how things should be already, at least for buildings: And that's it! You later used the word "elegantly", then do it so: simple, no steps, no caps, no gaps, no radius, no more parameters, emulating existing processes, or their reverse. There you basically proposed to use unit(s) to unbuild structures, to be rewarded what I quoted from you at the beginning. Maybe I'm missing something, but I don't get why you would need ANY extra rule. What I quoted from you produces a simple rule: salvaging is unbuilding. For units, I can't help but keep saying that you don't need any extra rule! You use the same rule as with buildings: just unproduce them. Why complicate the ship rule with a radius, if you could just click a Salvage button on the ship, and then click a Dock, and all should be automatic from there? The ship would travel to the Dock, garrison, and get salvaged. All the radius thing is not simpler, not needed, not realistic, and not intuitive because the unproduce rule imitates that of buildings. Same with siege engines. Besides, you state you can dismantle (some of) them in one's territory, when one is not able to construct them there in the first place, incurring a logic gap. I agree doing so should be part of the game (with those big engines being extremely slow in return), but that's not yet there. When it is, yes, dismantle them wherever they can be constructed, to keep following the simple unbuilding/unproduce rule, but in the meantime it would be incoherent: the disassembly being realistic, while the assembly isn't. No. Scorched earth tactics should not be ultra-fast, that's exactly the point not to get the unsightly simultaneous collapse of everything (by the AI at least). What should be ultra-fast is deleting some building or unit that is bothering the player (I'm exaggerating with "ultra", it could take a very few seconds). The whole point is: you can use Self-Destruct, but you can't abuse it. The key is what I said: "only gets noticeable the more buildings at a time one wants to destroy". Thus, the best way to deal with all these and other issues at the same time seems to be modifying Self-Destruct the way I explained before (queue buildings, queue units in parallel if considered, and sequentially in each of both queues drain their HP at like 1000/s, etc), and all this has nothing to do with Salvage, there's no resource reward, because it's simpler and faster to execute.
-
Map making support and conversion tool: post-Atlas
Asher replied to Grautvornix's topic in Scenario Design/Map making
Also if you could add tool tips. When on dark theme, it is had to tell which buttons you can click and not click (see photos). Could you have some other colors, pwease. Also, do you use github or gitlab or any of those type things? It might be easier for other people to update or something -
Map making support and conversion tool: post-Atlas
Asher replied to Grautvornix's topic in Scenario Design/Map making
I loaded some maps, and it worked. Can you make it so you can load mods for it, like if you are making a map for a mod that adds new structures. Because it was saying a certain civ name was undefined, but it was, just in a mod. Maybe you already added the setting, but I didn't see it - Yesterday
-
All right here is my proposal: a refund is limited to a percentage of the resources it took to construct something, say, 50%, multiplied with the current health status of the object, i.e. a ship at 60%health gets 30% refund. all refunds are tied to a condition: ships must be within the perimeter (30m) of your own dock. Outside that area there is no refund. siege engines must be on your own territory, no refund outside. buildings are more complicated: some should not give a refund (walls, towers), others only give a refund if not under attack since 15s and fully owned, and if one own unit is present in their vicinity (radius 20m). Deletion wiht refund becomes a salvaging teardown: the building loses health over, 10 seconds, the resources arrive at the end, any enemy damage during that period cancels it. Deletion of buildings without anyone nearby, or not satisfying the other conditions is immediate and without a refund. All of this remains configurable as I am not yet sure about the best settings (distances, level of refund, criteria, teardown period) I'll adapt the mod and test it first before posting. Done testing. Please see below for the mod. WIll also put it onto mod.io and hope it can be signed @Stan`@ltms recover-resources.zip README.md
-
OK, point taken - how could that be addressed? Should we introduce steps and/or a cap, like 0% finalized- 100% refund, up to 70% finalized - 30% refund, more than 70% finalized - no refund anymore. Deletion after completion - 30% refund. Would that work for you? Currently no salvaging of destroyed buildings exists and they can be immediately deleted anyway at the moment. Requiring units (no siege engines) to actively destroy own buildings woud prevent doing that to a whole group of buildings at once already. Would you really want to use valuable units to destroy that one storehouse that's not needed anymore jsut to get back, say, 30 wood? For me this could be an emergency aspect to get more resources if none is in reach and no bartering is possible anymore, e.g. after a devastating attack of your enemy. Of course, but for gameplay and simplicity I would possibly tend towards the same level of resource refund (we could use the same mechanism). But isn't that a contradiction? If it shall be ultra-fast (scorched earth tactics) it cannot be queued as this would take too long.
-
Map making support and conversion tool: post-Atlas
Grautvornix replied to Grautvornix's topic in Scenario Design/Map making
Did a total review and refactoring of the user interface and functionality. Hope it is better now. I am placing the python code and new screenshots in the original post on top of this conversation. @Asher I'd love to have your comemnts - please have a look! -
Implementing forces in Unit Motion (HELP WANTED)
Atrik replied to Atrik's topic in Game Development & Technical Discussion
Also, if anyone interested know how to animate, we are looking for charge animation (strike while moving) and staggering animation. -
Hi everyone, I've been looking into the possibility of creating Proto-Germanic voice lines for the Germans in 0 A.D. First, a note about AI: I used ChatGPT to help me find linguistic sources and prepare the first word suggestions below. This is preliminary research, not a finished translation. I'm not a historical linguist, and the proposed forms have not been independently reviewed by one. Some of them may well be wrong. No audio has been generated yet. My idea is not to reconstruct exactly what the Cimbri spoke around 100 BC. As far as I understand, the surviving evidence simply doesn't allow this. Instead, I would like to find a reasonable linguistic approximation that fits the historical setting of 0 A.D. and sounds good in the game. We only need about 18 short voice lines. Ideally, they should be one or two syllables long, but I don't think this needs to be a strict requirement. Before experimenting with recordings or text-to-speech, I would like to get the words and their pronunciation into a reasonably good state. 1. Which language should we use? Release 28 describes the Germans as a coalition of the Cimbri, Teutones, Ambrones and other Celto-Germanic groups. Official Release 28 announcement The linguistic situation seems rather uncertain. For example, Gilles Quentel discusses early contacts between Continental Celtic and Germanic. There are also different interpretations of the surviving names of the Cimbri and Teutones. Bichlmeier and Blažek discuss several possible etymologies of these tribal names in their 2020 publication. I think reconstructed Proto-Germanic could be a reasonable common language for the faction, as long as we make clear that this is an approximation, not a reconstruction of an attested Cimbrian dialect. There is also the question of the First Germanic Sound Shift and its chronology. For our purposes, I would initially use a consistent reconstructed Proto-Germanic pronunciation rather than trying to reconstruct a hypothetical earlier dialect specifically for 100 BC. Of course, I would be interested in other opinions on this. 2. First suggestions for the voice lines I used the English meanings from the Audio Voice List, with the Latin translations as an example: Audio Voice List – 0 A.D. Wiki The following is a working draft, NOT a finished or academically validated translation. All proposed Proto-Germanic words and forms are reconstructions, not directly attested historical expressions. Some of the specific forms still need linguistic verification. Most candidates were initially found through Wiktionary's Proto-Germanic reconstruction entries, which often refer to etymological dictionaries such as Kroonen or Orel. However, I have not independently checked every individual reconstruction against these books. I also used the freely available Proto-Germanic grammar by Winfred P. Lehmann and the IE-CoR linguistic database. Some forms are more tentative than others. I have marked the particularly uncertain ones instead of pretending that we already have a complete solution. Selection and greetings English Proposed form Notes Hello hailaz! Literally "healthy, whole". A possible greeting, but not an attested Cimbrian one. What is it? hwat? Simply "what?". Shortened for gameplay. My lord? frawjô? "Lord", without "my". The appropriate form of address should be checked. Movement and fighting English Proposed form Notes I will walk gō "I go / walk". I will fight fehtō "I fight". The meaning and exact form should be checked. I will attack! hwētō! "I attack". This candidate needs further linguistic checking. I will march! farō! "I go / travel". Not specifically military marching, but perhaps sufficient for a short acknowledgement. I will retreat! wīkwaną "To yield / retreat". This is still an infinitive. A shorter and grammatically appropriate spoken form is needed. Battle cry open Perhaps a non-verbal shout would work. Alternatively, a short expression based on a reconstructed verb for fighting could be considered. I would not want to invent something and present it as an authentic Germanic battle cry. Working and gathering English Proposed form Notes I will build timrō "I build". I will work land arjaną "To plough". The appropriate short spoken form still needs checking. I will gather samnō "I gather / collect". I will herd drībō "I drive". This could refer to driving livestock, but is not exactly the same as tending a herd. I will fish fiskō "I fish". I will repair bōtī "Improve / make good!" Not specifically repairing a building. The form and its use in this context need checking. I will hunt huntōn- Reconstructed verb stem only. The precise form and vowel length remain open. I will heal hailī "Heal!" An imperative rather than "I will heal". The exact form needs checking. Regarding hunting, the IE-CoR database gives huntōn- as its reference form, but its explanation also mentions hūnton-. The vowel length and the actual spoken form therefore need further checking. Other (I will put myself into) garrison — felhō Intended meaning: "I enter / go inside". This is one of the least secure suggestions and needs both lexical and grammatical checking. It is not an attested term for entering a garrison. A few remarks about the list The grammatical forms are not consistent yet. Some are first-person forms, others imperatives, infinitives or reconstructed stems. Personally, I don't think every response necessarily needs to be in the same grammatical form. The important thing is that it works as a short and natural-sounding acknowledgement in the game. However, we should make sure that the individual forms are actually plausible and not simply invented by an AI. Also, several suggestions deliberately use a broader meaning than the English original. For example, "I travel" instead of "I march" or "I drive" instead of "I herd". These would be gameplay decisions, not exact translations. I would be happy to replace any of these suggestions if there are better alternatives. 3. Sources Here are the main sources I found. Historical background Gilles Quentel (2012): Early Linguistic Contacts between Continental Celtic and Germanic: Lexical Aspects. Publication on ResearchGate Harald Bichlmeier and Václav Blažek (2020): "Cimbri" et "Teutoni". Journal article – Acta Linguistica Lithuanica Václav Blažek: On chronology of the First Germanic Sound Shift (Lex Rask – Grimm). Publication via DOI These publications discuss historical names, etymologies and linguistic developments. They do not provide translations of the 18 voice lines. Grammar and pronunciation Winfred P. Lehmann: A Grammar of Proto-Germanic. University of Texas at Austin. Complete online grammar The chapters on phonology and inflection are particularly relevant. R. D. Fulk (2018): A Comparative Grammar of the Early Germanic Languages. Publisher's page – Open Access e-book The complete e-book is freely available. I have not worked through the whole book, though. Vocabulary IE-CoR – Indo-European Cognate Relationships Linguistic database One useful example is the entry for "hunt": IE-CoR: hunt. It references Kroonen's Etymological Dictionary of Proto-Germanic and also illustrates why some details need further checking. I also used Wiktionary's Proto-Germanic reconstruction entries as starting points for individual words: Proto-Germanic reconstructed terms Some examples: fehtaną – to fight timrōną – to build fiskōną – to fish hwētaną – to attack These entries are helpful for finding possible forms and references, but they are not a substitute for checking the original academic literature. 4. What is still missing? Before recording anything, I think we would need: Someone with knowledge of historical Germanic linguistics to review the suggested words and their grammatical forms. A consistent pronunciation guide, preferably using IPA. Better solutions for the uncertain expressions, especially retreat, repair, healing and garrison. A decision on the battle cry. A way to produce natural-sounding recordings that can be freely distributed with 0 A.D. I know there has already been some discussion about AI-generated content in the project. I'm not attached to using AI for the final audio. Human recordings would be fine as well. For now, AI has mainly helped me find sources and put together this preliminary list. I would be interested to know whether AI-assisted linguistic research is acceptable for this kind of contribution, and what the requirements for the final recordings would be. 5. Questions Does this general approach make sense for the Germans in 0 A.D.? Would reconstructed Proto-Germanic be a suitable choice, or should we consider another linguistic approach? And is anyone here familiar with historical Germanic linguistics who could help check the proposed words and pronunciation? I would be happy to continue working on this if there is interest. Thanks!
-
Oh sorry, I was pretty sure I disabled all mods, but one was still there. I disabled it and didn't get the error. Sorry
-
Implementing forces in Unit Motion (HELP WANTED)
Atrik replied to Atrik's topic in Game Development & Technical Discussion
Exciting news! I've finely brought this project to a testable and reviewable state. A big change since my last posts is that I've managed to make the performance impact minimal. The inertia system pay for itself and is kinda having 0 cost including the collision detection logic and other logic related to it. Having a lot of units that have the "charge" effect fighting is also demonstrated to be reasonable on performance with only a few percent increase in simulation cost for a given battle. This project have a lot of implications, and anyone willing to be testing the PR and giving feedback would help tremendously to make it move forward. If you are able to, please do. PR link -
Sounds like the gui/session/session.xml file is out-of-date. Are sure you have nothing modified and no mods loaded?
-
Good to know! And a big thanks to @Vantha
-
Just opened 0ad, and got this. I got it even without mods. 0ad would start -> I would go to matches -> new game -> then start, and it would start, and then it would quit
-
True. But not everyone can contribute the same way. Making tools more accessible could bring in more creators.
-
I get it. But I still think there's untapped potential for solo content. And I have huge respect for what the devs have built. That's why I'm here.
-
With a Pull Request you ask that your code be merged into the source code.
-
Not really, right now in the game, when you abort ship or engine training, you get the whole refund. This might be unrealistic, but maybe it would be too punishing and different from other RTS to do otherwise. I didn't think of the second point, and although it makes sense, you can't get a refund from engines that cannot be garrisoned, and you are using a different rule than with ships. That's why I thought for them to go back to the Arsenal. Sure, but that's what salvaging would be. Right now the game only destroys. That's why you return the ship to the Dock to get resources back, it's not the same as scuttling. It's not so much about an actual exploit, but a gap in the logical working of things. If at 70% built I realise I want to destroy the building without benefiting from it, waiting for completion would give back more resources, making this refund scheme unnecessarily irrational, while ignoring calls for it "not to be too simple and rewarding". This is exactly my latest Salvage proposal: "do what you want to do, but require unit(s) to do it ("salvager(s)")". If you just garrison it you don't even need animations, which could be just construction in reverse. If the refund will be the corresponding loot or a "fraction of the materials used" (maybe the first is calculated as the second?) it's just a choice that can be discussed (it's all the same for me, as long as the rule is simple, but in reality salvaging is of course more rewarding than loot). But, on top of that, I didn't want to remove the Self-Destruct option because some people will surely want to delete things ultra fast without any salvaging. That's why I now proposed for it to work like always, but in a queue (you imagine the arsonists, they were supposed to do things ultra fast and as an excuse to solve the collapse issue anyway). Other things to consider regarding the destruction queue: when queued at the same time, elements should be ordered from lower to higher HP. Whatever addition to the queue comes at the end of it. If 50% of the ownership is lost (I think this is the limit to destroy them in the first place right now), elements have to be unqueued (limiting a player's ability to destroy a lot of buildings just before losing ownership, which is what the AI always unsightly does). While units, if considered, should have their own queue (running in parallel), a single queue icon (skull) should appear on the right, showing the remaining time of the whole process (that is, the longest time considering both building and unit destruction queues), which can be aborted by right-clicking on it (already destroyed/dead elements remain so of course, while whatever was being processed at that very moment ends damaged/injured). Unqueuing individual elements should also be possible, maybe by pressing some icon indicating that they are in the destruction queue. The HP drain could be around 1000 or 500/s.
-
Hello my friend, how are you? Sorry for my ignorance, but what exactly is a PR?
-
Sorry, did not see your message before responding to your previous one. The discussion is less about the refund as such but more abpout shouldbalow the user to simply deletey a building (as well as a unit). For buildings, this goes back to the proposal to extend the destruction process a bit. In fact, what if we need at least one unit commanded to "work" on the building to destroy it, providing a similar benefit as when you destroy your enemy's buildings? This could be exactly the same process as attacking an enemy building (only with a differnt animation possibly). Instead of having a building-cenbtered command "delete" we would need a command to units "destroy my builidng", similar to "build that builidng". This could elegantly take care of my previous question "what if an enemy attacks your building while you were destructing it yourself". The mechanism to arbitrate resources in case of concurrent destruction by two parties attacking the same building is part of the game already (I think/I hope, at least this exists for conquering, never checked for destruction of an enemy builidng together with an ally).
-
This is one of the many compromises to gameplay we have to make, I guess. Hmm. You are right. So no refund after destruction at all because the same principle applies to buildings, ships, siege engines? To provide a refund, - ships need to go back to the dock (done) - siege engines need to be manned (at least one unit) prior to destruction I believe we agree already on these two. There is no refund for buildings when they are at 100% (finished), ever. From the real world, I believe that old buildings (ruins) were often used as a quarry/resource for erecting new ones, hence I question the rule 100% built- 0% refund. The rule in game (0% built/100% back up to 100% built/0% back) certainly applies to the resources you had originally put aside to construct that building. After it has been built (100%) you spent 100% of resources, so destroying currently means losing all of it. Could refunding be exploited? Not really: You get a higher fraction back if deleting after finalizing it, but you had to invest the 100% before. The only cheat here is, that you benefited form the building's function (e.g. research a new technology) while it was working and still get a refund after its destruction.
-
Latest Topics
