Bugs and feature requests

[tomreyn]

Here's a couple of bugs and feature requests, based on 3.3.5 beta 3, using the binary 32bit linux builds on ubuntu lucid (10.04) x86_64 (Linux 2.6.32).

Bugs:
* Only one CPU seems to get used
* Games get out of sync (no error message) with many players (this can be related to mixed Windows/Linux games): while some players see something happening, others only see the same thing delayed by several minutes. Once it seemed like those different parties actually saw different endings for the same game.
* Possibly related: in a multi-player game with several linux and windows players, it took several minutes for my units to actually recact to a given command. For example, when I ordered cutting trees, this was only taken on 3 to 5 minutes later. Once it started this happened continuously and lasted until the end of the game, but the delay decreased towards the end of the game.
* The default key binding (glestkeys.ini) for ResetCameraMode is "32". This is probably a typo?

Feature requests:
* Please provide a dedicated (CLI only) server so we can run game servers on well connected dedicated servers in data centers.
* Please improve graphics performance (if possible). I use an Intel i915 based chipset (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)) which explains bad graphics performance - but it should not be that bad. It is actually ok when playing alone with multiple computer players ('CPU') but it becomes unbearable on network games with multiple players. I can hardly point and click then, just guess (where the mouse pointer will show up next) and click.
* Please make in-game chat colors represent the users' color.
* Please indicate, textually, for each unit which player it belongs to.

[ultifd]

First of all, as you know, and since I already told you, this bug section is for Vanilla Glest really...oh though that doesn't make much sense, it is what it is. (So, can a moderator or admin move this...?)
Out of sync: Everyone who tests, know that already, but thanks for pointing that out...I gues.

it took several minutes for my units to actually recact to a given command. For example, when I ordered cutting trees, this was only taken on 3 to 5 minutes later.

That is more related to your connection, not out of sync.  Believe me, I would know... Because sometimes I have a bad connection...so...yeah.

* Please provide a dedicated (CLI only) server so we can run game servers on well connected dedicated servers in data centers.

Hmm, possible, later, but do you have $$$? 

* Please improve graphics performance...

I would see why but...

but it should not be that bad...

If this happens again and again, like after they release a stable version...then we can talk about that I guess. 

* Please make in-game chat colors represent the users' color.

As I said in the IRC Channel, that is not a very good idea, as if people have bad colors as their "color..."then it would be...bad...and for the eyes.  I guess if they do implement this, as you said, make it optionable...

* Please indicate, textually, for each unit which player it belongs to.

I would see why...maybe later...again, not so good for the eyes, optionable if implemented...again. 
-----------------------------------------------------------------------------------------------
This is kinda a good example of what we were talking about about requests... 
Sorry if I seem like I am attacking you(how?  )...

Thanks.... 

[John.d.h]

Feature requests:
* Please provide a dedicated (CLI only) server so we can run game servers on well connected dedicated servers in data centers.

Considering Glest is a community-driven game, that's only happening if somebody has a spare server or something.

* Please improve graphics performance (if possible). I use an Intel i915 based chipset (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)) which explains bad graphics performance - but it should not be that bad. It is actually ok when playing alone with multiple computer players ('CPU') but it becomes unbearable on network games with multiple players. I can hardly point and click then, just guess (where the mouse pointer will show up next) and click.

We've been wanting a good graphics coder for a while.  No such luck yet.

* Please indicate, textually, for each unit which player it belongs to.

I can see how that would be good for accessibility.  Something like 6% of men have some kind of colorblindness.  It should definitely be toggle-able (and turned off by default), though.  I'm sure the majority of people would find it annoying.

[tomreyn]

First of all, as you know, and since I already told you, this bug section is for Vanilla Glest really...oh though that doesn't make much sense, it is what it is. (So, can a moderator or admin move this...?)

Yes, I know this is the wrong forum since you told me on IRC after I posted my initial post here. Thanks to have made me aware here, and thanks in advance to the moderators if they will move it to a more suitable place. Unfortunately the distinction between the various softwares/forks/mods is not at all obvious on these forums, at least not to me. And I would still not know where my post would have belonged. The softare I am referring to in my initial post (and also this post) is MegaGlest as found at http://sourceforge.net/projects/megaglest/

Out of sync: Everyone who tests, know that already, but thanks for pointing that out...I gues.

In software development, it can sometimes help to have multiple reports for the same issue, since those can differ slightly, or issues which look similar on first sight are actually two or more separate issues.

it took several minutes for my units to actually recact to a given command. For example, when I ordered cutting trees, this was only taken on 3 to 5 minutes later.

That is more related to your connection, not out of sync.  Believe me, I would know... Because sometimes I have a bad connection...so...yeah.

Right, this can be related to connectivity issues. However, my ADSL connection doesn't cause latencies of 3 to 5 minutes (plain TCP packets would long have times out then). So while latency may be a contributing and/or triggering factor, this seems to point out a bug or unintended bahaviour in the game.

* Please provide a dedicated (CLI only) server so we can run game servers on well connected dedicated servers in data centers.

Hmm, possible, later, but do you have $$$? 

As before, this statement seems to be driven by the level of expertise you have gained in software engineering so far. I believe a dedicated server would actually be beneficial to the intentions of the developers since it allows for better debugging (more games, less resource consumption, larger games, more users, more logs, more unexpected situations/errors/warnings, possibly direct developer access to log files or even automated processing of log files). Of course, it's up to the developers to decide whether they have the time to spend on this feature or not. I assume it will not mean extremely much additional time since much if not most of the existing code will be reusable. But let's have the developers decide on this one, since only they are qualified to do so (hint!).

* Please improve graphics performance...

I would see why but...

but it should not be that bad...

If this happens again and again, like after they release a stable version...then we can talk about that I guess. 

"We"? You mean like you and I? Are you suggesting you'll be programming the OpenGL improvements (threading and the like) then? Great, I'm looking forward to see your code!

* Please make in-game chat colors represent the users' color.

As I said in the IRC Channel, that is not a very good idea, as if people have bad colors as their "color..."then it would be...bad...and for the eyes.  I guess if they do implement this, as you said, make it optionable...

I think that's a good point, it should be an option.

* Please indicate, textually, for each unit which player it belongs to.

I would see why...maybe later...again, not so good for the eyes, optionable if implemented...again. 

Of course this could be an option, too.. It has often happened to me that i was unaware whether a given unit is mine or that of another player. My goal there is a better visual distincition. This can be achieved by this or by other methods, it sure would help me though.

This is kinda a good example of what we were talking about about requests... 

I do not understand this comment, since I seem to be lacking context. Also, who is 'we' in this case?

Sorry if I seem like I am attacking you(how?  )...

While this can be my personal impression, you seem to pick a condescending / precocious tone at times. It is obvious that someone using (and contributing to) the software longer (you) than someone else (I and others) has a different experience level regarding this very software. It does not, however, imply that those latter people are technically or socially inept.

Thank you for your suggestions, I am convinced your very interest is to support this project and I think that's a good intention.

[tomreyn]

Feature requests:
* Please provide a dedicated (CLI only) server so we can run game servers on well connected dedicated servers in data centers.

Considering Glest is a community-driven game, that's only happening if somebody has a spare server or something.

Of course. And I would run a virtual MegaGlest game server for a while if a CLI-only server was made available. I'd happily set it up with direct logfile access for developers, also shell access if needed for log file monitoring/processing.

* Please improve graphics performance (if possible). I use an Intel i915 based chipset (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)) which explains bad graphics performance - but it should not be that bad. It is actually ok when playing alone with multiple computer players ('CPU') but it becomes unbearable on network games with multiple players. I can hardly point and click then, just guess (where the mouse pointer will show up next) and click.

We've been wanting a good graphics coder for a while.  No such luck yet.

I imagine this can be an issue - that's a pity.

* Please indicate, textually, for each unit which player it belongs to.

I can see how that would be good for accessibility.  Something like 6% of men have some kind of colorblindness.  It should definitely be toggle-able (and turned off by default), though.  I'm sure the majority of people would find it annoying.
[/quote][/quote]

I must admit I had not actually thought of colorblindness there, but it sure would help in this case. I'd personally like it for the reason I provided in my previous post on this thread (so I'll just repeat it):

It has often happened to me that i was unaware whether a given unit is mine or that of another player. My goal there is a better visual distincition. This can be achieved by this or by other methods, it sure would help me though.

[ultifd]

Unfortunately the distinction between the various softwares/forks/mods is not at all obvious on these forums, at least not to me. And I would still not know where my post would have belonged.

Yeah, if I were you, then I would have posted my requests and bug "reports" too in this board... 

In software development, it can sometimes help to have multiple reports for the same issue, since those can differ slightly, or issues which look similar on first sight are actually two or more separate issues.

Yes, I know that and understand that. But mainly, for this particular issue, they have been the same problems... most of them, at least.  ... Also, we have been testing and seeing these out of sync issues for a long time...and it was always out of sync before megaglest, BTW... Still, you are correct. 

Right, this can be related to connectivity issues. However, my ADSL connection doesn't cause latencies of 3 to 5 minutes (plain TCP packets would long have times out then). So while latency may be a contributing and/or triggering factor, this seems to point out a bug or unintended behavior in the game.

Yes, I think it can be  a....well rather is a "half/half" issue...or 75 to 25....I think we as in the testers, and (probably...) the developers will look into this more...but as you know, the out of sync issues is the main "issue" of megaglest right now.

As before, this statement seems to be driven by the level of expertise you have gained in software engineering so far. I believe a dedicated server would actually be beneficial to the intentions of the developers since it allows for better debugging (more games, less resource consumption, larger games, more users, more logs, more unexpected situations/errors/warnings, possibly direct developer access to log files or even automated processing of log files). Of course, it's up to the developers to decide whether they have the time to spend on this feature or not. I assume it will not mean extremely much additional time since much if not most of the existing code will be reusable. But let's have the developers decide on this one, since only they are qualified to do so (hint!).

I understand that, of course it is beneficial...but you need to understand that (and you probably already do, still)
that it takes more then...well...nevermind, we'll see. But the Glest Team has agreed to become one..sort of...we'll see.  ...

"We"? You mean like you and I? Are you suggesting you'll be programming the OpenGL improvements (threading and the like) then? Great, I'm looking forward to see your code!

We as in all of us testers, developers, and such. So that wasn't what I meant... Anyways, now, we, will all see, later, like everything else in this community.

It has often happened to me that i was unaware whether a given unit is mine or that of another player. My goal there is a better visual distinction. This can be achieved by this or by other methods, it sure would help me though.

Well, I can usually understand which units are mines and which are my allies...and opponents I guess.
Yes, it would be helpful, and there are sometimes when it may be hard to tell apart...but like you said, probably a better way would be...better...and helpful too. 

I do not understand this comment, since I seem to be lacking context. Also, who is 'we' in this case?

We=Glest Community, Generally...
I was talking about this... https://forum.megaglest.org/index.php?topic=5581.0
But, this time, your topic is good, compared to the hundreds(somewhat) of similar threads...

While this can be my personal impression, you seem to pick a condescending / precocious tone at times.

Yes, I am sorry when I seem like that, or when I am like that.

It is obvious that someone using (and contributing to) the software longer (you) than someone else (I and others) has a different experience level regarding this very software. It does not, however, imply that those latter people are technically or socially inept.

Yes, I agree with you.

Thank you for your suggestions, I am convinced your very interest is to support this project and I think that's a good intention

No problem.
Yes, they are.  They are sometime just...well...not maybe understandable? misunderstand-ble?  ...

Thanks, again. 

[tomreyn]

@ultifd: Thanks for your friendly reply. We seem to agree on most topics, that's nice. As such, and since you did not explicitly ask for it, I'm not responding to your individual statements this time (let me know if you think differently).

There's this reply of you, though, which I just can't make anything out of:

As before, this statement seems to be driven by the level of expertise you have gained in software engineering so far. I believe a dedicated server would actually be beneficial to the intentions of the developers since it allows for better debugging (more games, less resource consumption, larger games, more users, more logs, more unexpected situations/errors/warnings, possibly direct developer access to log files or even automated processing of log files). Of course, it's up to the developers to decide whether they have the time to spend on this feature or not. I assume it will not mean extremely much additional time since much if not most of the existing code will be reusable. But let's have the developers decide on this one, since only they are qualified to do so (hint!).

I understand that, of course it is beneficial...but you need to understand that (and you probably already do, still)
that it takes more then...well...nevermind, we'll see. But the Glest Team has agreed to become one..sort of...we'll see.  ...

If you could just re-read this sentence, it will probably become obvious that there's no way for me to understand what you are talking about (aside from the first statement where you agree it's beneficial). You seem to want to say something but at the same holding back any info on it which would have allowed me to understand what you are referring to. So: here's another chance to either say what you wanted to say or just not say it, both is totally fine with me. ;-)

[softcoder]

Hello Tomreyn and others.

Bug Replies:

* Only one CPU seems to get used

Answer:
Currently we recently introduced threads for some things in mega-glest. Its is not very likely that we will use threads for graphics processing. Why? Having read material from ATI/NVidia and talking to pro's in the game industry, threads typically add more overhead than gain when it comes to current graphics frameworks (like openGL which strongly discourage using threads). We are focussing on network transport to be done in threads as it seems to give the best gain at the moment.

* Games get out of sync (no error message) with many players (this can be related to mixed Windows/Linux games): while some players see something happening, others only see the same thing delayed by several minutes. Once it seemed like those different parties actually saw different endings for the same game.

Answer: Yes we are working on reported cases as best as we can. This is one reason for introducing "Server Controlled AI" as it may prove more stable if we cannot find all the other issues.

* Possibly related: in a multi-player game with several linux and windows players, it took several minutes for my units to actually recact to a given command. For example, when I ordered cutting trees, this was only taken on 3 to 5 minutes later. Once it started this happened continuously and lasted until the end of the game, but the delay decreased towards the end of the game.

Answer: There was one network related problem that was fixed in beta5. It is possible that you had a lot of lag on your network connection or that the server was lagging.

* The default key binding (glestkeys.ini) for ResetCameraMode is "32". This is probably a typo?

Answer: This is not a typo, just a more readable version of the SPACEBAR character (its integer value is 32)

Feature requests:
* Please provide a dedicated (CLI only) server so we can run game servers on well connected dedicated servers in data centers.

Answer: This is lower priority at the moment, perhaps we will get there eventually but for now we are aiming for stability.

* Please improve graphics performance (if possible). I use an Intel i915 based chipset (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)) which explains bad graphics performance - but it should not be that bad. It is actually ok when playing alone with multiple computer players ('CPU') but it becomes unbearable on network games with multiple players. I can hardly point and click then, just guess (where the mouse pointer will show up next) and click.

Answer: Yes this is a high priority and will be looked at after we have stable network play.

* Please make in-game chat colors represent the users' color.

Answer: Feature request noted.

* Please indicate, textually, for each unit which player it belongs to.

Answer: Code exists to do this but it is not ready to release yet. To see it, edit glestuser.ini and set DebugMode=true, then during game play (in game) press the ? key to see what I mean.

Thanks

[tomreyn]

Thanks for your replies, softcoder!

I have one more question regarding this: You said

Answer: Feature request noted.

which makes me wonder how bugs and feature requests are currently tracked. Is there a publically accessible bug tracker you use? I saw there are some entries in the SourceForge bug tracker but it's really few.
I'm mostly asking because I wonder how the bug tracking can be made most usable/comfortable for the developers and prevent that bugs get reported but are later forgotten about. It's also nice for users to be able to watch the process on a bug or feature request (if it's a larger issue). I'm not sure it's worth it to set up something like bugzilla for it, but it could be (unless it already exists, of course).

[softcoder]

Code: [Select]

[url=https://sourceforge.net/tracker/?group_id=300350]https://sourceforge.net/tracker/?group_id=300350[/url]

[claymore]

Can somebody move this thread? I nearly missed it.

Thanks for the informative replies softcoder. That answered one or two of my questions as well.

[tomreyn]

Yes moving the thread would be nice, thanks in advance.

Since graphics performance is one of the top targets (after stability), I've compiled some stats on my Ubuntu Lucid (10.04) laptop with:
GL_RENDERER   = Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
...with 256M shared RAM. The PCI ID of the chip is 8086:2a42.

The Kernel is 2.6.32-22-generic, the graphics driver is i915 (srcversion 2CD294A9B4EF76F55537D28)

megaglest 3.3.5beta5 gives me between 0 and 35 FPS (based on what the game reports in debug mode), with no action it is usually at 25 during gameplay. These values only change marginally (but never exceed 35) depending on the various factors: full screen vs windowed, 640x400 px + 16 bit vs. 1680x1050 px + 32 bit.

supertux 0.3.3 (2D jump'n'run/scrolling side game) performs at around 60 FPS with opengl renderer and music + sound.

'glxgears -fullscreen' also does 60 FPS.

Globulation (glob2) 0.9.4.4 runs fluidly, but I didn't find a way to make it show the FPS.

Battle for Wesnoth 1.6.5, invoked as 'wesnoth --fps -f -r 1600x1050 -bpp 32 -t -m' gives me 50 FPS when there is no action and about 35 FPS when units are moving or fighting.

[ultifd]

@ultifd: Thanks for your friendly reply. We seem to agree on most topics, that's nice. As such, and since you did not explicitly ask for it, I'm not responding to your individual statements this time (let me know if you think differently).

No problem, and yeah, it is all right. You don't need to reply.   I just did because...well I wanted to I guess.

There's this reply of you, though, which I just can't make anything out of:

Code: [Select]

---quote text---

If you could just re-read this sentence, it will probably become obvious that there's no way for me to understand what you are talking about (aside from the first statement where you agree it's beneficial). You seem to want to say something but at the same holding back any info on it which would have allowed me to understand what you are referring to. So: here's another chance to either say what you wanted to say or just not say it, both is totally fine with me. ;-)

Well, yeah, I was agreeing that it was beneficial, and then I was going to continue on about what I was going to say, but then I thought again, that it would be better to wait...after..."everything" I guess. So, no, but I guess I would have my say later on this again...later   .

Yes moving the thread would be nice, thanks in advance.

Just to make it stand out, and that everyone agrees.   Archmage? Omega? Titi?  

Softcoder's Answers: Thanks,   ...Very informational mostly and answered a question that I had...I think.