mouse pointer problems

[DevUrandom]

What is the point of putting program data in my documents, considering that 'my documents' implies it is for user use only, not programs, and %APPDATA% is for application data, hence the name.

Cool, what you all know.
Please tell me what MS answers to your petition.

Map and mod installation should be supported from both installing to the install directory itself (to be shared by all users), or to the proper %APPDATA% directory (for single-user install).  It looks like that your virtual filesystem should support that just fine, as long as you have it setup like that.  Most people would probably just install it to the installation directory anyway.

Hey, that's a cool idea!
Oh, wait... We've got that 2 years ago... Sorry, no cake for you...

Will try to compile the trunk.  I attempted to download the pre-compiled one from that one stickied thread and all it does is crash upon app launch (apparently that is a common occurance with that one according to the thread).

We are always interested in sophisticated bugreports, which you, no doubt, can provide with grace.

And SDL problems have not always been my own, everyone else I work with has had issues with it as well, on a vast variety of different hardware (one of which is interesting, causes his main computer to hard-lock when SDL unloads, fully repeatable, thankfully I have had nothing that serious).

I recommend getting an OS which seperates User- from Kernelspace. So stay away from your Windows 3.1 and grab that shiny new Windows XP, Linux, FreeBSD, Darwin, ...

[Buginator]

What is the point of putting program data in my documents, considering that 'my documents' implies it is for user use only, not programs, and %APPDATA% is for application data, hence the name.  It is a well defined pattern, I use it, I also use *nix/bsd's pattern on their system, why break it?  Sorry, that just bugs me, My Documents is sacred, it shall not be touched by programs, hence why it is security permission locked to apps, have not had any real issues with it to date though (and actually I redirected the calls from wz2100 from it to to another drive, so it still does not touch it, just far more of a hassle since it does not respect %APPDATA%).

Map and mod installation should be supported from both installing to the install directory itself (to be shared by all users), or to the proper %APPDATA% directory (for single-user install).  It looks like that your virtual filesystem should support that just fine, as long as you have it setup like that.  Most people would probably just install it to the installation directory anyway.

MS wants to dictate how & where to have programs store the data.
While I rather it be a user's choice.

Lots of commercial games stick it where MS wants, so they qualify for the windows for game logo.
Even if my game is installed on say F:/, it still writes all the savegame crap to C:, no matter if C: is running out of room.  That really pisses me off.

[OvermindDL1]

That is without a doubt an OS issue. It should not be possible for *any* user space application to cause a hard lock. No ifs, no buts. Sure SDL might be doing something it shouldn't be, but the worst that should happen is that an error report dialog should come up.

Yes, I know, it should be a driver or something that is causing it, but we have tried updating everything, downgrading everything, trying other video cards, everything, and it keeps doing it at the same point all the time, other then that his main computer never crashes/locks/anything.

Cool, what you all know.
Please tell me what MS answers to your petition.

MS was the one who designed that pattern, their game studio is made up by a bunch of morons, but their main program divisions generally follow that pretty correctly.

Hey, that's a cool idea!
Oh, wait... We've got that 2 years ago... Sorry, no cake for you...

I have not tested so I did not know, as stated the game is rather unplayable with having to alter my click up a quarter-inch everywhere.  That is a good design, now just need to move it to %APPDATA%.

I recommend getting an OS which seperates User- from Kernelspace. So stay away from your Windows 3.1 and grab that shiny new Windows XP, Linux, FreeBSD, Darwin, ...

And if you could not tell from the file system structure I have described that I must be using Win2000 or higher (specifically XP).  I also have FreeBSD on my server, and Kubuntu on the older, mostly internet usage computer.

MS wants to dictate how & where to have programs store the data.
While I rather it be a user's choice.

Configurability for all such things would also be outstanding, and using the command-line parser you have you could easily have a main config file in the main directory, which could of course point to the secondary directory (or choose to just not use it, keeping everything in the main directory), where a config file loaded from the other pointed to directory would override any other given options in the first config file.

Lots of commercial games stick it where MS wants, so they qualify for the windows for game logo.
Even if my game is installed on say F:/, it still writes all the savegame crap to C:, no matter if C: is running out of room.  That really pisses me off.

Quite agree, my %SystemDrive% is too low on space, is not C: (rather F:), most games get stored on G:, this game is on E: (G is too full now), My Documents is in a subdirectory on O:, etc... Yes it is ugly but there are reasons behind this madness (which I can detail if you so wish).  Although I am not sure I have any games that have that white band across the box, tends to be a stay away sign for me (not to mention that they just tend to not be wanted, they are not like BZ2 or Wz2100 after all)...  And sadly my engines support that way as well, but I leave options to override it (or rather, to support it since I do not stick anything outside of the install directory by default).



Either way, back to being on-topic.  Found out that if I launch the game through the Steam interface (steampowered.com) so it would allow the Steam overlay to exist, then the blue bar across the top does not exist and the mouse clicks in the right place.  However, if I then launch the game by itself again the band is still there, so at least I found a pseudo-workaround, and it definitally seems to involve something in the windows creation as the steam overlay hooks the windows creation to set some flags on it so it can display its interface correctly (which it does not anyway, but that is besides the point, I still found a work-around for the moment so I can at least play it, now to introduce it to some people, been quite a few years since I have had a good multi-match in WZ2100).

[Per]

Where we write configuration and save data is determined by PhysicsFS, not SDL, BTW.

[OvermindDL1]

Where we write configuration and save data is determined by PhysicsFS, not SDL, BTW.

Yes, I noticed, hence why I referred to your virtual filesystem (PhysicsFS, where does the "Physics" part come from anyway?), and not SDL.  It looks pretty capable and useful.

[DevUrandom]

icculus.org is currently down, so I can't search for the correct answer, but I have this idea:
PhysicsFS abstracts the physical filesystem... Just an idea, will have a look what Ryan wrote about it when his site is back...

[OvermindDL1]

I will look into PhysicsFS when I download it to build the trunk, probably day after tomarrow.  I had never actually seen a standalone virtual filesystem before.  I built one myself using a directory structure similar to *nix/bsd based on mount points.  Anything, from input controllers to the display, register themselves in it (such as /dev/input/0/mouse/button/0), had quite a few useful things, could even mount remote points so that is the main way the engine communicated remotely, each player would have their own mount point (which could be queried and communicated with, would also have mount points underneath it as well, each node could be an object or a node for more nodes that could be objects and so forth).  Files themselves would also be mounted along the path and would be in a hierarchy so if you wanted a file called startup/init.cfg then you could grab it from /fs/startup/init.cfg, where it could search along multiple directories in a specific order, returning the first it found (multiple objects per node as you can see, each are iterated in a sequence until one decides it wants to handle the request, /fs would be an actual object, and everything underneath it could be real nodes if I mounted them manually, but if it did not exist then they would be passed to the /fs object to see if it wanted to handle it, and each would search in its assigned directory to see if the file exists, if not then it passes it to the next to check its assigned directory and so forth).  Probably not the best explanation, but it works quite well for my use.  The real filesystem is a node, each player would be a node, each game object could register themselves as a node if they wanted (and many do, generally everything in my engines do except for quick temporary ones like a cannon shot), arranged by team, type, etc...).  Only the initial string lookup is expensive (a hashmap lookup), but a link is returned that links to the node, even if nothing is assigned to the node yet, all access through that object is just as expensive as a pointer indirection.  A couple quick examples of pseudo'ish-code:

Code: Select all

Node player1Fire = Nodes["/players/OvermindDL1/input/fire"]; // "/players/OvermindDL1/input/fire" would probably be a symlink to something like /dev/input/mouse/0/buttons/0 if local, or if player OvermindDL1 was remote then it may either not exist, or it may be a networked synchronization object, depending on if it wanted to share it out or not, probably not
bool *firePressed=0;
try
{
	firePressed = player1Fire.link<bool>();
}
catch(InvalidLinkCast &e
{/* do whatever to handle it not existing */}
// or could do:
if(player1Fire.canLink<bool>())
{
	firePressed = player1Fire.link<bool>();
}
// could just bypass the firePressed stuff and register an async callback, less polling needed then...
Nodes["/players/OvermindDL1/input/fire/press"].registerListener<>(&WhateverClass::playerOnFireStart); // where playerOnFireStart would have a signature akin to void playerOnFireStart(Node &node);
Nodes["/players/OvermindDL1/input/fire/release"].registerListener<>(&WhateverClass::playerOnFireStop); // where playerOnFireStop would have a signature akin to void playerOnFireStop(Node &node);
// or could link to both at once:
Nodes["/players/OvermindDL1/input/fire"].registerListener<bool>(&WhateverClass::playerOnFire); // where playerOnFire would have a signature akin to void playerOnFire(Node &node, bool isPressed);
//Each object node can define its own interface and usage, and since that would be symlinked to an input object, the input object defines quite a few useful interfaces for different usages

// or for a file
Node superTankObjectDefinitionNode = Nodes["/objectdefinitions/SuperTank"]; // probably a defined symlink to some object definition file, like SuperTank.odf
// BitStream is just my basic bytestream, but with bit capabilities, mostly used for network stuff, if used as a bytestream with no bit functions then it is full speed with no real overhead, but the bit usage is useful for network communication to keep bandwidth usage down
BitStream *file = superTankObjectDefinitionNode.link<BitStream>(); // no error handling, just assume it exists...
ODFParser op(file);
int health = op["General"]["health]; // op["General"]["health] actually returns another object, but it can be silently cast to a string or a few other things depending on what is in the text, so probably an int, float, or other similar things as well since health is generally numeric, throws an exception if it does not support that cast, could also use <</>> to serialize an entire object out if it fulfills the interface requirement

Er, need to go, almost late...

[EvilGuru]

PhysFS is quite nice actually. Makes it easier for modders to replace/add things to WZ without exposing an array of security issues.

Although PhysFS does not do a particularly good job at finding config file directories. At least on OS X a specific piece of code is needed to get the Application Support directory. I would file a bug report but according to Buginator (who I believe posted a patch a while back) they are not that responsive.

Regards, Freddie.

[DevUrandom]

"They" is Ryan. And as we all might or might not know, Ryan is currently extremely busy with UT3...
I expect him to run through the ML as soon as "UT3 Linux client now available" is posted on his site.