Jump to content
The Dark Mod Forums

malex984

Member
  • Posts

    99
  • Joined

  • Last visited

Posts posted by malex984

  1. oh, well... i'd like somebody else to try running the build which works for me just in order to make sure that it doesn't contain any implicit assumptions/dependencies about the host setup... but if nobody is up to it - i guess i will try to find out which of my experiments where unnecessary and prepare a minimal patch which would be immediately useable without any unusual fingering.

  2. I am having a bit of unexpected trouble running TDM on OSX: i needed to correct doom.script but it still fails to set player data due to a dictionary memory corruption while loading a map (rain.map from darkmod resources repo) :-(

     

    Maybe instead of using the most recent trunk sources I really have to use the 1.8 branch?

    Do you still have sources for the recently updated version of boost in trunk, so that I could update macosx OSX binaries without touching headers as well?

     

    Besides, the downloadable current official tdm_update.macosx is supposed to prove the same recent data files under OSX as one would get by updating now under Linux, right?

  3. 1 - Does it build w/o errors?

    2 - Have Mac TDM users tested it?

     

    Please note that my patch is minimal one to let one to build TDM - the resulting binary may not do everything one expects.

    Therefore I'd advise testes to use binaries from darkmod SVN where I made some path&framework-related (quick-and-dirty + only for testing on Mac OS X) changes, or just wait a bit for another correcting patch, which I guess I will produce only after a good look at the final official 1.08 data files structure, e.g. on Linux.

  4.  

     

    Happy to test on a Mac 10.5 system if getting a hold of the 1.08 branch isn't too much of a hassle. Let me know-- I've got this thread subscribed.

     

    As I said i can easily provide Mac OS X binaries (and they are already In darkmod repo) but suspect that they will probably be useless without recent data files... no?

  5. 1 - Does it build w/o errors

    Yeah it does for me, but it depends on used gcc (Xcode) and SDK versions due to the way

    how the static libraries boost and curl were build, as I reported at the very beginning :(

     

    Do you know *exactly* which libcurl version is being used?

     

    The source code is frozen for 1.08, which is in its own branch.

     

    Once someone's perused the patch, you can commit it to the trunk, even before we've released 1.08. We'll have to figure out how to do a TDM 1.08-based package just for Mac after the 1.08 Windows and Linux versions are released, since we're not holding 1.08 for the Mac version.

    Well, you could point users to an additional patch if you are against incorporating it into the official 1.08...

  6. Beside the minimal-changeset patch from above I am prepearing another one with some further modifications to path-related functions and fixes to idlib itself which might be good for TDM in general, but IMHO it would be better to test them on Linux and windows beforehand...

     

     

  7. Ok, my patch is on ftp now: http://ftp.thedarkmo...tation.patch.7z

     

    If it is ok, i can submit it to darkmod_src, but i am no sure since i have heard it to be frozen now...?

     

    Note: the patch TDM is tested on Mac OS X 10.6.8 using Xcode 3.2.6 + SDK for 10.6 with gcc 4.2)

     

    Running the following commands produce universal dynamic library 'game.dylib' and application bundle 'Doom 3.app/' in created directory: 'sys/osx/build/Release'

     

    cd sys/osx/
    xcodebuild -project Doom3.xcodeproj 'ARCHS=i386 ppc' -configuration Release -sdk macosx10.6
    

     

    For debug build use "-configuration Debug" (results will be in sys/osx/build/Debug)

     

    Note: using "-sdk macosx10.5" (for minimal required OSX 10.5) required me to rebuilding libcurl for example with the following configuration:

    env MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-m32 -arch i386" LDFLAGS="-m32 -arch i386" ./configure --disable-ldap --without-libidn --without-zlib --without-ssl --enable-hidden-symbols --disable-shared --disable-debug --disable-dependency-tracking
    

    (and the same for ppc + combining universal binaries as per your wiki)

     

    due to the following error

    Undefined symbols:
     "_fopen$UNIX2003", referenced from:
      _Curl_cookie_output in libcurl.a(cookie.o)
      _Curl_cookie_init in libcurl.a(cookie.o)
      _file_do in libcurl.a(file.o)
      _file_do in libcurl.a(file.o)
      _Curl_parsenetrc in libcurl.a(netrc.o)
      _readfromfile in libcurl.a(formdata.o)
      _Curl_getFormData in libcurl.a(formdata.o)
    ld: symbol(s) not found
    collect2: ld returned 1 exit status
    

  8. Something strange happened

    [dragora@irya ~]$ git clone git://github.com/orbweaver/DarkRadiant.git
    Cloning into 'DarkRadiant'...
    fatal: unable to connect to github.com:
    github.com[0: 207.97.227.239]: errno=Expir? el tiempo de conexi?n
    

     

    I don't know if the problem is only mine because my internet connection is limitated.

     

    I will have the internet working normally on weekend.

     

    Hm, that worked for me. You could also try using https:// instead of git:// .

  9.  

     

    A quick "peep" from this corner-- we'll obviously defer to New Horizon on this, but if it's easier to share source and have me compile it, that's also fine. I'm in research physics, so compiling/linking/patching is nothing new (I just don't have your depth of knowledge to package things nicely; my code works, but it tends to be ugly). Cheers!

     

    Besides, there will be several issues of compiling TDM under OSX from the current SVN sources as I did not committed my fixes there yet since I was trying to fix the filesystem/path related parts.

    I can of course provide a patch to be applied on top of current SVN.

  10.  

     

    A quick "peep" from this corner-- we'll obviously defer to New Horizon on this, but if it's easier to share source and have me compile it, that's also fine. I'm in research physics, so compiling/linking/patching is nothing new (I just don't have your depth of knowledge to package things nicely; my code works, but it tends to be ugly). Cheers!

    Well, sharing binaries is not a problem, provided TDM team lets me do that, Guys?

     

    Besides, @New Horizon, if you have the darkmod svn access - I put universal binaries there some time ago - it would be nice if somebody other than me tries them out...

  11. Okay, that's good news. I'll take a look at packaging thedarkmod.app as a folder and getting it moved to the appropriate location. I also have to look at moving the fms folder in its entirety to the appropriate location.

     

    You might not hear from me for a while on this; it's going to take some research.

    Alternatively, rather than doing all of that I could simply change the meanings and initialization of fs_* variables instead, for instance as follows:

    look for everything in current directory (where the .app binary is located),

    for missions use ./fms/,

    forget about $HOME/Library/.... altogether.

     

    But where should I look for D3 stuff with this alternative..?

     

    What do you say?

  12. While I'm doing that, could you see if you can do an OSX build of tdm_update? The source code sits in the directory darkmod_src/tdm_update. There's a scons shellscript in there (macasx_build.sh), but I don't know if there's an XCode project set up.

     

    If you can do that, and check a new tdm_update.macosx (or whatever's appropriate) to SVN, I could try a Mac installation/upgrade myself.

     

    Building goes without any problems whatsoever. New tdm_update.macosx is in SVN now. No need in a XCode project as it is not an Apple application bundle.

  13. I have to look into adding thedarkmod.app to the packaging process. It may or may not require code changes to tdm_update.

     

    While I'm doing that, could you see if you can do an OSX build of tdm_update? The source code sits in the directory darkmod_src/tdm_update. There's a scons shellscript in there (macasx_build.sh), but I don't know if there's an XCode project set up.

     

    If you can do that, and check a new tdm_update.macosx (or whatever's appropriate) to SVN, I could try a Mac installation/upgrade myself.

     

    Ok. I will take a look at that.

     

    Besides I wanted to note that the current MacOsX build will only try to change $HOME/Library/Application Support/Doom 3/ and its children. For instance it will create "darkmod" there for storing downloaded fms and currentfms.txt.

    Which also means that fms folder and currentfms.txt from the delivered "darkmod" folder are ignored (unless it is placed in the location mentioned previously).

  14. If tdm_update packages "thedarkmod.app" as a folder with its contents, and that folder is placed inside the darkmod folder on OSX, will the player's double-clicking on "thedarkmod.app" start TDM correctly?

    Yes. Provided the folder is named "darkmod", and optional D3 resources are in the folder named "base", which is in the same place as the "darkmod" folder.

     

    Could one test your delivery mechanism before it goes public?

  15. I need to make changes to tdm_update so it puts the Mac file(s) in the right place.

     

    Does thedarkmod.app live in the darkmod folder?

     

    I also need to make changes to the packaging instructions. Is thedarkmod.app a single file that is built under XCode? Why is the folder of Mac files under darkmod in SVN called thedarkmod.app (the same name as the executable)?

     

    Oh. That folder IS the Apple application bundle and it contains an executable module Together with all the necessary resource files. Mac OS X users need that folder as it is ( of course without the svn stuff )!

     

    And yes it can live in any folder provided there is the darkmod/ resource folder is its parent directory (which should also contain "base/" with D3 resources). For instance it can live in the directory named darkmod containing all the TDM resources.

    This is the result of my changes to the meanings and setting of fs_* variables, according to your note #35 above.

  16. Yes, that's the way archlinux works so the user should know that this can happen.

     

    @malex984:

    I'm pretty sure there is a problem in the xml parser. I ran the editor with a debug build of the library. It actually parses the documents but it seems to me that the result is not written to the tree structure. I'll try it again tomorrow.

     

    xml parses xml files alright (i even saved them temporary again while debugging) but afterwards they will not be added to user/system trees as i described in http://forums.thedar...post__p__296223

×
×
  • Create New...