malex984

yeah Well, on ArchLinux you have a choice to upgrade or not for each individual package. I am still not sure that it is due to libxml...

besides i needed to add all the ifs to "void SelectionSetManager::onRadiantStartup()" as follows: if( toolbar != NULL && item != NULL ) toolbar->insert(*item, -1); if( item != NULL ) item->show(); // Construct a new tool menu object SelectionSetToolmenu* toolmenu = Gtk::manage(new SelectionSetToolmenu); if( toolbar != NULL && toolmenu != NULL ) toolbar->insert(*toolmenu, -1);

So, after my changes to void Document::importDocument(Document& other, Node& importNode) its end looks as follows: if (/*targetNode->children == NULL*/ targetNode->name == NULL) { // invalid importnode return; } std::size_t i = 0; if( targetNode->children == NULL ) xmlAddChild(targetNode, xmlCopyNode(topLevelNodes[i++].getNodePtr(), 2)); // Add each of the imported nodes to the target importNode while( i < topLevelNodes.size() ) xmlAddPrevSibling(targetNode->children, topLevelNodes[i++].getNodePtr()); If DR works fine on some other system it could be that on that system some initialization has created those children before comming to this function ... ps: i am using the latest code from https://github.com/orbweaver/DarkRadiant.git , commit ID: c5c872b26a1284a947066c2682ff6a411f6beedd

libxml2 2.8.0 configured with --with-threads --with-history --with-python=/usr/bin/python2

Ok, the problem seems to be as follows: Document::importDocument assumes importNode to have children already but in the beginning it is wrong (targetNode->children == NULL)! Therefore it never even tries to create/add newly imported nodes with xmlAddPrevSibling. Update: Ok, it seems that i fixed that one... and can see the UI mostly constructed... but now I get NULL out of "GlobalMainFrame().getToolbar(IMainFrame::TOOLBAR_HORIZONTAL);" in void SelectionSetManager::onRadiantStartup(). Blimey! Update: ok, after adding some sanity checks/ifs it actually runs fine if one takes care to delay autosaving in the initial setup dialog...

Yeah, i also traced it down to some problem with RegistryTree building... Though, it seems that loading of xmls is fine whereas anything save for several "game" sections just would not get imported into RegistryTree's and therefore their "/darkradiant/user/ui"-section remains almost empty after all imports...

Well, does the following path setup seem fine for TDM? Let's say that SOME_PATH/anything/ contains the "thedarkmod.app/" (directory name 'anything' is not relevant). Then: SOME_PATH/darkmod/ is expected to contain TDM resources and SOME_PATH/base/ may contain D3 resources, $HOME/Library/Application Support/Doom 3/darkmod/ is used ONLY for downloading/saving/loading fms and contains the only relevant 'currentfm.txt' which appears there after "Install Mission" But: $HOME/Library/Application Support/Doom 3/darkmod and $HOME/Library/Application Support/Doom 3/base are not used for searching resources.

Well, the twist is that you actually need the whole .app directory instead of a single executable as for Linux. In the future one could also consider to try adapting the Linux code base to work under Mac OSX and thus get rid of that Apple Application Bundle but that would be quite a challenge as one would have to deal with XServer intead of using the Apple GUI frameworks, and XServer may even be absent on a host.

OSX native applications always look like that, see http://en.wikipedia.org/wiki/Application_bundle The DLL extension specific to OSX is .dylib but .so also often appears for some shared modules. Like in Unix - no special executable extension in favor of a file system attribute. That is why please consider it to be just a Linux with a twist that one has a whole .app directory instead of a single executable. What is your deployment concept? What resources do you expect to be present on host system and where? Note that putting thedarkmod.app directly into /darkmod/ would not work right now... But it is easy to change to make the application look for resources similar to the Linux variant. Would it be appropriate? What is the expected resource locations and their directory structures under Linux?

Welcome karlfox! Thanks for your interest in testing TDM under OSX. I would assume that you might need to checkout the drkmod SVN repo, which is rather huge to share in any other way... Other than that I could of course share my binaries directly but 1. they will be probably useless without that checkout(?) 2. being new here I would rather wait somebody from the TDM team to state their preferences concerning this. Guys?

Ok then I will try to produce them next. What Mac OS X do you use? Update: I built release fat universal binaries for min. 10.5 and put them to the darkmod SVN repo.

The point is that "~" worked in default (partially debug) build but it changed in release build... which was quite unexpected for me =) Ps: same sources, build projects, configs and resources.

Oh! Though only SHIFT CTRL ALT ~ does the job for this build...

Ok guys, I am happy to say that I have Release binaries and after finding a workaround for my *mission install* problems I managed to load and play a mission (outpost) as well as several usual maps (snow, rain)! Unfortunately the build seems to be very fragile and often shuts down due to segmentation faults right before the end of mission loading :'( Ps: curiously enough it seems that the tilde ("~") key does not trigger the console in this build...

Well then I am preparing a Release/i386/10.6 build now and will send it to you once I am satisfied with it (I noticed dependencies on global host libraries in what I had). Do you think I should rather build fat binaries with PPC or support OS X variants earlier to 10.6? Besides I am curious about where all the stuff under Doom 3.app/Contents/ should go?.. Ok

Besides I have built the default configs only and there were some debug builds involved (i guess that is why I could see the failed assertion). I bet the end users would be more interested in pure release builds while beta testers should better see more debug / assertion output. How do you usually handle the binary distribution for testing? Do you put different builds into different SVN repositories?

Seems ok to me.

Just as described at http://stackoverflow.com/questions/6087292/bad-codegen-pointer-diff-in-boost-error-in-32-bit-build Well, I got some strange things reported by "svn status" directly after checkout, e.g. In guis/readables/: ? MARBLE~3.GUI ! marble_world.gui Oh, I tried that without any luck - see also my previous post. Well, I am not quite sure about their correct locations =( what if send them ('Doom 3.app/*' and game.dylib) to you?

Thanks a lot! That did the trick. I can start and play any *map* with that!!! Unfortunately I still cannot install or run any *mission*: even through currentfm.txt contains it (and it is present under fms/ directory) - there is no currently installed mission detected by "New Mission" starting screen... Moreover even. "map MISSION" did not work - although I can list all the maps (with TAB) - no missions can be seen there. It seems that some search locations are wrong... Do you have a list of conventions for resource search locations? Can I view them via console? I would guess that TDM get confused by $HOME/Library/Application Support/Doom 3 even after I emptied it. Beside that I noticed textures missing on some maps (I only tried test/tree, rain, snow maps for now). At least once the application crashed due to DecodeOGG (there was a failed assert in sound/snd_decoder.cpp:517).

Yeah it does the same for me. What about the produced log?

As a side note: I found a reference to non-existing wiki page http://wiki.thedarkmod.com/index.php?title=TDM_Coding_Style on http://wiki.thedarkmod.com/index.php?title=Coding_in_the_SDK Was "TDM Coding Style" renamed or moved?

Greebo, thank for pointing out your Xcode projects. Well, actually it tends to use clang nowadays, which also provides frontends linked under the usual names - gcc and g++ :/ The command I was looking for is xcodebuild. Using it I was able to produce 'Doom 3.app' and 'game.dylib' much more quickly than via scons. But my previous experience with the scons scripts helped me to resolve similar building problems. Now I have two sets of built binaries to choose from =) Curiosly enough the both sets behave the same way. I Noted that the static boost libraries committed to svn seems to be built with -fvisibility=default which leads to quite a problem on newer OS X and Xcode. I'd recommend rebuilding them with the same settings as used in the project. Thanks. But please do warn about the size of such a checkout! Besides, does it matter if I place it on fat32? I checked it out under the name darkmod and put my 'Doom 3.app' alongside it. Additionally I replaced the game.dylib in one of the pk4 data files with my versions of it. Finally It runs: the GUI with ambient music and mission downloading seems to work!!! It would be nice to check the play mode now. Can I force a mission loading and starting from the d3 console or via command line? The problem is that I am having trouble installing (and therefore) playing any of downloaded maps. Also the installation-relaunch hides the mouse pointer but shows again the starting launch dialog. No matter what I do (I also tried running executables with the usual Doom arguments) - 'New Mission' never shows any mission being currently installed =( Besides there are no visible items in the list of installed mission but I blindly click there and choose them anyway... Seems to be a missing font... I also got similar effects while using the data files from my previous d3+tdm setup. But there I sometimes can see some of the currently downloaded missions. Well I will do whatever I can do. Ps: I hope it's ok to post all of this Mac OS X specific stuff here (publicly)...? The point is that I would like to attract the attention of interested Mac users and later on ask for their assistance in testing.

Sorry, I did not look at them properly yet (only for a bit of reference on lists of needed input sources, libraries and frameworks). It's just that I used a *faster* and newer Mac machine via ssh and worked there from command line... But I have been planning to try those Xcode project files next. I think one can do that from command line as well, right? Besides, is there some absolute minimum set of data files just in order to check that the runtime for produced binaries?

Hi guys, Looks like i managed to produce 'game' and 'libgame.dylib' by adapting the existing scons scripts to work on my mac os x + doing some hand magic. Naturally i'm very suspicious of these first fruits... Is there any quick (and maybe dirty) way to check the runtime without the original D3 data files? Cheers, Alex

start by changing "python-config" to "python2-config" everywhere in m4/boost.m4 and configure.ac and regenerate the build system (e.g. using autogen). after doing that you should not need to do anything fancy about configure.