MegaGlest Forum
MegaGlest => Bug reports => Topic started by: tomreyn on 14 September 2012, 00:35:35
-
While it only happens sometimes (but often enough to spoil the fun), when you right-click on enemy units in order to attack them, it can happen that you units do not attack the enemy but just walk towards them, and get slain. That's a pretty annoying behaviour, even though it happens only a couple times in every game.
Unfortunately I do not know how to reproduce this. This issue is an oldtimer, though, it's been around for several versions. On svn head, when this happens, you see that the 'walk to' indicator (a green circle around the enemy unit, I think) is drawn by the time you click, instead of the 'attack' indicator (red circle around enemy unit, IIRC).
It would be great if it was possible to identify and get rid of this issue which can result in loosing games (it's happened to me).
-
This can only happen if the unit is not detected as selected and therefore the unit is told to move to that cell. Without some kind of reproducible steps this may be very difficult to fix.
If there is an opengl problem using the selection buffer (on svn head) I DO output an error to the console (perhaps this is occuring in some cases??):
GLint renderModeResult = glRenderMode(GL_SELECT);
if(renderModeResult < 0) {
const char *errorString= reinterpret_cast<const char*>(gluErrorString(renderModeResult));
char szBuf[4096]="";
sprintf(szBuf,"OpenGL error #%d [0x%X] : [%s] at file: [%s], line: %d",renderModeResult,renderModeResult,errorString,extractFileFromDirectoryPath(__FILE__).c_str(),__LINE__);
printf("%s\n",szBuf);
}
-
Thanks for looking into it.
Sadly I could not tell how to reproduce it, since it happens with different factions and different units, both attacking and as targets of attacks. It's not too hard to reproduce it, though, if you play two games and keep it in mind I'm pretty sure you will run into it. I see how this wouldn't help fixing it, though.
I've never come across the error message the code you quoted produces, and - on SVN head - I always start the game from a terminal, so unless this output is limited to --verbose or requires DebugMode (I assume that's not the case) then I don't think this is what's happening.
I had discussed this issue with Titi before I posted, and he is aware of it, too. And then he uses different video drivers (proprietary Nvidia ones) than I (open source ATI ones) do, so it would not seem to be a driver / Mesa issue.
-
Any new info on this bug?
-
beside the fact that it still happens no.
-
Yes this still happens (whether using glselectbuf or color picking), and I don't have any additional info available (not sure how I would go about generating any).
-
Let me know if this still happens with color picking enabled in the current svn build.
-
I've not noticed it happening since I switched to ColorPicking - but I may be so used to it by now that I just don't realise it anymore. I will try to be ore attentive next time I'll play a network game.
Since ColorPicking is now the default configuration in current development builds (at least since r4034), other peoples' reports on whether you still see this issue there would be appreciated, too.
-
Unfortunately this still happens on r4032 (that's the client version in a network game on a 3.7.1 host).
-
I think this happens because you're not actually clicking on the enemy units but rather on the ground below them. For example, I have found that it can be difficult to click on snakes, because their models don't take up a lot of space. I believe (from my experience, I haven't read the source) that the current method of selection is that a unit is selected if the cursor or selection box intersects part of its model.
I think a related bug is that you can select multiple (of your own) units in one click if your camera is positioned correctly and color picking is disabled, because you click "through" the unit closer to the camera. If color picking is on you'll only select one of the overlapping units, though it is not always the top one.
-
i must say, that I cannot remember that i ever mentioned that behaviour as a bug. I am mostly on windows.
But nowadays there are lots of issues.. see at https://forum.megaglest.org/index.php?topic=8855.0 (https://forum.megaglest.org/index.php?topic=8855.0)
-
For me, this issue persists in r4036.
Ctz can be right in that this issue is related to not clicking exactly on the model (it's hard to tell, since it's not always easy to hit the model when clicking). I guess it would thus be better if a right-click would do the same as selecting the primary attack command (using the GUI) and then left clicking on a map position, i.e. right-clicking should be registered to the cell, not the model.
-
Try out 4037
-
Generally i would love glest to be a little toleranter in clicking of moving units. Often its really impossible to doubleclick troups on the run because you cant hit the sweetspot twice on one unit.
maybe its possible to make the second click of a double click independent from its position?
Greets
-
Actually now, having run into the issue again in a few games, I don't think this is because you fail to hit the model. I can click on the same target once, and units walk there, and click again without moving the mouse a single pixel (and without the target unit moving) and it becomes an attack. So this rather seems to be a timing issue or similar.
And it still happens on r4041...
-
Hopefully the latest svn improves this now?
-
I haven't run into this lately. Let's consider it fixed until it turns out otherwise (in which case I'll report back).
Thanks for your work!
-
Sadly it happened again on recent SVN recisions (the last one I saw this on is r4083). There will always be some delay before I can report it happening in a given new revision because I'm sure used to this defect that I tend to not notice it, but then it strikes me badly at once because I loose a lot of valuable troops this way.
-
Still happens on r4126 with color picking.
-
Still happens on r4246 with color picking, but it seems to be unrelated to the selection mode. Titi has also reported this to happen to him in personal chat.
-
Please retest this on rev 4300
-
It still happens on r4306.