sternstaub

https://github.com/0ad-matters nice repository, did not know of it. Thanks for providing

I am watching him play TG at the very moment of writing this looks like a fun thread to me ?

Nice, a Schwertwerfer. He werfs his Schwert. are you suggesting that we'd suggest further suggestions within the post, thus inevitably providing a fifth suggestion, or that the suggestive title of the topic itself contains said fifth suggestion?

Did the problem persist before?

I like the basic idea, but it would have to be done in a lore-friendly way. Cannonballs were not a thing around the year 0. The fire effect on the other hand could be interesting for this. There is already a fire ship which attacks other ships by burning.

It probably will not be a simple "one fix" solution for the lag in the game. I try to understand it at the moment and it is very complex. Anyway, your effort as well as interest in the matter is surely appreciated Your idea to make certain information available only on player's demand might indeed help out with the lag problem.

I actually use the control groups to quickly change the building. For acoustic people like myself, it would be annoying if the sounds were gone for a brief period after selecting a building. Because sometimes, when i press the wrong key, i would just press the 2 neighboring keys until i hear the sound of the building i want to select. So, well, people are different, and personally, i am against removal of unit selection sounds. However this seems to totally make sense for movement / command sounds to me. On the other hand, if you can expect a sound for every valid input you give, it also helps orientation when it's lag.

Cavalry at full pace would actually have to describe an arch if they wanted to turn around... So it adds to realism.

Note: Perhaps it could even be worth a thought to have four components to the game: 1) pyro engine - game logic. to be honest, it would be very cool if it had it's own .pyroscript language / interpreter like TES games (very mod friendly), but that is a lot of work. still, i like the thought. 2) passive pyro libs - libraries with all the models, textures etc. which can be used by pyro engine computation. those do not compute anything themselves. We might call them "passive objects". The libs should not only contain 0ad base-game-content, but also content from mods, so there would eventually be a large library to use for extending the game. This means: all players have the pyrolib available (dependency of ->3), although the base game (->3) does not implement all of it's content. Anyway, mod resources could be available to easily use or derivate from, independent of the mod state. I think about 1000ad for example, which has a lot of buildings / models. Or delanda est. Also consider that art designers can use the existing models from the libs as blueprints / starting points; slightly alter a certain resource, creating a new one in the process, which can then be added to the libs again, etc. You may add as many libs as you wanted, since they do not do anything on their own, as long as they don't overwrite files from each other. Also, i do not want to imply that there would only be ONE pyro-lib. The player could use many libs, as long as they do not conflict with each other. But my intention is for the player to only need ONE library to have all the basic resources needed by many mods, creating a large compatibility layer, so to speak. Smaller, player-created libs should be merged into the master lib as soon as they are in a fine state. (Questions... how to imagine a release cycle here? Many updates? Less updates? how to update? User-friendy method possible? auto-update? tedious clicking?) 3) "master file" (for instance 0ad, 1000ad...) - basically an specific implementation of game logic with the libs. Consider Bethesdas .esp and .esm formats. this ->3 can be a "master file" which can be mounted, and have the mods (->4) override sections of it. These overrides should be traceable for multiplayer purpose, and it shoud be determined whether they are cosmetical or game-changing. Using a different master file would mean a big lore change, like the council of modders projects (1000ad...). Those master files would per nature have a big impact on the game itself, registering civilizations, setting tech trees and determining the game experience as such. It might also be the place for javaScript ? still very unsure about the whole scripting thing. 4) active mods - active mods would be able to "mount" the pyro-libs (->2) and connect them with game logic (->1). both 1 and 2 are hence providing the "frame" for mods. they would serve as an interface to ensure expected, predictable behaviour of modded game clients. For instance, everyone has the 1000ad menu sprites and textures in their lib, but they load the game with "0ad master file" (->3) (let's now rename it to "0ad-active", to clarify), so when they start the game, the engine would look into the active master file ->3 for the menus. Another possibility is that the "master files" are only for "unit registration" (which units exist) and balancing. So that the damage, life, speed, gathering rates... of the different units are fixed by master file (->3) and cannot be changed by mod file (->4). The menus, however, would also be provided by master file (->3), but we can chose that they can be overwritten by mods. Strictly speaking, the master file -> would pose a fallback option for everything which is not overwritten by mods ->3 . It also might or might not make sense to categorize mods, like it is done on nexusmods.com. So that a certain kind of mod would only be eglible to affect the corresponding part of the game. (shiny -> UI mod; ) For multiplayer, maybe have this requirement: player must have the same master file (->3), and they must not apply different sets of mods (->4) in the categories gameplay, corerender (visibility of units to the graphic renderer)(fictional example), technologies and some others which would have to be determined accordingly. Are You referring to a design change in pyro API ? A kind of meta-library, as mentioned above, might part of a solution here? How many active devs are working on the game (round about)? Cannot estimate. This might be a matter of how it is done, and of the point in time. At the moment, there is the public mod for some (or most?) of the specific implementations for 0ad, if my - currently vague - understanding is correct. What if the 0ad-implementation (->3) were to be a mod itself, but in the means of (->4) a pure game logic instruction mod? I know that we already have the 0ad base mod (/mods/public), but currently, it contains all the sounds, the maps, the unit models, materials etc.; These resources might be stripped from game logic. The resources may then be added to the public library (->2). The game logic be added to another "base mod", implementing At this point please consider that the game 0ad itself *is* actually an implementation of pyro engine logic. At the moment, they are entangled in source, so to speak. My proposal would thus be to generalize pyrogenesis logic, so that separation of both can be done in a practical way, and in the best case even provide a custom scripting interpreter with all the basic instructions to be used by mods. A script language tailored to the needs of RTS would be sandboxing per design. Those may be attached to units, like actor.ATTACK(attackable x), actor.BUILD(), or to the world, like placeActor(actor, position), placeActor(actor, position_anchor) or whatever. This is still quite vague. Several different thoughts in a combination. it could be eased with libraries which "stay in the background". at the moment, we have this "multiplayer friendly" option. This points to the direction of the library logic mentioned above. But the basic functionalities which are provided to mods might be pre-defined by the engine. Like handles. That basically would be a custom script language? The process of implementing such handles - or, call them script commands - would require close communication with the modders, so that they can fit the different use cases of the mod devs. When many new functionalities are demanded by current modding projects, this might indeed imply a cumbersome update procedure. But: Once this reached a state where most demands are met, only smaller updates would be neccessary - ideally. As soon as such a thing would be established, it would put the behaviour of mods into a more predictable frame, at the cost of mod dynamic. It also implies a close connection between modding and coreDev workflows. At this point, think of the community mod, which brings change on a much quicker pace than 0ad -> different release cycles. Please do not take this post too serious; still need to get into JavaScript much more. Many lose thoughts, anyway.

i believe that it gives 1 of each res every 2 seconds. this is a nice idea per se and i did not want to contradict. what i wanted to say is that there already is a mechanic like this already, so maybe they can be connected. Or the corrals can be for food trickle and the wonder does III + IV res trickle. Or there can be basic techs for res trickle on the corral and advanced tech on the wonder. i just like it when similiar concepts are kept together.

I think that "water source" is not a concept in 0ad; water is determined by terrain height.

Isn't this what a wonder does?

Hello, i wanted to suggest something for ranged units. The idea is simply to have an area attack for archers / ranged units. it would be interesting imo if this attack would have a bit higher range than regular attack, but would be affected by spread / less accuracy. Also, it would hit all units in the area, friend and foe. This would add a bit of dynamic to ranged gameplay and also be somewhat more realistic than hyper-sniping only enemy troops in the heat of battle. This probably only makes sense if the units are also handled as battallions, so that they attack in sync. Extra checks for each unit might be costly. There is a topic about battalions Let's just see what your thoughts on this are

maybe have some kind of wall that can stop rams then, like spikes in the ground ?

It could also be interesting to give palisade walls a heigh-factor. So that if a piece is damaged, it shrinks and becomes passable for certain units. But this would probably not play well gameplay-wise; it would make palisades less effective against cav, because the horses can jump higher than infantry or siege weapons - thus the narration logic would go against the balancing logic here. or what if palisades could stop troops for a short time, but siege rams for a longer time. clarification required; what is the meaning of "effectivenes versus siege"? it can mean that siege weapons deal more damage against pals, or that pals can stop siege weapons as mentioned above. Well, this is kind of conservative, but you might have a point. Thing is, there is no "right way" of doing it here. Con Maybe this is more about the "ram" part than the "palisades" part, after all ? Swordcav is good against it, unless ram is escorted by spears. However, i agree, because it does not feel very dynamic. It feels like "pull your troops back and pump damage into that ram or your CC is going down". Maybe add some dynamic here, like halving the ram HP, but for instance giving it a health regen for garrisoned units (which "repair" the ram), or increase the repair factor. More troop interaction with vehicles, so to speak. So that not only the defender, but also the attacker needs to somehow focus his troops on his rams. This would make them more of a factor in the overall troop movement strategy, considering the low speed of siege vehicles. where are palisades, palisade placement and damage calc at the moment? how is the handling of these things done? maybe could save time to handle as arrays, if placement logic provides that opportunity. Because a wall can (but doesn't have to) be a straight chain of one element after another. If the walls would be saved as an array of neighboring elements (which they probably are), then this check would not be costly. Problem is, that if one section of that wall were to be destroyed, the array would change, the element would be removed and the gap (in the array data structure, not the wall) might be closed (because one element of the wall was destroyed). This can have some impact exspecially for big arrays.A possible "solution" could actually also be something like the height factor suggested above, because palisade sections would not neccessarily have to be destroyed, but only damaged until "0 height". The entity itself would remain intact, but lose impact on the gameplay. Thus, the array data structure would not have to change, because there still would be an element to keep track of. Throws the question about what happens if the wall owner wanted to remove a section of his own wall. For that matter, it could make sense to have a "long palisade" and "short palisade", where the "short palisade" is for making gates etc. and the "long palisade" is for limes-like things. Might also be done for stone walls (consider athen trait of "long stone walls"). == but these are just some spontaneous thoughts on it. Maybe they can provide some inspiration for someone.

could (or might) also be interesting to have streets. exspecially as they were important to some civs, namely Romans. they loved streets and books. really. AFAIK. streets could give the AI a pathfinding method (on some civs?) and give infantry movement bonus. But probably a feature which would be useful only on larger maps. In that case, that would of course exceed the purely decorative means. although that might lead to many entities, as buildings are entities (AFAIK). thus it probably has a rat tail (no idea if this saying exists in eng) attached to it, because it might be useful to have a separate 2d-layer and separate handling for such special kind of object. Because less performance impact if it can be reduced to 2d and match the terrain in some way. In other words: i am not sure if such tiles would scale well with the current state of the engine. my guess is that it would be best to do it with a mod (if you intend to use it only for sandbox anyway..). So it sounds like you think about a singleplayer kind of scenario here. If this were to be implemented in the base game, it would pose an additional source of unexpected behaviour and maybe lag, because each tile would be handled as an entity. But i might well be wrong on that. Please note that i do appreciate the basic idea: having some kind of basic (infra-)structuring possibility in the game, be it only decorative. Although, as i mentioned, the different civs had different attitudes and uses of infrastructures, because of different natural formations, flora etc. . Little excourse: in my city, there is a street called "Pontstraße", where "Pont-" comes from the latin "pons", which refers to a bridge. Nowadays, there is only little water in the area, because it is quite urbanized by now; but long ago, the area lay outside of the city and was swampy. The romans thus built kind of a wooden bridge-road - their road system and organization was a great strength of theirs, after all! And hence originates the present name of the street. What i want to say with this: It DID play a role back then.

I agree, but how would the process of making it default start? Opening a ticket? ^^'

good point.

Or maybe smaller sanctuaries which give a stacking bonus, where you have up to 5 or so? Maybe they can have an aura, where the people would fiercly defend their sanctuary? some civ already has something like this.

The topic was discussed on the Delanda Est overhaul mod: If this feature is implemented in a good way into the mod, then it might have a good chance to get merged into the main game. Personal suggestion: Drag the mouse to move in formation, click the mouse to move without formation.

Please only imitate this company if there is no other way I still think that this is no good idea before the game scales properly. We should not spam on food before we have the wood to build houses Although it might add more interested devs or mods to the project. Maybe there is a more profound truth to your post than i cannot fully see now... But still, please don't take Micro$oft for an inspiration ugh

The game seems to have multiple workflow layers. pyrogenesis -> 0ad -> mods There is pyro engine with the simulation and basic data handling, which would be the layer for I/O optimization. Abstract stuff in here. I think it should ideally reach a somewhat stable state as the first? So that the stability can build up to the other layers. Because better simulation and performance stability = better community games = more activity on community layer (the mods for 0ad) Then, there is 0AD itself; it is much about the meshes, soundtracks, civ design, building sizes (if a space game would use pyrogenesis, it maybe had very different buildings, so that would be handled by the 0ad layer) , but also gives the basic, persistent balancing for every basic unit type. So, the game mod is kind of a.. consensual game state, which can be assumed to provide certain functionality, meshes and compatibilities. It is a common package for a community of players. In that perspective, it is more modular than the engine (generic operations and script handling, graphics rendering...), but less modular than the actual mods. That way, it allows for a greater number of players to have trust in a common gamestate and prevent OOS. Moddable game is great, but this is of course a Problem to keep track of all the versions and ensure same game behaviour between different players. p.s., i am aware that there is a "0ad" base mod within the game, but maybe it would be helpful to handle it in different layers? Engine layer should have long update cycle, game layer with medium update cycle (seasons+balancing??), and then the community-modding-layer, which is technically bleeding-edge. But there can also be some kind of release cycles, like already done. I like to compare it to arch linux and manjaro. In that way, that many people can have an better access to the grassroot kind of development (not only code!), if the changes can be locally limited. Because the fundamentals on which their modding relies (the game) provide a long-term stability. Maybe it even makes sense to have different mod formats, like .pyromap, .pyrociv etc., which can then have a stable dependency system implemented (theoretically). The Community mod is a great example in which this strength of the community-driven game is already realized! It says on the description that bleeding-edge changes are quickly added and removed. It is already a good, kind of real-time community participation (though the community might still become bigger :p and it sure will, as soon as we scaled it somehow in some ways) //EDIT4: Also consider that the different layers would have different pools of contributors. The 0ad-game can take contributions from the modding layer. Basically like a filter. But on the modular layers, we probably see the most historians, musicians, writers, translators... stuff like that. The pyro engine as the most "static" layer would take contributions mainly from devs. Not so much music in the const arrays. But (ideally, in future) these contributions could extend to other RTS who use the engine. Still in the learning of all the C++ atm. Begging pardon for maybe stupid assumptions or questions. It is not meaned to say that the engine is "too bad" or just complaining. Much effort has already be done, and probably, if we compare engine optimizations, it is much less work than all the meshes, models, voices, music, scripting, balancing, moderation, legalese etc. I just hope that more problems can be solved ! So much has already been achieved, and it would be very lovely to see it scale up to epic battles which can take the players back in history is this about the atlas editor? Concerning the files that are created by modders: maybe it is worth a thought to create user friendly toolkits for packaging mods on the long run. So that there would always be checks if the basic file stucture is correct etc. Can reduce the need to re-upload a mod and start another version for some fix of missing or wrongly placed files. When there is many people modding, then this can take some work away from the team, i imagine. //EDIT2: i am aware that there is already a command line argument to package a .pyromod. So you are most likely already aware of that fact, considering the depth of organization on wildfire games. Wait, what is the topic called? Naming poll... this is kind of off-topic. <\talk>

Which system are you on?