-
Posts
189 -
Joined
-
Last visited
-
Days Won
1
sternstaub last won the day on December 8 2023
sternstaub had the most liked content!
Profile Information
-
Gender
Male
-
Location
Aachen, Germany
-
Interests
Linux, history, society, programming, singing and playing the guitar
and obviously gaming.
virgo.
Recent Profile Visitors
2.360 profile views
sternstaub's Achievements
Duplicarius (4/14)
75
Reputation
-
Map Scripting: Adding "randomness" to Skirmish maps
sternstaub replied to wowgetoffyourcellphone's topic in Help & Feedback
If randomness is not allowed in the simulation (-> deterministic), i think it must be done in the lobby? Not sure, but Petra AI behaviour can be set to random aswell. -
Building latest revision is currently broken for Linux
sternstaub replied to Riesi's topic in Applications and Contributions
Can build again on Arch with current libxml, thanks Riesi -
Naval Overhaul (Alpha 27)
sternstaub replied to wowgetoffyourcellphone's topic in Gameplay Discussion
Transport ships could also be used as dropsites then. Also, if they have a high capacity like 70 units or so, they can indeed provide utility, depending on the map. Maybe also a speed buff for more garrisoned units? I am neither pro, nor against it (yet) tbh -
I said it once, and i say it again: give game hosts the option to decide such things. Game host could be given options to restrict mod usage only to signed mods.
-
It could be cool for a random map. Do you mean to have 5 wall sections for 5 players, like a star? Is there any documentation references on random maps?
-
Oh, thanks, i see ^^ Can actor trees be farmed by players, or are they decorative objects?
-
-
-
Looks cool and inspiring how did you place long grass?
-
I have the intention of recreating some parts of the roman limes as a map / multiple maps. Such models as yours will be of great help. will stay tuned.
-
...without DE, it cannot be opened Other question - how do you get this fancy skyset? For vanilla, i have now started a rework / new version for skirmish (...multiplayer) games. rheinland-Delanda-est-patch will be the only mod containing the old map. It will not be available for vanilla players. Will be structured a bit differently; i try to give as balanced positions and terrain as possible on an asymmetric map. The main concept of "ore -> mountains" and "rock -> river / swamp" remains. Future extensions will be written and published for vanilla, then patched for mods. I also consider creating copies of mod objects and use them in the game world to avoid breaking the balance / overwriting original mod files.
-
The same on A26. And you can open it in atlas w/o Delanda Est? Could you send the file which you have opened / saved?
-
Proposal to add water as a resource
sternstaub replied to Grautvornix's topic in Gameplay Discussion
Water resource might be an interesting topic regarding regenerative resources. Please consider this: if you build more wells, there is not more water, but you drain more water. Water is not infinite. Question is - how fast does the groundwater in a certain area replenish? More wells make sense when there is enough water in the ground (and new water coming from rain, rivers or underground sources) to keep them all supplied. Also, the farming and fertility component has been addressed. What if we try to organize and discuss under a bigger abstract topic? I suggest micro-biomes (EDIT: environmental patch?). Like territory borders, there can be a micro-biome mask for each map. On map creation, the borders of different micro-biomes can be set or alternatively the areas can be painted with a brush (background being a generic micro-biome, derived from map biome). There could then be many effects and properties applied to such mico-biome, like slowdown / speedup for units, fertility / field gain rate, build restrictions, water regeneration rates, currently available water amount, et cetera. Having an ever-refreshing resource would however require background processing. I can imagine that the multi-threading problem/discussion (0ad utilizes only 1 CPU core and does not compute asynchronously, AFAIK) could play a role when more background processing is, or is supposed to be, introduced. That way, not only the current lack of water dependency would be addressed; it would also introduce another level of mechanic. Which places offer the requirements for settlements? What about fertility and farming? Where to find good ore? Peoples fought and pillaged each other over such matters! This is just an example of how we may try to pull multiple factors and ideas together into a larger topic, so that this topic may be discussed, refined and improved until it's due time. Only adding a water player resource would, in my opinion, not be as fancy as it sounds, since a lot of other mechanics would have to be adapted, the cost would have to be added to all the buildings and units, then the resource would offer more playstyles which need to be balanced et cetera. And in the worst case, the playerbase, or parts of it, dislikes the feature in the end. With the micro-biome dependency, there would not necessarily be another player resource. It could be realized by adding a fountain building type, draining water either from the ground or from the rain, for example. Those could grant a "water supply" aura, affecting fields and refreshing units in some way. Also, i would like to clarify that the content of this post here alone is very likely to introduce a massive workload. Such thinking only makes sense if there is a plan for, say, 10 years. It may seem like a long time, but consider that 0ad is already being developed for quite a long time. With good results, exspecially the next Alpha! Good software takes time, testing, effort and vision. That i believe. But be that as it may - i believe that we can indeed agree to assume that the final, or even beta release of the game will still take a lot of time and a lot of community effort. For such an community effort to be utilized effectively in the sense of enhancing and stabilizing the engine, a long-time planning / strategy and public communication would certainly be a great help. The whole development might be subdivided into 10, 20, 30 patches with certain topics. At the moment, we have the suggestion thread, but posting there feels a bit like lost echo, because so many ideas and topics are being mixed up into this idea thread. If there were one thread (or Subforum) for each game component / each patch / macro-topic that has been planned to take place in the future, the ideas from the general idea thread can be just sorted into the existing system. Like tickets on trac, such ideas may be unattended for quite some time. But when the time is ripe to create the patch in question, all the community effort from all the time can be bundled and addressed. The ideas can then be realized in mods for testing, for getting an idea of how such feature would feel, how it would impact the game. As it seems to be with map-rheinland mod: i create it once, play the map a few times and then get a feeling for how it plays. If i afterwards recreate the map, it is a chance to make it better when i apply the experience from the first run. The same way it is done with bugs, AFAIK. They are lower priority until the release goals have been reached - afterwards, for the rc, the bugs will be searched and fixed. That does not mean that, for example, a demo mod for A43, which is now good and implements features which are planned to be implemented in 2034, would just be copied into the mods/public/ of the main game when the time comes. But the experience beforehand can help the devs to see and avoid problems and issues before they actually decide whether to implement a planned feature, and weather to implement it into the core engine or as js. The same way it is done with bugs, AFAIK. They are lower priority until the release goals have been reached - afterwards, for the rc, the bugs will be searched and fixed. However, I do not know of such long-term overview for the 0ad development, although i would be very interested in it. Any hints or ideas are welcome. what else to say? ..."Enjoy the choice " (not my quote) EDIT: I should give some example ideas for such macro-update-topics: - flora overhaul: try to add as many specimen of trees, bushes, fruit as we can, collect data about them, have meshes, add tooltips, add biome conditions / where those trees do grow. the meshes could be collected from existing mods, maybe? due date: 2031 - diplomacy and trading overhaul: bundle diplomacy and trade into a single window, add an resource overview for allies and buttons to quickly send res to the UI, discuss resource transportation (as addressed in the forums and, afaik, @man_s_our's realism mod), road systems. due time: 2034 - naval overhaul - WIP 2024/25 ? - formation, hero and combat overhaul: discuss different dynamics for commanding units, the effect of heroes on civil soldiers, behaviour and control of ranged units (sniping!), levels of combat automation (through heroes? Give heroes strategies which they actually used as automated command?), battalions and formations, continuous status effect system. many possibilities. due time: 2027? - ...and this one here, which can be called "environmental dynamics update" (better than micro-biome). Maybe bundle it with wind directions /effects, general environmental dynamics and such things? (i just shaked those out of my head, please do not take it too seriously) -
It is an interesting thought to have these different formation trees. Tightening a square formation should go relatively fast. Changing from a square to a line should not. But - is this not the case already? The units have to always walk the distance to their new formation. Anyway - formations have already been discussed on the forums before. Is there a planned time / version when this may be addressed? There are certainly multiple layers of impact to the formations topic, not only how fast they can be changed. Imo, having a "formation patch" / "tactics patch" does make as much sense as having a naval overhaul patch. Or having an "atlas + campaign mechanics" patch (drifting a bit OT here) But if so, it would most likely take quite some time (year+) until this would actually become a priority at hand.
-
Tried to load into atlas after removing all entities from the map.xml - this happens. Issue seems to also affect the contents of the .pmp file. First of all, thank you for taking the time and trying it out yourself This is weird, i can open the file in neither in the game nor in Atlas. Always crashes with segfault. รด.o