Leaderboard

We you could create a special actor with the field mesh and a custom template with obstruction. This way you wi have a custom obstruction object. You can set it to be only visible in atlas See the trigger markers for example.

Delenda Est has these placement obstructors, whose code may be useful to you. <?xml version="1.0" encoding="utf-8"?> <Entity> <AIProxy/> <Footprint> <Square width="38.5" depth="7.0"/> <Height>9.0</Height> </Footprint> <Obstruction> <Active>true</Active> <BlockMovement>false</BlockMovement> <BlockPathfinding>false</BlockPathfinding> <BlockFoundation>true</BlockFoundation> <BlockConstruction>true</BlockConstruction> <DeleteUponConstruction>false</DeleteUponConstruction> <DisableBlockMovement>false</DisableBlockMovement> <DisableBlockPathfinding>false</DisableBlockPathfinding> <Static width="37.0" depth="6.0"/> </Obstruction> <Ownership/> <Position> <Altitude>0</Altitude> <Anchor>upright</Anchor> <Floating>false</Floating> <FloatDepth>0.0</FloatDepth> <TurnRate>6.0</TurnRate> </Position> <Selectable> <Overlay> <Outline> <LineTexture>outline_border.png</LineTexture> <LineTextureMask>outline_border_mask.png</LineTextureMask> <LineThickness>0.4</LineThickness> </Outline> </Overlay> </Selectable> <Visibility> <RetainInFog>true</RetainInFog> <AlwaysVisible>false</AlwaysVisible> <Corpse>false</Corpse> <Preview>false</Preview> </Visibility> <VisualActor> <Actor>structures/hellenes/wall_long.xml</Actor> <SilhouetteDisplay>false</SilhouetteDisplay> <SilhouetteOccluder>false</SilhouetteOccluder> <VisibleInAtlasOnly>true</VisibleInAtlasOnly> </VisualActor> </Entity>

Have you tried using custom special filters, haven't tried myself but should be able to expand the template of the entity you want to have the effect applied without template duplication. Here is an example I did for a map where i wanted to make the a wonder ungarrisonable https://code.wildfiregames.com/D1634 the file in question is binaries/data/mods/public/simulation/templates/special/filter/disableGarrisonHolder.xml so should be similar for your case

Sure but it should instead be a barrier shape or something using a field sounds a bit hacky

@hyperion, you're right, commits such as 15713 or 19095 ought to be avoided. On the other hand, committing every single modification separately is undesirable too. Where to draw the line is always a bit arbitrary. D2493, D2494, D2495 affect the same entities; I did it in three because each of those can make sense on its own (or not) and can be implemented indepently. D2494 removes splash attacks and raises default damage of artillery, but having one patch removing splash attacks and another raising default damage is not really an improvement, these changes make much more sense together than they do separately. Likewise, the <PreferredClasses> changes are because of the damage changes. You have a point that the summary does not really explain why the patch is as it is. I'll rewrite the summary to be more argumentative rather than descriptive. One problem is that the actual splash damage inflicted depends not just on the splash radius, but also on the distance from the centre of the entity hit; because structures (and warships) tend to have long footprints (longer than the splash radius), they don't take any splash damage in practice. Also, the AI does not seem able to take splash damage into account. Another issue is that ancient missiles were not exploding shells; splash damage is anachronistic. To be clear, I'm certainly not arguing to remove the mechanic. I'm actually in favour of having a cheat unit that has a splash attack (perhaps a mortar; or some Greek fire, or the dragon?). Anyway, this discussion is getting quite specific. Could we please continue it over there on phabricator ( https://code.wildfiregames.com/D2494 ), where the actual review is supposed to take place?

I like splash damage and I feel like it's an intereating mechanic that should be kept and not be put in the trash. Sadly I don't have more reasonable arguments for it. I do feel like "hard to understand" is not a good argument, too.

Cool. Good to know! Thank you for swift reply

There are issues with the possibilities of cheating, the game is open source, so with enough technical knowledge, you can run a custom game client that gives you unfair advantage such as by implementing automatic troops micromanagement or to exploit the latency-compensation mechanism. Also, the network code, from my understanding is written in such a way that every player simulates the whole map, so that means that a cheater can remove fog of war and see what other players are doing. Cheaters won't be able to alter unit stats, that will get them out-of-sync. But I don't think these should prevent one from running a competitive gaming scene. Sportsmanship and some level of trust is necessary, and you can't always rule out every form of cheating in any game. This is not unique to 0AD, even commercial games have exactly the same problems to varying degree. Just don't make the prize pool so large that people becomes monetarily motivated to cheat, and action reported cheaters promptly. If you want to run a competitive scene with large monetary sums, you will need to run an offline competition, so that you can control the gaming machines and ensure that players can only use an unmodified version of the game. (actually, I suspect that if you actually try to deliberately make cheating hard and try to implement various rules to make cheating hard, that will probably just invite people who would cheat just to show you wrong; so you either has to go all the way to prove that they're wrong, or rely on sportsmanship)

Being open source is not an issue, you can have end-to-end security even with source code available. Given enough eyes, it's arguably more secure. The problem is just time and dedication to it, which needs to be invested in more important areas (e.g. performance, features, balance etc).

Completely agree. The only questionable thing we find in a few mods is the code that removes the mod itself from the list of enabled mods. Players should be aware that their opponent is using autociv or any other mod (in theory: as I said, they can't know if their opponent changed the code locally).