janwas
-
Posts
2.733 -
Joined
-
Last visited
Posts posted by janwas
-
-
Greetings!
I can't send message to you Why? I can't send any message to any oneUnfortunately we've had cases of PM spam, after which Erik/feneur set a minimum number of 10 posts before people can send PMs. I see you will have those soon, and if Erik sees this earlier, maybe he can give you that permission immediately
-
That's bad news, I can't see why that is happening unless you happened to leave out some parts of the VC++ install (most notably the platform SDK), especially since you've done a complete reinstall
I think most of us were using VC2005 and it has worked without problems. VC2008 SP1 is also known to work - is upgrading an option?
-
Thanks to Philip for reviewing + committing this, and to Cygal for the patch!
-
Thanks for confirmation of AL_NONE
I've created a trac ticket and am looking through Philip's trace file, which is probably going to be awesomely helpful..
-
Thanks for reporting these warnings!
We already have a trac ticket for this particular issue, and will fix them when time permits -- or would be grateful for help in doing so
-
-
The workaround suggestion is good for starters.
Attempted analysis of cause:
The OpenAL spec says alSourceQueueBuffers fails with "invalid operation" if:
1) No current context
2) Adding a buffer of a different format
3) Source has static buffers attached
#1 is ruled out due to the non-existance of an "alc_init failed" error message, which implies alcCreateContext returned non-NULL and alcMakeContextCurrent did not encounter an error.
#2 is 'impossible' (except if memory is corrupted) because the buffer format is set once per file and never changed or transferred.
#3 can't happen because we never set static buffers (the only time we alSourcei(.., AL_BUFFER) is when buf=AL_NONE).
Could you please verify that AL_NONE = 0 on your system?
The most likely of these options appears to be #2. Could you please add a debug_printf("%d\n", sd->al_fmt); line before returning from snd_data_buf_get?
The first two times (main menu, in-game music), it should output the format for 16-bit stereo, all subsequent outputs should be equal and for 16-bit mono.
-
I was saying that he had the same problem/error as me.
Dude, that thread contains at least a half-dozen separate problems. You mean post#32 (the same "resourceObject has no properties" warning), right?
Building units in the barracks I do believe is what generates the problems.Ah. To be more specific, building a single Hippikon (cav sword) is enough to trigger the problem.
That also points us at the problem: the hele_cavalry_swordsman_b.xml file was structured incorrectly (build time was a child of Resources, which means the time object was being treated as a resourceObject). Fixed.
I've got the crashdump now. Where would you like me to put it?It'd be best to attach it to a trac ticket, so that it's more easily found and cross-referenced. However, you can also attach the file to a forum post.
wait that folder into in there anywherehrm?
-
I just go about playing. I get to gathering and everything. It just gets around to melting slowly into it.
Sorry, that's not nearly enough detail to begin debugging.
amd x2 44002gigs ram
ati x1650 256mb
I also just bought an HD 4650 to get ATI Firestream gpgpu. The CUDA equivalent.
Plenty of power to play Grand theft auto 4 and just about any other game I can find.
hm, that system should definitely suffice
Are you running a debug build? Switching to release boosts the framerate considerably.bah. Been putting off registering there heh.It would only take seconds and helps us as well as yourself (e.g. notification when something related to the issue changes).
I cant seem to get it to crash the same way without the debugger running. So I'm not sure.Thanks for trying though
-
OK, 1.38 might also work. Does a file named boost_system-mt.* exist at all on your system? Boost can be linked statically or dynamically.
Unfortunately I can't help in more detail (am developing on Windows).
-
Do you have Boost 1.35 installed? The error message refers to a missing library that belongs to that package (libboost-dev); if it's installed, then we may be looking for it in the wrong directory.
-
Greetings,
installed Visual Basic 2008 Express Edition SP1You need to install Visual C++ to compile the game.
-
gui/test/functions_sim_player.js(114): TypeError: resourceObject has no properties
The sim player error repeated MANY times.
hm, I don't think we've seen that before. What are the steps to reproduce this problem? (What map? Was it triggered by giving the order to chop wood / work a farm etc.)
D:\0ad\binaries\logsNothing in there applicable.
I've just added a readme.txt there that explains that log files are only created at this location if you launch with -writableRoot. The log files should be located in %appdata%/0ad/logs.
http://www.wildfiregames.com/forum/index.php?showtopic=12424&st=20#Had this problem also.
hm, do you mean build issues? That thread is mostly Linux-specific, I can't see what problem you are referring to.
-
No. The game didnt even crash. I had to kill the process to get rid of it.
hrm, it looks like you launched the game from the VS IDE. Could you please run it without a debugger so it has the chance to write out a crashlog?
What are the steps required to reproduce this problem?
WARNING: missing a simulation turn due to low FPSBasically these get repeated over 9000 times.
hm, that's a vicious circle - if the framerate is too low, then a debug_printf raises that warning, which is quite slow, thus further lowering the framerate and so on.
What are your system specs? There's little that can be done here besides using a release build and/or disabling the warning.
The field amount went to [588.9999].Ooh, that is bad news indeed.
Debugger never gave me anything for it though. Logs have nothing also.Right, resources are computed within Javascript, which has different behaviour concerning variables and typing (or lack thereof).
Could you please create a trac ticket for that one? (trac.wildfiregames.com) It'd also be helpful to know if that was a once-off event (happened only once during 10 test runs) or whether it's common and always happens if you farm for xx seconds.
-
Sounds good!
Hopefully the usefulness of not having to manually build the external libraries outweighs the extra time spent checking that the libraries are up-to-date and the extra spam from those build scripts.I'd think so, (reliably) solving the frequently occurring SpiderMonkey problem is already valuable and update-workspaces isn't run that often, so a few seconds doesn't hurt at all.
-
Did you see the whole output, Jan ? What could point to these errors otherwise ? I can't see anything else for my part ...
I didn't see any relevant info, either :/ (We do need to clean up those warnings, though)
Just one thing looked strange:
/usr/bin/ld: can't/usr/ locate file for: -lAtlasUI_dbgbin/ld: can'tlocate file for: -lAtlasUI_dbg
Is it trying two linkers (and failing to print a newline after the first error)? That's interesting..
-
more complicated sounds ok, as long as it is only complicated
heh, true
In fairness I'd say our build script isn't horribly complicated, and it remains readable by virtue of being Lua (not my favorite language, but still way more intelligible than CMake or m4).
I didn't know about --as-needed, thanks for the pointers.
-
Binary packages are configured and compiled for a particular Linux distribution with a particular filesystem layout. With most programs you can change the default directories by passing arguments to the ./configure script before you run make, and the paths get compiled into the executable. You can't change the paths without recompiling, but you never need to change the paths so that's okay. I don't see any reason not to do the same - so we should let people specify the paths (for system data, not per-user data) when calling update-workspaces.sh, and default to the common /usr/... paths, and then the game can use those string constants when loading data and libraries (when it's run in the run-from-system-installation mode, not the run-from-SVN-checkout-directory mode).
Ah, ok; that'd just require simple changes to the Paths class (i.e. hardcoding the paths).
And I think that supporting both ways of installing (like in windows and in /usr) on *NIX-systems would be the best solution because it would allow people to install the game even without root privileges - by simply downloading binary distribution and unpacking it directly in their own home dirs (boss will never know ).That's a good argument. Only supporting the single-directory mode on Windows would've been a copout, to be honest.
OK, I've run out of thoughts on this topic Thank you for your patience reading them.Thank you for your comments, they are helpful!
This should be fixed in r7081. (Also I've extended CxxTest so you can run "./test_dbg -test TestSysdep" and "./test_dbg -test TestSysdep::test_sys_get_executable_name" etc to run individual suites/tests, and added build system support for mock objects.)Awesome!
(It's not fixed very nicely, because in general it seems to be impossible (or at least extremely hard) to find an absolute path corresponding to a relative path - e.g. if I symlink /tmp/a to /tmp/b/c, then /tmp/a/../c/ is equivalent to the absolute path /tmp/b/c/, so you have to mess around with the filesystem just to normalise the path. It would be much easier if we didn't actually try to determine an absolute path for the executable, and were happy with unnormalised relative-to-cwd paths, but I don't know if we can cope with that.)I agree that being 100% robust there is unrealistic (symlinks are tough, but also due to unpredictable contents of argv[0] and getcwd/initial_path - they may be total garbage). However, the source copies the old/deprecated normalization stuff from boost, and I'm wondering why realpath wasn't used - that looks to be more robust and should at least correctly handle symlinks.
One more comment: relying on cwd doesn't work on Windows because it in turn is not always correctly set *sigh* (I forget in what cases, but launching from a shell and explorer and debugger behaved differently).
-
Greetings! Sorry about the delayed reply.
Help is very welcome. We are happy to accept patches, and the process for selecting tickets to work on is exceedingly simple: whatever grabs your eye!
(See http://trac.wildfiregames.com/report/3)
Really anything not marked as an 'enhancement' would have a tangible benefit, and one of the advantages of being a hobbyist group is that there's no boss ordering you to do stuff you don't want to do.
If you're in things for the long haul, we'd love to see you join the team. That can be arranged by having a quick chat in IRC to get to know each other a bit better. It looks like things will be pretty hectic today, but how about mid-day tomorrow (Sunday)?
Am I correct in assuming you are currently in the GMT+2 time zone?
-
The directories are referenced from build/premake/extern_libs.lua but aren't present in libraries/. Comsuppw (Windows-specific) is a .lib file shipped with the compiler; X11 ought to be present on most *nix but I don't know where/whether we need a directory or just a single file. I don't know about DL, either. Seems quite doubtful that these warnings point to a problem that prevents the library from being loaded, though.
-
hm, it's safe to say that the cause is a NULL this pointer (offsetof m_RenderData is 0x9C, which is also the faulting address). Unfortunately this member function appears to be called often, so it's difficult to see what's going wrong. Did the game write a crashlog.dmp to %appdata%\0ad\logs? Posting that would be helpful.
-
Well, lets look at two my favorite strategy (both turn-based) windows games: GalCiv2 and CivIV
They both save all the per-user config data, mods, saves etc into %PROFILE%\My Documents\My Games\<game_name> folder. They never save anything in Program Files. I think it's the best practice for windows.
Right, that's pretty much our plan on Windows, too
(Just substituting CSIDL_APPDATA for My Documents)On other systems there can be different paths (/usr/etc instead of /etc for ex.) but I'm not sure you plan to support all this systems.That's the advantage of XDG - we write a bit more code once, then users/systems can easily change environmental variables to support their particular path setup.
And as a universal solution you can use cmake to configure sources to use correct paths and it will allow you to get rid of all this path checking - paths would be fully static but configurable before compilation.hm, that's an idea, but I'm not sure we'd always want to require configuration+compilation. Wouldn't it make sense to provide binary packages (debs or rpms) eventually?
-
Sorry that I didn't read the whole tread...
but _PLEASE_ don't use such exotic build-systems!
Reading the thread would have pointed out the reason for a more complicated build system - Makefiles or autotools do not meet the requirements set out above.
but the others are horribleDoes that include Premake and scons?
They don't respect *FLAGS (LDFLAGS/LIBS, -Wl,--as-needed) which is important if you'd like to link just _really needed_ stuff etc.hm, I don't have much Linux experience, but only linking in the bare necessities doesn't exactly sound like a killer feature. Is that so important?
-
- on Windows systems all data files are in relative paths and the main executable is in the root of this hierarchy. You don't need to check anything.
That's currently true for many systems, but newer versions of Windows and least-permission user accounts forbid writing to some directories, especially under Program Files. Hence, we should also separate data and executables on Windows.
- on *NIX the executable is in /usr/bin (or in /usr/local/bin) and the data is in /usr/share/<program_name> (or in /usr/local/share/<program_name>). In package managers this path is coded as 'datadir'. Once again you don't need to check the paths.hm, I don't know about acceptable practice on Linux. The XDG layout scheme (what we're now using) was recently suggested. Can someone else with more experience comment on whether fixed paths would be acceptable? (Simplicity is a pretty compelling argument
)However, XDG isn't that much more complicated. I think what's "killing" us is correct relative search on Linux, as Philip points out. What if we only enabled the option for that on Windows (where GetModuleFilename is easy+reliable)?
Installation and writable files
in Game Development & Technical Discussion
Posted
Oops, that logic is incomplete. I think the intent was to grab the system.cfg from paths.RData() (i.e. svn) and local.cfg from paths.Config(), which coincide iff -writableRoot was specified.
How about we add a second Mount there unless the two directories are equal? To make saving config files more likely to work, the writable directory (i.e. Config()) should be mounted last.