MirceaKitsune

Ah, it's a Python version issue? I hope at least an emergency fix like this is possible to address soon, especially if a PR exists and only needs approval. I have the 0 A.D. release installed by the package manager, but it's already well behind the many changes and features in Git so I've only used the later for a long while.

Hello. I'm experiencing a compilation issue for latest 0 A.D. Git on latest Manjaro Linux stable, would like to know when a fix is projected. I tried asking on Discord but some bot called MEE6 glitched out DM'd me an unrelated spam warning and this morning my mention of the issue was removed from the server, no idea what must have happened but hopefully it's okay to post here. Here's the relevant part of the log, the complaint seems to be about something called SpiderMonkey and a module named six.moves: Building SpiderMonkey... SpiderMonkey build options: --disable-tests --disable-jemalloc --disable-js-shell --without-intl-api --enable-shared-js --disable-jitspew patching file js/src/moz.build patching file js/src/old-configure patching file python/mozbuild/mozbuild/virtualenv.py patching file third_party/python/virtualenv/virtualenv/discovery/py_info.py patching file python/mozbuild/mozbuild/action/process_define_files.py patching file python/mozbuild/mozbuild/backend/base.py patching file python/mozbuild/mozbuild/preprocessor.py patching file python/mozbuild/mozbuild/util.py patching file python/mozbuild/mozpack/files.py patching file build/moz.configure/flags.configure /archive/mircea/Games/0ad/0ad_GIT/libraries/source/spidermonkey/mozjs-91.13.1/python/mozbuild/mozbuild/configure/__init__.py:915: SyntaxWarning: invalid escape sequence '\.' RE_MODULE = re.compile("^[a-zA-Z0-9_\.]+$") Traceback (most recent call last): File "/archive/mircea/Games/0ad/0ad_GIT/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/../js/src/../../configure.py", line 22, in <module> from mozbuild.configure import ( File "/archive/mircea/Games/0ad/0ad_GIT/libraries/source/spidermonkey/mozjs-91.13.1/python/mozbuild/mozbuild/configure/__init__.py", line 13, in <module> from six.moves import builtins as __builtin__ ModuleNotFoundError: No module named 'six.moves' ERROR: SpiderMonkey build failed

I had no idea this was already proposed for nearly a decade. I imagine it was simply forgotten? Glad I could bring some attention to the concept, maybe now it's possible to give this a try somehow.

Nice! Sounds like we already have many features from their Advanced Diplomacy concept: The three Enemy / Neutral / Ally states always existed in 0AD. While you can't put time limits on them or restrictions just on economic activities, you can always break away... in recent versions I've had AI break neutrality pacts and go back to enemy, thankfully not alliances which would be more difficult on players. You can even send resources to your enemies, always wondered if that makes AI more likely to accept a neutrality pact... since it's already default we could allow it with units too, if you want to keep a match going for longer give troops to a nearly defeated foe so you have what to keep fighting. And implementing this should also be super easy with no engine changes: Next to the buttons to tribute food / wood / stone / metal, just add a button to tribute the selected units... when clicked all units become those of your ally where they stand as if captured. So if there's nothing I'm missing that could result in significant bugs or disrupt gameplay in unexpected ways, I'd say this is a fun concept we could try out with a mod then merge it if it plays well!

I still run into this issue during my games and it's always a headache I'd be happy without. Whenever I'm out of resources my barracks forcefully disable auto-queue... if I don't see the little text announcing it or know which building it refers to, it can take minutes before I realize I'm no longer producing soldiers and remember that's why. It would be both more logical and pleasant if unit production just paused instead and you weren't limited in what you can schedule including upgrades, this already happens when the limit is not having enough houses so why not do the same for insufficient resources as the population cap?

I thought I already posted this but it seems not, and it's an idea I'm quite interested in so I'd like to hear what you think! What if we made it possible for allied players to donate units to one another, based on how they can give each other resources? Just like Player 1 can send Player 2 a tribute of 100 wood, they would also be able to give 10 soldiers to another faction, even a building like a tower or barracks or civic center. An extra button in the alliance menu would be available, when clicked all own units you have selected become units of that faction. This should probably be a game setting rather than a default universal change, but I'm quite interested in supporting this as an option... at worst it should be easily doable as a mod to test the idea and see how the concept plays out. Technically speaking I see no limitation: Players can already capture units from other players regardless of faction... this includes living units even if that isn't supported by default and only buildings are possible to catch, a change to the unit json allows capturing and using even enemy soldiers. When you capture a building that's irrelevant to your faction you won't be able to use it, like if you aren't an elephant warrior faction an elephant stable is useless if captured... it's then the responsibility of your ally to give you units you can use, but most are universal so soldiers from another faction would work the same way and fight for you. I think this would add a fun new level of strategy between allies based on how much you wish to help them: If I have enough soldiers but my ally is on the verge of death and resources may not be enough to save them, give them some of your troops which immediately get to work gathering or attacking. Or maybe I have an extra barracks I'm no longer using, I can give it to my ally instead... it can be in my base as there's no territory decay between allies, the ally can then train units in my area if I decide that doesn't bother me. If I'm generous or think that makes me safer, I can even donate a civic center I built or captured, useful if I don't want to focus on securing that area and would rather have an AI do it for me. I see lots of fun possibilities to how this can play out!

I had been thinking about something; Not a thing I'm likely to do myself especially as I haven't modded 0 A.D. yet, but I was at least wondering if it's possible. What would stop us from having this as a mod? Unit editor mod: When enabled you open a special menu which lets you edit units during a game and apply changes! I presume the biggest obstacles would be realtime asset loading and hot reloading of unit settings. The former would likely be manageable, you'd just get stutter when loading an unit that wasn't already precached at level start... the later would require being able to change the stats of existing units as well as add or delete them during a match, this would likely be complicated as the engine wasn't designed with that in mind: You may be able to change the health / attack / defense of existing units but probably can't define new ones, not to mention making then use different icons / models / sounds whereas things like new command icons appearing on existing units would also be a problem (eg: I defined a new soldier and want it to appear in the barracks the moment I hit Apply). Other than that I presume no sandboxing system forbids a mod from saving changes to a unit json like a text editor would, so you could do edits in fields and have the menu translate them to text and update that unit file. How far would such a system be able to get right now? What engine changes would be required to support such an unconventional idea? Even if the engine didn't have obstacles I doubt someone would put time into this... unlike Minetest I never made mods for Pyrogenesis but am familiar with JavaScript so if I had a base example maybe I could do the fields? Imagine how awesome it would be though, having an in-game menu to edit units with immediate effects while a match is running... we could even give it multiplayer support to have collaborative game design! Probably just a dream but a nice one to have

That solved it, thanks! Haven't started a game but the Git version now boots to the main menu successfully

An update on the situation: I can now successfully compile the latest Git version of 0 A.D. again without any errors, on the latest snapshot of Manjaro Linux. However I can't run it due to a missing library issue. /home/mircea/Games/0ad/0ad_GIT/binaries/system/pyrogenesis: error while loading shared libraries: libicui18n.so.73: cannot open shared object file: No such file or directory I have the ICU package installed. However my version is 74.2-1: I take it Pyrogenesis needs to be updated to use this newer version?

I presume this is the same issue I've been having? I could compile well on Linux for a long time, but suddenly the process no longer works! I thought it's an update in 0 A.D. Git, it may as well be something that changed in my Linux distro (I use Manjaro KDE). For me the error is: make: *** [Makefile:271: output/debug/FCollada/FUtils/FUXmlDocument.o] Error 1 make: *** Waiting for unfinished jobs.... ./build.sh: line 28: die: command not found ERROR: FCollada build failed

Ooops, I missed that part, sorry! Now it's in fact working Only issue I'm noticing on my first try is a few seconds after loading some things appear black and I have low FPS, once all textures have loaded and it clears up everything seems to be working well. Happy I can confirm Linux / amdgpu is also working well with this!

I decided to try recompiling 0 A.D. from Git on my Linux / Manjaro box which thankfully still works fine. I can start the compiled version without issue on the old settings, but once I select the Vulkan backend from the menu and restart Pyrogenesis it crashes on startup. I attached my crashlog.txt which can hopefully be used to explain it: crashlog.txt

Yeah the fields would need to be kept up to date. What was the original actor editor? A good design idea might be to keep the fields easily editable in the GUI software, so things can be quickly updated without having to recompile everything or do massive restructuring if a unit field changes.

Although the way units are presently balanced makes sense and feels well sorted, there's one little thing that never felt right to me. I never understood why cavalry can't also pick berries from bushes: Wanted to at least ask if anyone else thinks there would be sense in making riders able to harvest berries as well. I believe I tried to mod this as an experiment but there's no animation for berry harvesting so it looked broken, this might require model changes unless the existing hunt animation also works. From a logical perspective, it doesn't quite make sense why an unit that can hunt wildlife and gather meat can't gather berries in a basket. Since cavalry can already gather food by hunting, why would berries be an exception? It feels that if one is possible the other should be too. Obviously they couldn't farm fields only foot units should do that. From a gameplay rationale, some maps have many berry bushes scattered in random places: It's difficult and wasteful to make a farmstead near each one to send women to pick them. Cavalry being able to travel more quickly to deeper woods in order to retrieve berries would probably play better and give everyone a small but fair advantage... enemies on their end could be further incentivized to explore nearby neutral territory to drive hunting horsemen away.

This is something I've been wondering for a while now. I had plans to play around with making custom factions, either using the models / sounds of the default ones in a custom setup or even unique assets from other mods if anyone has any to share. So far I've briefly played with modding to change a few default functionalities as a mod, I'm aware you do it by editing or creating json files for units. Of course doing so manually in a text editor can be harder and more time consuming... thus I was wondering: Is there a GUI to facilitate unit editing and creation? I was thinking something similar to the character editor in RPG Maker: You pick an unit (building, soldier, trooper) and have fields to easily edit all the basic features... icon, health, armor, upgrades you can research, unit cost and upgrades required, build restrictions, territory decay, etc. Same with aura and upgrade and such definitions. It could even be expanded to define custom resources or the parameters for random maps! I'm not aware of such a thing existing at this time unfortunately; Depends on whether anyone considers it worth it enough to make one, personally I'd find it very useful especially if it had stuff like previewing the models. It would probably be easy to do as a Python script since there's libraries for both Qt and GTK to define an UI... this could also be made into a component of the Atlas map editor which could make more sense, even editable from Pyrogenesis itself which would allow realtime previewing though this could be more complicated.

From what I understand as someone who isn't familiar with the engine code, the hard limitation was the engine not yet making it possible to define light sources attached to units or map props. Once Pyrogenesis were to support spawning point lights and spotlights, it's indeed a matter of adding it to existing assets. What we probably want by default a bunch of buildings (such as Civic Center or Temple) having one or two flame torches. Another great improvement would be lit windows, not sure if those should have light sources as an emissive window texture could be enough. Think I actually asked about that one: Another issue we have is night maps are rare, this will be most visible and useful on them. So a great additional improvement would be taking all the maps (especially random ones) and adding a night mode to them, currently only a handful have it instead of being something universal. A day / night cycle is also a relevant feature. PRB would be awesome but feels more secondary by comparison: Especially for a RTS where you don't see close detail it might be less immediate. Would definitely look nice if the helmets of guards had proper metalicity!

May I bump this to ask if any progress has been made since last time? Alpha 26 was released recently: A27 is about to be upgraded from OpenGL and feature a Vulkan backend. Given the new renderer, is the way paved for allowing buildings / units / map decorations to correctly have their own lights? I feel the lack of custom light sources is the biggest relevant limitation still left in Pyrogenesis.

Correct, the planet wouldn't be to scale obviously: It would be more the size of a small meteor technically speaking. That's the one bit of realism that wouldn't be possible... unless someone wanted to wait an hour for the map to finish generating then get 1 FPS if the system doesn't run out of memory in the process, we might get something the size of the moon in that case Then again this is an environment where an entire empire is built in 30 minutes as buildings and people are created and grow up in mere seconds, spacetime scale would never be accurate. That is fascinating to hear about! Is it going to be an open-source project we will all be able to enjoy? Any demos screenshots or videos that can be shared at this date? I always wanted to see a scifi RTS built on Pyrogenesis, the engine is great for it and other genres as well. Also a fun little fact: Part of what inspired me to consider this feature is a game from my early childhood. I believe it was called Populous, I'm sure there's at least one other person here who's heard of it and played that decades ago. It was the first fully 3D game I ever played and one of the earliest: It was a RTS where 4 tribes met and fought on different planets using shamans and magic. I don't think it had planet mapping for the world either, especially in that era I doubt they could have went that far even if they wanted... I do remember you chose a planet from the menu or something like that.

I know this is less likely to happen in practice, given it would likely require significant engine changes for something many might find too unusual to be worth it. At the same time, especially considering Pyrogenesis can be used for different products and genres including space / scifi, I definitely don't see it as something too wild to consider at all. So yeah, I was thinking about planet maps. Right now a map must be flat, circular though rectangular edges are also supported if I'm not mistaken. Were this idea to happen both custom and random maps would support an additional spherical format: When used the terrain is generated as a sphere rather than a plane. Obviously it could only produce unrealistically small planets you can easily circle around... even so it could be an interesting concept for sure. Such maps could provide both unique mechanics and visuals alike. Mechanically the biggest change is everything warps around, you can attack from different sides which would make the gameplay special. Visually it would also be an unique feat rarely done in an RTS: Apart from having an actual horizon where distant terrain covers while buildings have different inclination (think the effect in Animal Crossing), imagine being able to zoom out and see the whole planet from space! Obviously this would imply big changes to scrolling and movement: The camera would work differently as it pivots around the center point of the sphere, moving the view would also rotate it. All unit / building models will need to point toward the center of the sphere, otherwise just be aligned too the spherical surface and that should be it... not sure if pathfinding would have bigger issues getting adapted. Daytime and atmosphere would be a trickier one since we don't even have a dynamic day / night cycle for existing maps (although I think one can be scripted), seeing the proper time of day based on your camera position would be the cherry on the cake were the the rest to be implemented successfully. If supporting actual sphere mapped terrain is impossible, a simpler alternative would be allowing rectangular maps that are seamless and repeat around the edges. This would surely be easier to implement, main hurdle being a technique to render copies of terrain and models across seams while also allowing the camera to scroll seamlessly. However this method wouldn't allow zooming out so you can see the entire planet and manipulate it like Google Earth, zoom would have to be limited or you'll see infinite copies of everything.

Visually it does seem to look identical which is interesting. The guaranteed speed boost I'm seeing in that video is definitely welcome! Want to wait a bit longer seeing how new the Vulkan backend is, then I'll love to give it a try myself.

This will be such a massive and awesome change I'm sure! I'll likely wait a bit till it's more stable then help test when a new appimage is out later. I use Linux on the builtin amdgpu module, a somewhat rarer setup so if there's anything wrong I can hopefully catch it.

For now I'm likely going to skip this feature as it makes my mod more complex than where I wanna go. If the engine adds support for this on units later, that would be an interesting feature to have and play with. I also noticed something else: The game will break and print tons of errors if you add a negative value to resource trickle. This does feel like a bug to be fair and it would be nice to see it resolved. If anyone can't reproduce it let me know and I'll try it again and share what's happening.

Yes, it's how I found this inconsistency. The outpost has a customized TerritoryDecay but lacks the TerritoryInfluence: That makes sense in its case... for the Storehouse and Farmstead however, which I'll allow building anywhere for my mod, I would have liked disabling decay but still allowing the territory influence. Technically I could disable decay entirely and leave the influence instead, but then an attacker will have to capture farmsteads / storehouses manually even in their own territory which is kind of illogical. So for now I commented out the influence paragraph in the XML and the buildings do indeed work like the outpost, if it doesn't break anything important I can go with this functionality for the mod in the end.

While playing around with modding I found what must be a bug in the engine... or perhaps just functionality I don't understand, but I'd rather have it clarified just in case. I'm trying to make some buildings possible to place anywhere (both own and neutral territory) but only decay in enemy territory (not neutral). So I set <BuildRestrictions><Territory>own neutral</Territory></BuildRestrictions> with <TerritoryDecay><Territory>enemy</Territory></TerritoryDecay> but there's a problem: I must also remove <TerritoryInfluence></TerritoryInfluence> otherwise the building will still decay and fall to Gaia. It's worth noting that if I set <TerritoryDecay disable=""/> instead, the building will no longer decay even with the TerritoryInfluence field left there. The two only seem to conflict if I want to have decay but only for enemy and potentially ally territory. Is there a reason why you can't disable territory decay on neutral ground without also disabling territory influence? Why does the later cancel out the settings of the former?

Should be useful, will look more closely tomorrow, thanks. Does it require custom scripting or is the "consuming" field a builtin setting? I also found something called resource trickle in the defaults which I presume is an interval based decrease, may come in handy to at least simulate food getting used over time.