Jump to content

janwas

WFG Retired
  • Posts

    2.733
  • Joined

  • Last visited

Everything posted by janwas

  1. heh, that's certainly true - it's much easier on Windows. Right, but this release (being incomplete and rough around the edges) is intended for devs. I think idle is somewhat frustrated that your reaction to the error was running with sudo. Instead, the correct thing to do after update-workspaces succeeds is invoke make from build/workspaces/gcc (which should be where a makefile resides).
  2. Ah! Good to hear that it runs after all, but we'd love to know the error that comes up. (unfortunately our debugger infrastructure isn't as good as on Windows, but if a ~/0ad/logs/crashlog.txt is written, that might help)
  3. Ah, then it's the same as on Windows. (hm, someone posted the command line "0ad" from their Linux system, I wonder what that was..) Looking in the build instructions: "( cd ../../../binaries/system && ./pyrogenesis_dbg )" that appears correct - have you already updated it?
  4. Ah, I'm glad the uint64 issue made it into the wiki hm, we've had reports of successful execution on OS X, so a missing library might explain this. You don't happen to have any information/backtrace on where it's freezing?
  5. Glad to hear it, have fun! It'd be helpful if you could post those errors on trac.wildfiregames.com and link to the ticket from here. Hopefully we can get them solved
  6. Topic moved hm, I don't see any remaining errors except for the NSPR flag thing - is that causing the compile to fail? Unfortunately I can't help there, but hopefully Simon and/or Philip will see this and have an idea.
  7. It's good that you're running x86, that at least gives us hope We might be running into trouble with the SpiderMonkey library itself - their versions and capabilities (most importantly: thread-safety) differ. I would have thought the recent step of adding our own SM branch to SVN solves this problem, but maybe it isn't actually being used/compiled. Would you like to try adding an #error to some files in libraries/spidermonkey/src and /include and recompiling? If indeed your locally installed SpiderMonkey was being used, we'll need to change that, but unfortunately I have no idea how (Windows user ).
  8. pyrogenesis.exe is coming from SVN (it's auto-built for the convenience of our artists who run Windows). pyrogenesis_dbg is also the Windows name - I believe it's called 0ad on Linux. Have you checked the most recently modified files in trunk/binaries and/or trunk/binaries/system? That should point out the build output.
  9. 5 times? hm, that's possible but a bit much. Philip will know the exact load on the server, but I would've thought things had returned to normal after the initial slashdotting/surge of interest.
  10. hm, that's a strange one. We don't actually call JS_DefineFunction, it's probably being invoked from one of several JS_DefineFunctions. Could you please add printfs to those four spots to try and determine which of its parameters is equal to 1? BTW, I hope "bus error" isn't due to the address being unaligned. Are you running OS X on an x86 processor? I doubt we'll currently run on PPC due to possible endianess and alignment bugs.
  11. Good point. Now that I think about this more: - why that header is being included at all? I thought our version is meant to override the default system header. - the PROTYPES_H comment suggests that the contents of this header should be supplanted by NSPR's definitions. Do you not have that installed? (That might explain why others don't have this error - I thought the OS X build was working after we added the SpiderMonkey tree.)
  12. Thanks for sharing It's sad to hear that Qt Creator isn't there yet, because I've tried out Eclipse and agree that its UI is "a bit strange".
  13. About libCollada_dbg.so: that's probably because it wasn't successfully compiled for some reason. There have been reports that parallel make breaks, running without -j parameter may help. Was it the same for you, that a second build attempt worked? UTF problem: looks like those are coming from a javascript file. The first scripts to be loaded after InitVfs are in binaries\data\mods\public\gui\test. Could you please open all of the .js files there in another application and see if it complains about a byte order marker or similar?
  14. By all means, please add it to the BuildInstructions! (ideally they should allow someone like me - not at all versed in Mac development - to get things up and running fairly painlessly. I like how that's mostly automated on Windows, but a detailed list of required steps is the next best thing )
  15. This is interesting for me as well, I've been trying to break the addition to Visual Studio for years now Have y'all tried out Qt Creator? That looks quite promising, and it even uses the VS debugger on Windows (which is a huge plus, because nothing else IME has come close)
  16. Ah, that one's a pretty good argument for namespaces (two libraries are defining the same symbol). Your workaround looks good - could you please add that to http://trac.wildfiregames.com/wiki/BuildInstructions? (either in the instructions section for OS X or in known problems at the end - whatever you deem more appropriate)
  17. Nice to have had a chat with you! Working on GUI frameworks at the day job is a good basis for taking up the GUI thread in 0ad.. Since that's so near the user, I figure progress there will be immediately visible, which is nice. A longer-term goal (fed by an interest in game development, not just general GUIs) is work on gameplay code - let's see what specifically interests you when you're a bit more familiar with the engine. Welcome, and I'm looking forward to working together with you!
  18. Greetings! Uhoh, those previous errors are already showstoppers. Since even the simplest of the VFS mount calls is failing (line 570, accessing pre-existing directories within the SVN tree), it looks like we're failing to determine the executable's directory. Does it help if you launch the game from gdb, which sets argv[0] correctly? Can you please step through source/lib/sysdep/os/linux/linux.cpp's sys_get_executable_name and check what source/ps/GameSetup/Paths.cpp's Paths::Root is returning so we can find out the cause? Unfortunately I can't help much with the libCollada problem (am developing on Windows). Do you see anything in the build log that indicates the .so wasn't actually built?
  19. If you have some knowledge of Python or are feeling adventurous, you might try wrapping the ReadContents call (xmlUtils.py:119) in a try/except block and printing xmlNode. With a little luck (I'm not familiar with the Blender code and can't have a look ATM), that will display which XML node is apparently missing (or failing to be read), and maybe we can just add that to our .dae file.
  20. Not a problem, I bet we can make it work this weekend If the weather holds, I'll probably be going on an all-day bike tour on Sunday. How does Saturday morning (say 0900 GMT) suit you?
  21. Glad to hear it:) For info on graphics settings, please see http://trac.wildfiregames.com/wiki/Playing0AD (note that we recently added support for home directories, so the path for local.cfg should be $HOME/.0ad/config/local.cfg IIRC. You can also launch with -writableRoot to keep the old behaviour.)
  22. Hm, it looks like there is a problem with how boost::filesystem is being linked in (or not, as it appears). Searching for the missing reference in question yields this: http://lists.boost.org/boost-users/2007/11/32237.php .. so it may just be a matter of your boost_filesystem.* file's extension. Does it help if you copy it from .a to .o or vice versa?
  23. Sorry for the delay, things are hoppin' How about we meet up at 1000 GMT in Quakenet #0ad?
  24. 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.
  25. Greetings! Unfortunately 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
×
×
  • Create New...