can attack air units with melee ground units

[Platyhelminth]

inruin in IRC noticed that ground melee units (like the swordman) can attack air units (like the ornithoptere). I successfuly reproduced that "bug".

I don't think it is a wanted feature ...

I used glest data 3.1.2 with GAE 0.2.11 and fpm faction 0.1.9 .

[Omega]

They shouldn't be able to attack anything unless the field allows them to. Mayb e magitech was modded?

[Inruin]

It's definitely a bug.  I'm looking at the XML file and the fields are fine and how they should be.  The swordman says "land" only and is still able to attack aerial units.

[silnarm]

It's definitely a bug.

I prefer the term 'undocumented feature' 
Thanks for the report, we'll look into it.

[Omega]

I prefer the term 'undocumented feature' 

ROFL!

That is weird. Does it happen on vanilla glest too?

[Inruin]

I recall an instance where I had a flying unit and the AI had Swordman units but wouldn't attack my air unit.  I think it's obeying the attack field from an AI standpoint, but if you tell a unit to directly attack the other, it will work no matter what.

[silnarm]

Fixed in revision 131.

I fixed it once, reverted, and then fixed it better... I think I got it right

[Omega]

That's odd, I've tried that and nothing. No attack... Could be an OS thing (are you linux?) or something... Dunno, but I've never been able to attack even if I tell the unit to.

But if silnarm fixed it, I guess it was broke. Where?

[silnarm]

All the checks were there, but if you explicitly targeted one unit, those checks were bypassed and you could indeed attack anything... The AI obeyed the rules, your own units on auto commands or 'attack move' commands would obey them, but if you attack a specific unit, the attack-fields were not checked.

[Omega]

Really? Then why could I still not attack air with my swordsman? Hmm, I wonder if its OS specific? Regardless, it's fixed, so this topic seems solved.

[Platyhelminth]

Inruin used windows and I used linux. so it is not OS specific.

But for sure, when daniel santos will fix multiplayer he will add secret features to linux users .

[Omega]

But for sure, when daniel santos will fix multiplayer he will add secret features to linux users .

Don't be a jackass!

Besides, that's impossible, being open source.

BTW: I f wondering why I used the 'harsh' term jackass, I would recommend looking up corner gas, a Saskatchewan filmed comedy, and a good one at that! One character, Oscar, loves to use jackass sometimes in episodes.

SOUND BITE:
Oscar: (Talking on phone, wrong number, slams it)
Emma: Who was that?
Oscar: I don't know, some jackass!

[Platyhelminth]

The vanilla glest, which works in multiplayer, needs that everybody share the same binary and operating system (see: https://forum.megaglest.org/index.php?topic=4277.0 and wine won't help you ... ). Even if 2 binaries are made in the same system with the same options, they will not work together (some people had tested it in past).

If GAE fix that problem that would mean that differrent binaries will work together. So due to the fact that the game is open source, someone may implement a cheat directly in his code and make his own binary. Binary that may not be rejected by other in multiplayer (like unlocking fog of war without being detected).

So when this problem will be fixed, cheat in multiplayer may be easyer.

[Omega]

Fortunately, most of the people we can play against we can trust.

Simple solution: don't change the binary check! Of course, that isn't the best idea. Which is why we can have a toggle on/off thingy. Defaultly we would be able to multiplayer against anyone, regardless of binaries. However, people concerned about cheating, crashes, version differences, etc; can toggle it so they can only challenge the same OS and binary. Windows is actually recommended, since it is very rare to see computers without a pre-installed OS these days, and many things are limited to windows, though many linux programs should have much trouble on windows. Not to mention that most of the big posters on the glest board use windows or at least have it available to use.

[Heretik]

The server must be the only one to have the whole kwoledge of the map. Clients must only know what the player must know. So in the example of the fog of war, the server must never send to the client any data any portions of map which are in the fog of war. And that's the same for the rest. I don't know how this is coded in Glest, but if it's not designed like this, it's most probably buggy and should be fixed.

So if any cheating is possible, it's on the server side, not on the client side. Then we can play on servers that we trust.

No, windows is not and should never be "recommended" ! Not only Glest is a Free software so in this spirit must work at best on Free OS. And second point, I'm not sure most people on this forum use windows. At least on Glest IRC room, where we currently find players to play over the internet, nearly all people use GNU/Linux. So, Glest works on linux and windows, just keep it like this.

[Platyhelminth]

omega; download GAE 0.2.11 code , then watch the file /source/shared_lib/sources/xml/xml_parser.cpp .

At the line 31, you will read someting very interressant.

[silnarm]

The server must be the only one to have the whole kwoledge of the map. Clients must only know what the player must know. So in the example of the fog of war, the server must never send to the client any data any portions of map which are in the fog of war. And that's the same for the rest. I don't know how this is coded in Glest, but if it's not designed like this, it's most probably buggy and should be fixed.

So if any cheating is possible, it's on the server side, not on the client side. Then we can play on servers that we trust.

While this would be ideal to solve the cheating problem, it is I think somewhat impractical due to the massive increase in network traffic required to make it work, as opposed to running two simulations that are assumed to be 'in sync' (reducing traffic to just the unit commands essentially) and just forcing the issue everyone in a while ('re-syncing' by the server sending a 'full update' periodically).

The ORTS project uses a Server/Client system like that though... I don't know how well it works, but if it works for them... I guess it may be feasible. I'm not at all familiar with Glest's networking code yet though... so I shouldn't be commenting so much on this one

At the line 31, you will read someting very interressant.

I suspect you may find few more lines like that in the source, if you looked hard enough   I think I've even added one or two along those lines myself, I'd imagine that this is quite common for cross-platform projects