Jump to content
The Dark Mod Forums

PrinzEnrique

Member
  • Posts

    16
  • Joined

  • Last visited

Reputation

4 Neutral

Contact Methods

  • Website URL
    https://dollarblogname.wordpress.com/

Profile Information

  • Gender
    Male

Recent Profile Visitors

432 profile views
  1. Did you get the same results for the 2.0.4 and 9999 ebuild? Could you send me your output from "emerge --info"? In general, I only check this forum every once in a blue moon to see if I have to fix or update the ebuild. If you want an immediate reply you should send me a PM.
  2. No worries you are the first to give detailed feedback anyway. I expected some deps to be missing because I just added them by watching configure and trying to build. About the metadata, well I don't really care about that for local ebuilds. I would have included metadata with a public overlay but I don't intend to make one.
  3. Updated ebuilds and patch for Gentoo: ebuild for 2.0.4 ebuild for git current patch for both Instructions are still the same
  4. Hm nearly missed this release. For that one other guy who uses Gentoo around here: version bumped ebuild and updated patch ebuild for 2.0.3 Gentoo patch for 2.0.3 Instructions are still the same as for the older ebuilds
  5. But maybe it won't. Or maybe the team just does not have anybody capable of doing the not-so-fun things. These not-so-fun things are the bane of all FOSS projects and the reason why most critical projects end up getting money involved. there are many projects out there with paid and volunteering contributors so I don't think that kind of general statement is true. still it's true money will affect the motivation of people involved but there are many different ways to use money. you don't have to hire someone as a team member to do work 9to5 on the project. you could use it for specific services like external code reviews (yeah i doubt that's really relevant for TDM/DR it's just the most obvious example) or maybe bug bounties. agreed to everything else. btw. i'm not saying TDM should start using money. if the team did think this through and decided against it then stick with it. i just felt some statements needed a counter-argument
  6. same problem here ... at least i think running on Gentoo Linux tried with both 2.0.1 and 2.0.2 OpenGL renderer string: Mesa DRI IntelĀ® Haswell Desktop OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.8 no gallium at all
  7. ebuild for properly installing DR 2.0.2 on gentoo the patch for gentoo is still needed short explanation how to use the ebuild: http://forums.thedarkmod.com/topic/16686-darkradiant-201-released/?do=findComment&comment=358382 should i start a separate thread for the ebuilds so i can write a proper instruction to these and just add new ones with each release? is there even a demand for DR on gentoo???
  8. it should only be needed on Gentoo and maybe Funtoo as they handle python installations a little differently than binary distributions.there might be a generic approach for the build system to make it work on every distro without a patch but my knowledge of build systems and coding in general is pretty limited.
  9. Not a serious bug ... more like an annoyance but ever since I got it built for the first time DR would always show version 1.8.0 in the about dialog. Also the shared objects are getting the version suffix 1.8.0... don't know if this is intended it just seems odd. /usr/lib64/darkradiant /usr/lib64/darkradiant/libdds-1.8.0.so /usr/lib64/darkradiant/libdds.la /usr/lib64/darkradiant/libdds.so -> libdds-1.8.0.so /usr/lib64/darkradiant/libmath-1.8.0.so /usr/lib64/darkradiant/libmath.la /usr/lib64/darkradiant/libmath.so -> libmath-1.8.0.so /usr/lib64/darkradiant/libpicomodel-1.8.0.so /usr/lib64/darkradiant/libpicomodel.la /usr/lib64/darkradiant/libpicomodel.so -> libpicomodel-1.8.0.so /usr/lib64/darkradiant/libscenegraph-1.8.0.so /usr/lib64/darkradiant/libscenegraph.la /usr/lib64/darkradiant/libscenegraph.so -> libscenegraph-1.8.0.so /usr/lib64/darkradiant/libwxutil-1.8.0.so /usr/lib64/darkradiant/libwxutil.la /usr/lib64/darkradiant/libwxutil.so -> libwxutil-1.8.0.so /usr/lib64/darkradiant/libxmlutil-1.8.0.so /usr/lib64/darkradiant/libxmlutil.la /usr/lib64/darkradiant/libxmlutil.so -> libxmlutil-1.8.0.so
  10. I wrote ebuilds to properly install DarkRadiant on Gentoo including a patch to circumvent this issue. I planned to post them for 2.0.0 but as I couldn't get it to build I waited for the next release that worked. Apparently I am not allowed to attach plain text files so have some links instead ebuild for 2.0.1 ebuild for git patch for gentoo The ebuilds go into *local-overlay*/dev-games/DarkRadiant/ and the patch into *local-overlay*/dev-games/DarkRadiant/files/ then manifest/digest the ebuilds. But I guess most Gentoo users should already know how this works. There's one issue though. It looks like audio support is optional. At least configure has no problem with missing OpenAL or alut and just disables building of audio. Still I couldn't find a configure option to enable or disable audio support. If audio is optional I would like add a proper USE flag for audio to the ebuild which needs a configure option.
  11. fails to build on Gentoo currently make[3]: Entering directory '/home/prinzenrique/Programs/source/DarkRadiant/plugins/eventmanager' CXX Accelerator.lo CXX Modifiers.lo CXX Statement.lo CXX EventManager.lo CXX MouseEvents.lo CXX Toggle.lo CXX WidgetToggle.lo CXXLD eventmgr.la .libs/EventManager.o: In function `EventManager::initialiseModule(ApplicationContext const&)': /home/prinzenrique/Programs/source/DarkRadiant/plugins/eventmanager/EventManager.cpp:65: undefined reference to `ui::GlobalKeyEventFilter::GlobalKeyEventFilter(EventManager&)' collect2: error: ld returned 1 exit status
  12. First time I could get the sources from your repo built on my Gentoo. So I guess that counts as better
  13. great FM. the sudden fade out ending was a little anticlimactic though. I was totally pumped and prepared for something scary and then it was over. don't have to say anything about the first part that hasn't been said already. good work
  14. Just the non-standard loot alone wasn't that much of a problem. It was a combination of them with their hiding places and the mission story. If they were hidden in one of the guest rooms I would've probably found them but I was not checking every nook and cranny of the upper hallway, the innkeepers office and outside the inn. I thought why should loot outside the inn be relevant to the inn's reputation.
×
×
  • Create New...