Messages

2726

Closed bug reports / [fixed] Bugs in megaglest-3.3.5beta7.1

« on: 16 June 2010, 05:02:21 »

1. When you are starting a server but the port is already in use you get an error message (which doesn't look nice, yet). Once you clicked that error message away, you end up on the server configuration screen. This doesn't make sense since you cannot run the server if it cannot bind to the server port. Clicking any button will bring you back to the previous screen. That's fine for now, it's merely a matter of good looks and hardly a nuisance.

2. When announcing a server to the master server, it's currently possible to inject arbitrary values for the various fields. This allows for falsifying information on a server. It also allows for injecting values unexpected by the client. The client will then display error messages whenever it tries to parse the server list. This currently boild down to a DoS situation, since with the error messages popping up as soon as the master server info is parsed, clients will not be able to connect to any server whatsoever.

It's also possible to add and remove fields. This allows, for example, to promote fake servers listening on arbitrary IP addresses (currently only on the hard coded default port, though).

2727

Feature requests / Feature request: Removal from master server

« on: 15 June 2010, 20:46:03 »

Possible servers are automatically announced to the master server, however they seem to remain listed until they time out. While this is good by itself, it would be better to also add a hook which will remove a given server off the master server when the server stops to pose as such, i.e. when the menu for hosting a server game is closed. This could possibly prevent that you see your own computer in the server list when returning from the menu where you configure a server.

I guess that's not very well explained, feel free to ask if anything needs better explanations.

2728

General discussion / Re: Compromised Website(Glest.org) and Insecure Logins

« on: 15 June 2010, 03:48:43 »

Could this have anything to do with kukacs missing account? You state that it was a long time ago, but is it still possible? 

Yes, it could. But it seems unlikely to me, there's no reason why just a single account would be removed off the forums. If someone was playing around with the site it'd be more likely the complete forum would get deleted, or they'd just pretend nothing had happened and would just lurk and take regular backups of the complete database instead, hoping to find sensitive information like CC numbers or similar in the private messages or hidden forums.

Unfortunately, I don't even know much about what to do there, since converting to HTTPS I not only don't know how to do, but would be unable to do that, and of course, it raises the question, if HTTP is so needed, why are the majority of sites, even very important sites, HTTP? Really only banks, paypal, etc seem to use HTTPS. Another, and more urgent precautionary measure is ensuring that only secure passwords (there is a definition for what secure passwords are, and this changes over time) are being used.

Let's not mix two things up. HTTPS over HTTP is a precautionary measure, which I think is very recommendable since it can prevent the hosting account from getting compromised in the future (and actually all websites providing logins and storing user date should be using HTTPS, and many do, not just banks and payment processors).

It is not, however, not a counter measure for the suspected on-going attack. If there is such an attack going on then what needs to happen is for everyone who has FTP access to change their FTP passwords, all mysql database user and all forum user passwords need to be changed (whatever the users' forum rank may be). Additionally, the existing code needs to be screened for more malware or backdoors contained in it. The server administrator (root) should be informed quickly, too). To be safe, it is a good measure to take down the website completely until the issue is sufficiently researched and resolved.

2729

Forum discussion / Re: kukacs acoount?

« on: 15 June 2010, 01:34:02 »

You'll have a table there where all the posts are in, and another table where his account credentials and personal settings are in (this part may be split up in two tables). If you can extract just this part of the dump then you don't need to roll back the complete forum for half a week. And I'd appreciate if you would not roll back the complete forum, not unless you make available to us a dump of the current state so we do can repost our recent posts.

2730

Feature requests / Re: Bugs and feature requests

« on: 14 June 2010, 21:37:03 »

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.

2731

Feature requests / Re: Bugs and feature requests

« on: 14 June 2010, 16:49:08 »

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).

2732

Feature requests / Re: Bugs and feature requests

« on: 14 June 2010, 12:34:39 »

@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. ;-)

2733

Feature requests / Re: Bugs and feature requests

« on: 14 June 2010, 03:00:50 »

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.

2734

Feature requests / Re: Bugs and feature requests, megaglest.

« on: 14 June 2010, 02:36:08 »

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.

2735

Feature requests / Bugs and feature requests

« on: 14 June 2010, 00:30:32 »

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.

2736

General discussion / Re: Compromised Website and Insecure Logins

« on: 13 June 2010, 19:29:36 »

Hi,

I'm the initial reporter and have registered here now. I've since been told that the compromise has happened long ago, and that, supposedly, almost everything has been cleaned up since, and the spam on the non forum pages (see the bottom of the page source on e.g. http://glest.org/) is just a remainder from then. I have no ways to verify that a complete cleanup (aside from this) has taken place so I'll rely on the statements I've been provided with, which were somewhat reassuring. That's also why I signed up here.

So the case about the compromised website may be less an issue than it seemed initially. However, the insecure authentication (due to lack of HTTPS) remains to be an issue in my opinion.

Looking forward to work and play with you,

Tom Reyn