sternstaub

That is interesting, because for me it says "&p hat die Großstadtphase erreicht"

agree. please do not jump on the anti hate speech train, for it can head to the wrong direction easily! People are always free to dislike others in non-violent ways. That is my belief. In a community of overviewable size such as 0ad, toxic players will just be disliked by others and at some point, not many will play with them. Regarding the hitler_appreciator account: This is more about the general topic of creating smurfs, and how to address it. Imo makes sense to use some kind of trust system for accounts. Gain trust points for using the account on lobby and give hosts the option to threshold required trust to a minimum value, hence filtering new accounts and smurfs. Could be realized via bot, like the ratings (trust only affect lobby matches). This way, the WFG team does not have to become the guardians of hatespeech, because the hosts can themselves filter new smurf accounts (aswell as new players, that has to be considered) and kick known toxic players.

it is described here

Hello everyone since there seems to be no topic for this yet, i wondered if implementing / using GNUnet for decentralization was ever considered for pyrogenesis. Maybe as additional connection method. If not so: what do you think about it? Does it make sense? i always like to empower decentralized concepts by using them.

Stupid question, but how can i get started on making models?

It would be possible to reduce health and give base health regeneration so that the unit only dies when focused. But that is not really an realistic approach.

@zxphxri am also trying hard to use corral at the time, with mediocre results, as can be seen on the food res... remark that you were fighting my army at my temple and in the range of 3 towers, fortress and CC in the end and that this was the spot in which i wanted to fight. at the moment i am trying to figure out ways to build defensive bases against rushes. probably expands the building phase for the town too long. happy and surprised because me=not an experienced player at all, and it would have been so sad to lose 2vs1. plus, we did not attack you to win, which felt kind of weird you gave us a hard time nonetheless, your food eco is running better (for reasons stated in the video, among others); GG

For multiplayer, each client must get the same result for the same operation iirc. It is a deterministic game. Still each client has to get the same result for a particular action taken. Else OOS.

Randomization is against the game design.

Troops can be garrisoned into some rams. Could be used to protect it.

Is there such a system already? I mean, slaves in general.

that one was really cool indeed.

did a test a few days ago, latest git. Here are the bugs which i encountered: On game start for a brief time, looks like this: The first time i place a field blueprint, it looks like this for a brief time: On the field blueprint, there are black artifacts. They are not visible on built fields however. Another error - missing model_water -, but the file seems to be in the spirv-mod: building a marvel causes this (black box only initially aswell): userreport_hwdetect.txt

Hmm. It is true; adding such will not remove micro, but rather refine it. you can always argue that a game becomes easier if it gets more user friendy. but also, this gives the opportunity to add other challenges to the game, which are more immersive than dancing with units. Imagine a centurion reporting: "...i beat them by having my legionaires dance from the left to the right at the moment their archers fired!". Ah, i do not know. It is true that 0ad is a game and not a 100% accurate realistic simulation. But it is not supposed to be a click-o-mat either.

sounds like having battallions (= fixed group) and formations?

disclaimer: writer not very familiar with current implementation. 1) separate the formation from actual unit position; make units behave around this fictional formation. these are like little flags in the ground with "unit IDs" on it (being pictural here) this can provide a useful set of data. would be possible for example to get n rows from either flank and break them out to perform a flank attack. Also gives an option to make formation movement calculation cache friendly. the interesting part here would be by which patterns units can be selected from a formation, like "select middle row" or "select the 4 left columns". This can be used for very intuitive user interfacing. This array of flags should be dynamic and change when units die. some unpleasant effects should be accounted for in that case. for example a unit from the left side of the formation might be placed to the right side and then start walking there, costing dps. that kind of stuff should be avoided. hence, maybe only remove the flags without auto regrouping the formation. maybe not. hard to say now. 2) as suggested elsewhere, use mouse draw to make things intuitive for user. plus, it gives more controls which can be assigned to the implementation of some fancy movements - whichever these may be in the end. there already is the unit selection which uses mouse drawing, so the mouse draw operation is already implemented somewhere i guess? (i would suggest the same for pings, by the way, but that is a different topic) 3) differentiate between attack formations and standing down / holding ground tight and loose/attack/move formations. -> different formation categories i. attack loose/attack/move formations would not neccessarily need such flag formations (->1), because the attack occurs only once. i would rather call it "attack move (formation)" instead of "attack formation". it might make sense to give a maximum range for an attack move, so that unit groups must first be set up at the battlefield. This is kind of a coreography for the units. The coreography stops as the unit is engaged into the combat, then it attacks the closest enemy. maybe i am thinking too much about cavalry charges here. A line or square formation or a shield wall can of course also offensivley move towards an enemy. Maybe it makes more sense to differentiate between tight and loose formations? ii. standing down using tight formations would spawn a formation (->1) in a certain place, and units stick tight to the formation when they are attacked. They do not wander off for more than a certain radius from their spot. iii. an idea would also be to have units lose the formation (->1) after some time. This would force the commander to perform regroups. additional factors like morale can be taken into account. certain civs could be stronger at holding tight formations, while other are better at attack move (formation). the former meaning better defensive gameplay, the latter meaning the opposite. 4) the ability to merge different unit groups into one formation temporarily can also be interesting. you want your archers to stand behind your melees, but when the line is failing, you want the archers to run first - without disbanding the whole formation. So wait, the formation itself is a temporary container of pointers to units, kind of. if unit is losing formation, that spot in the formation can be set to nullptr. the duration of the different formations (or of how long different units retain their formations) may vary. some input, more to come. more: maybe give capture points to formations like buildings, and add cooldown to reform? where a flank attack does more damage to the formation and sets single soldiers on "flee" for a short time?

Why should those be exclusive? We already have different meta with community mod. Problem is that joining a modded game can be tedious (it is relatively easy if mod is on mod.io), and it takes time. No long time, but some time. Why talk about mod changing for different games here? Well, because i think that both sides do have their points. Furthermore, the modularity of the game can be of great use on the matter. I already argued that for community mod in the past. Simplifying the exchange of currently used "modset" can be a way to prevent split in community (bad) while using the strength of modular game concept to try out many ideas simultaneously. Please be aware that my point here is about disparities in the community. From my experience, growing communities can develop such splits, which So, while the community mod is a "single split", so to speak, this is not really a problem imo. Yekaterina mentioned on another discussion that it also filters out "cosmic nubs". I am certain that we can achieve that filtering in other ways just as well, if there were no more "modding-splits". To be clear here, i do not think that the current system is bad or something. It is already a comparably simple and pleasantly straightforward process to change mods and add new ones. However, there is a tendency not to join the grayed out games, or not to see them at all, unless there are no other games specified. I think that it would be great if players would tend to use multiple mods and thus having to be smart about their play, think about what the consequences of the given rule-deviations are. For example, i play a vanilla game where CC cost 500, right afterwards i play a community mod game, where it is cheaper to build. That changes the frame within which the player would have to strategize. In fact, there already is the possibility to manipulate that frame already. Each lobby has it's own rules, relatively simple values which can affect game experience on a big scale. 8p small map 50pop low res is different than 2p big map wonder win high res 300pop. No need to argue that. But would it not be possible to extend the lobby rules and give the host more options? All the unit values of registered units (on host machine) could be manipulated. Since these values should be const during the simulation, it might make sense to set these up on lobby creation, so that they are handled like the game name or STUN. It can be set once, and not changed in the lobby iirc, @Stan` mentioned in another topic that the projectile speed cannot be adjusted by mods. So, given that there was a system for silently changing mods (or maybe rulesets? certain kinds of mods? plugins?), we would also have to assume that these mods which can silently be loaded / unloaded only affect. Therefore, with such a solution we would have two kinds of disparities. 1) disparities about different balance values of units, res cost, health, acceleration... could be addressed by the hosts easily 2) disparities about gameplay must still be discussed in forum and can affect the engine, or things that cannot be changed by mods. The question may well be asked whether this can make the overall multiplayer experience more confusing, because you need to look at many different values and compare them (you know, think very hard all the time etc.). It would thus be advisable to have a default value for each unit (makes sense, since these values do exist and will keep existing), and that each lobby will only point out the value changes which are made for the game. If this were to be realized, that can certainly be considered a formidable task. And it is quite a generalization of the original proposal of this topic. Anyway, it could prove as a fertilizing feature to the community grassroot power, because many different things can be tried out simultaneously, without changing mod and restarting client each time. Altough it is only little effort to do this, we all know how human beings tend to behave. Although the game already belittles the complication to perform such change to a triviality, it still requires some effort. ps: even if i talk about very general things sometimes, please take this not as an offence towars the things which have been already accomplished. Many things work very well, and this suggestion is merely intended to inspire a general direction for the future.

The mod.json has "ignoreInCompatibilityChecks": true ; nice.

Looks very helpful indeed Can it be used in multiplayer without the host having the mod?

Hi, i use a vpn too and they say that they have If you want to try it out, i can let you partake on my vpn plan and you can see if it works. PM me ps: cannot fix font size in quote it is a bit big sorry

Could you give ticket name or id please?

Okay so that's now changed that to say "Python 3" instead. If any change is not ok, i change back. Wanted reassurance not to break anything or change the wiki text with wrong Information.

It says under requirements: Python 2.7 (required for cxxtest and non-system SpiderMonkey) - so that is outdated too?

Then there is no problem to be solved here. ?

If it is done on installation and the user can assume that the installation file is trustworthy, you would only have to link once. Meaning that the possible exploit is limited to a time frame of installation. Never thought about this, but is there no way of prompting a UNIX user for such operations? Or use sudo for that single operation? Something of that sorts. Once there is a link to the replay DIR, no further w/access would be needed.