-
Posts
2.733 -
Joined
-
Last visited
Posts posted by janwas
-
-
I'm running extreme barebones services.
Ah, that explains it
I've changed related code to silently and safely handle disabled WMI (r7071).
About memory leaks and antler: yep, we are aware of both but they haven't ever reached the top of the TODO list (The latter is due to an error in deer_mesh.dae and not code)
-
http://trac.wildfiregames.com/changeset/7065#file6 -- the intent was that any errors other than file-not-found would be ignored here, and reported normally when trying to open the file normally a few lines later. With the new change, if e.g. your disk accidentally turned into cheese then you'll get a "Cannot find config file" warning instead of the proper disk-is-made-of-cheese error, which would be confusing. So either it should ignore all errors except the legitimate file-not-found/container-directory-not-found/etc ones (so it'll try to open the file and complain about any persistent errors), or else the warning text should be changed.
Ah, that's a good point, but it looks like philosophical territory. The original intent was that all (low-level) errors be reported immediately when they are generated (i.e. by using WARN_RETURN ERR::xxx instead of return ERR::xxx), so the cheese error (hehe) wouldn't be ignored.
Also, there is something to be said for the main game code saying "cannot find config file" regardless of whether it's just because the file wasn't found or because the disk is made of cheese - the result is the same.
Finally, how can the game code (or for that matter, LoadFile) know what errors to ignore and which ones should actually reported? I'm pretty happy so far with the policy of reporting everything unless a particular error happens often/legitimately, but am happy to be convinced otherwise.
The tests fail:Uhoh Unfortunately I'm out of time today and probably won't be able to look into the issue until the weekend due to an upcoming trip.
Directories aren't created with 0700 permissions (which XDG basedir requires) - they seem to be 0755.Yep, I couldn't see a way to do so with the boost filesystem API - create_directory lacks a mode_t parameter:
Attempts to create the directory dp resolves to, as if by POSIX mkdir() with a second argument of S_IRWXU|S_IRWXG|S_IRWXO.We should revert to calling mkdir then, eh?
There's no tests for the new code, so it would be easy to break it in the future and start putting files in the wrong locations and not notice.Yeah, I'm kind of worried about confusion regarding profiles etc., especially because the old location is still supported (depending on cmdline args). Do you have any ideas?
-
Interesting, I've not seen such an error before.
Are you running on a least-permissions account or as admin? Vista, XP or Win7? 64-bit?
Not sure if it has anything to do with WMI service within windows xp.Yep, we use WMI to retrieve certain system information. Until the problem is found and fixed, you can launch with the -quickstart command line argument (which disables the system detection code and sound).
A bit above me as to what it even does other then warn me about error # 4.The error#4 bit is just so we can see exactly which function failed. If you have access to a debugger, could you please post the value of hr? (If not, the error code should be visible in the Application section of the Windows EventLog)
A web search shows several similar problems.
If you start->run compmgmt.msc -> services and applications -> wmi control -> right-click -> properties, do you see an error?
http://www.pcreview.co.uk/forums/thread-526766.php was solved by ensuring %windir%/system32/wbem is on the path.
You may also want to check out the wmidiag tool (it seems to be useful for such problems).
-
Yep, the error code means "directory not found" in very early init (the config file). Hopefully Philip will find the cause, unfortunately I can't debug on Linux. In the meantime, there remains an escape hatch in the form of the -writableRoot command line argument that should restore the old directory lookup scheme if it worked before.
-
Yep, looks like the space is causing problems. (I'm not sure how hard it'd be to change our build system to cope with those spaces - someone should feel free to look into it )
Yep, that's the cause (cxxtestgen is the culprit). The build instructions call for checking out into a directory without spaces; it would be slightly nicer (in a low-priority sense) to rule out this cause of errors, but I have no idea how much trouble that would entail.
The crash issue seems to be a problem with the environment on my machine, it has since stopped and I cannot reproduce it.hm, that's strange (and slightly worrisome to have unknown bugs lurking nearby). One thing that changes with time is the translation of XML files to XMB. I guess it's possible for one of them to have been garbled, and the recent change from binaries/cache to $appdata/0ad/cache may have hidden the issue. Would you like to try deleting the former and renaming the latter cache folder?
-
-
Sorry for the inconvenience. That code was only a stopgap until the proper directory logic was implemented and has now been replaced. However, it did compile on VC2005, not sure why.
-
After two coding sessions yesterday and today, the support for user/home directories is in place. Crashlogs and screenshots are written to a subfolder of appdata/0ad or the appropriate XDG folder.
Ticket 81 has been updated.
It works on Windows but is untested on *nix Please drop me a line if there are problems.
-
Assertion failure: (uint32)2 < JS_MIN(((obj)->map)->freeslot, ((obj)->map)->nslots), at jsapi.c:2118
Aborted
Hm, this might be another instance of a known problem when the SpiderMonkey library wasn't compiled with the same version/flags we need. Mid-term, Philip (who knows more about the topic) was wanting to add source+makefiles to SVN so that we can rule out such incompatibilities. Unfortunately I don't know a short-term workaround, nor can I help with the wxW issue.
-
Hi Brandon and thanks for reporting the problem!
Those files are all generated by the test_gen project and do not exist in the non-public repository, either.
Could it be that test_gen isn't being built, or that dependencies are incorrect? (test_gen needs to build before test)
About the game crash problem: whether unrelated or not, we'd be happy to try and solve it. Please feel free to create a trac ticket (CCing "jan" ensures I'll see it faster) or attach binaries/logs/crashdump.* here.
-
Ah, that is helpful! The crash is apparently inside the error reporting code, which is why you aren't seeing the "Program Error" dialog. However, the crashlog.dmp file in binaries/logs/ should have been written by that time and is essential to finding out what happened. Can you please post that as well as pyrogenesis.exe and pyrogenesis.pdb?
-
I'm fine with using XDG, it's reasonably straightforward.
Subdirectory 0ad - makes sense.
mkdir with 0700 - done.
Alternative: Maybe we could skip the mods/*/*.zip thing, by not dynamically creating archives - just do it once during system-wide installation, and never at runtime.I'm fine with that. This archiving code has long been dormant anyway.
For efficiency, /usr/share/games/0ad/data/cache/ should be initialised (on installation) with conversions of all the .xml and .dae files.How would that work? Do we really want to create a separate cache-everything routine or executable?
BTW, the VFS was designed for this kind of thing, but the underlying path.cpp's Path presumes that everything will reside in one directory. Am currently removing that logic.
-
The error says: " Pyrogenesis .exe". You have an error with pyrogenesis exe. The application will be closed. Maybe you have lost your data
Interesting. I would've thought that to be "impossible" because we have a crash handler that should intercept any errors (and report information about them) before the normal Windows dialog comes up.
Do you see anything in the Windows event viewer, or when running DbgView while attempting to start the game, or any files created in binaries/logs/?
Well, I apologize, I realize now an installer is probably not a good thing for developper's health at the momentDon't blame me
heh, no worries. Let's just keep in mind that the probability of fixing an error is directly proportional to the amount of information provided. Frankly, with the above four reports, that chance is near zero.
An analogy for non-software-developers: imagine you build an oil rig and someone tells you: "it exploded". Is that enough information to understand the cause?
-
Those compile errors are from Atlas (and its freestanding tools), which is compiled separately from the game (thus explaining why it still runs).
Another ALCvoid-like issue ?That's possible, but I thought we'd concluded that GCC > 4.2 causes the error. Here it's the opposite.
Can you post a few of the referenced lines in il.h and ilu.h so I can check?
-
The latest errors are caused by the DevIL library not being found on your system, but unfortunately I can't help with installing it. IIRC there were several threads mentioning it, though.
-
(I'm beginning to feel like a broken record..)
What is the exact error message? Is it shown by Windows in your native language or by an english-language dialog entitled "Program Error"?
To give us a realistic chance of diagnosing the error, can you post binaries/logs/crashdump.*?
-
Oops, sorry We've been emulating secure CRT (e.g. strcpy_s) functions for non-Windows platforms as needed, I didn't realize vsprintf wasn't yet included.
r7060 attempts to fix this. (I can only test on Windows, please yell if that doesn't do the trick)
-
How exactly do I do that?
Right click pyrogenesis (bold) in project explorer -> debugging -> command arguments.
(or you can launch pyrogenesis.exe yourself from a shell)
Incidentally, I hope to have just solved the "resolution <= 2e-3" problem, see http://trac.wildfiregames.com/ticket/253.
-
What's the error message? Can you post binaries/logs/crashdump.*?
I don't think it makes a difference on which machine you compile, except for maybe the compilers' runtime libraries already being installed. However, we account for that issue (they should all be distributed in SVN).
-
Automatic creation of directories now hopefully works. Could you please try again after deleting the cache/ directory you created?
-
hehe. Good point, I have just (locally) changed the error message formatting to include the error number
-
Location: wdll_ver.cpp:57 (ReadVersionString)
Looks like the same error as above. Are you running Vista? 64-bit or 32?
This message is just a warning, and until it's fixed (which requires more information for purposes of debugging) you can either just ignore it (choose continue or suppress) or start the game with -quickstart (which disables the system-detection code that calls ReadVersionString as well as sound).
Performance warning: your graphics card does not support compressed textures.This one's probably a show-stopper. The game isn't going to run well without a GeForce III-level GPU, and current onboard offerings aren't there yet. Is upgrading your GPU an option?
Some prerequisites to run the game (like directx version or so)? It crashes also to me when i launch it after installing.Are those the only errors that show up? We can't debug crashes without more information, most importantly the files crashdump.txt and crashdump.dmp.
-
Context menu -> Settings -> Network.
-
Thanks Jeru, but I rather won't because this error occurs when I use the installer, which is irrelevant to the developers.
Don't get me wrong, we are happy to look at the issue, it's almost certainly not caused by the installer itself. (The wdll_ver issue is likely caused by Windows' automatic path redirection. Are you running a 64-bit version of Vista?)
As Jeru says, though, we need the crashlogs to get anywhere. Please feel free to CC "jan" if you create a ticket so that I'll see it sooner.
Installation and writable files
in Game Development & Technical Discussion
Posted
hehe, it's not quite that simple. Sure, we can check if the error is "file not found".
However, what was happening in this case is "dir not found" (files and directories are tracked separately). I think the capability of differentiating them is potentially useful, but it'd be burdensome if user code had to check for both of them. (Worse yet, delayed population of directories can postpone file enumeration errors - e.g. due to antivirus - until the first file lookup.)
GetFileInfo only avoids an *additional* error dialog from CHECK_ERR if you "pass in a flag" (i.e. set pfileInfo to 0), independent of the actual error. However, the new code doesn't silently ignore other errors because they are still reported when first returned from a function.
*nod* I've implemented our own CreateDirectories with a mode_t parameter.
Sounds good
Have noted this in the never-ending todo list.