Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Days Won


Everything posted by greebo

  1. Yes, please do upload them somewhere, or even better open an issue on the bugtracker and attach the files.
  2. Well, I guess so. If the wxGTK package on Ubuntu was using g++7, then there's only two possibilities: either downgrade the compiler used to build DarkRaidant to g++-7 (that is using ABI 1011), or recompile the wxGTK package for your system manually using the newer g++-8 compiler.
  3. Yeah, it should. Maybe that env hack is not working, is this post helpful? https://askubuntu.com/a/1028656 Especially the command here about choosing the default: sudo update-alternatives --config gcc
  4. Maybe try setting the compiler via the environment before running the build: CXX="g++-7" ./configure --enable-darkmod-plugins && make -j3 && make install Something along these lines.
  5. I think it's the other way around, the wx packages provided by Ubuntu were compiled using the 1011 ABI, whereas you used a newer compiler to build DR. Which gcc version are you using, and is it the one from the default Ubuntu apt package? I guess you can do two things: Either downgrade the compiler to some that is using ABI 1011, or recompile the wxGTK package for your system manually using the newer compiler.
  6. The camera speed is adjustable, I think the default shortcuts are the +/- keys on the numpad. The assignable commands (see Edit > Shortcuts...) are called CamIncreaseMoveSpeed and CamDecreaseMoveSpeed.
  7. I guess this should be feasible. Though I don't know how much work it actually is.
  8. I need to see your Game Project dialog to see the paths you're using (engine path, mod path etc.). Maybe DR is missing something to generate useful paths to write to. (Generally spoken, saving to some folders in Windows requires higher privileges, that's not something DarkRadiant can change. If that setup is problematic, maybe moving your stuff to different working locations might resolve the problem.)
  9. The script needs a syntax fix, it's due to the changes necessary after migrating from boost.python to pybind11. In Line 124 ase_export.blend.py add the "dr" namespace to the AABB type: ab = dr.AABB(origin,origin-origin) If you could open an issue on the tracker, I'll go ahead and fix it in the repo.
  10. I can confirm that problem, it seems there are a few events not handled by the respective windows. Please report this on the bugtracker.
  11. No no, of course the duplicate removal would only apply to vertices of one distinct surface.
  12. Looking and investigating this a bit, I can see a few problems. First, brushes and patches are saved as independent tris, each of them made up of 3 verts. Lots of duplicates, no smoothing. A probable solution for me would be to add an option to "Remove Duplicate Vertices" to the model exporter. Actually, I had this in one of the early implementations of the exporter code, but this caused problems as far as I recall, so I took it out again. As long as it is an option, I see the decision transferred to the mapper. Second, the bottle problem Spooks is noticing. I ran a few tests, and the model exported by DarkRadiant is actually different to the bottle02.lwo source model. The vertices at the bottle neck (where the sharp edge is visible) are split up, so the polys below and above the bottle neck are using separate vertices. I tried to track down where this happens, and it appears that these vertices are already split up when DarkRadiant initially imports the source LWO. You can see it when switching to Lighting mode in DarkRadiant - the bottle02.lwo model also has this sharp edge around the neck. I can try to look into the original LWO importer code (which has been present in several Radiant variants for ages) and see why it's producing such duplicated verts. It's possible that the proposed "remove dupes" option mentioned above might actually fix this problem alongside, but fixing the importer might also be a worthwile goal (if it is broken in the first place).
  13. I performed these steps to check the smoothing: Open a testmap in DR with a light or two Create Model models/darkmod/kitchen/bottle02.lwo Duplicate the model and move it to the left Select the duplicate, hit File > Export Selected as Model... Output Format: LWO, path: C:\Games\darkmod\models\bottle_test.lwo Center Objects around origin Replace selection with exported Model Click Export I now have a func_static with bottle_test.lwo assigned in the "model" spawnarg Open TDM, dmap the testmap and run it. The cloned bottle appears smoothed for me: (The left one is the cloned one.) There must be something we're doing differently? edit: note that exporting brushwork or patchwork might not automatically give you smoothed results. If the source geometry consists of separated vertices the resulting surface is not smoothed, which is usually the case when exporting brush/patchwork. When exporting surfaces coming from existing LWO / ASE models (created in proper modeling software), these surfaces are preserved and thus the smoothing.
  14. I'm looking at this older entry on the tracker: http://bugs.thedarkmod.com/view.php?id=2727 I'm wondering what most of the active mappers think about this. Should selecting a material in the Media Browser make this the default when, for instance, drag-creating a new brush? Currently, the selection in the Texture Browser tab defines the default material. Should the Media Browser selection used instead? Or should selecting a material in the Media Browser also select the material in the Texture Browser?
  15. DarkRadiant 2.6.0 is ready for download. This feature release is further improving on the Model Exporting capabilities and introduces smaller features like a mapping time stopwatch and the ability to define favourites in the Media Browser, making it more convenient to work with a large number of materials. On top of that, this build offers a number of fixes and improvement for various parts of the editor. It's recommended to prefer this version over any previous release. Windows and Mac Downloads are available on github: https://github.com/codereader/DarkRadiant/releases/tag/2.6.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask.If you run into a crash, please record a crashdump: Crashdump InstructionsFeature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker.Changes since 2.5.0 Add a stopwatch tracking your mapping timeMake The Model Exporter Respect The "skin" Spawnarg On ExportExport patches and lights/func_statics to OBJFixed: Particle Editor Doesn't Save Colour/Fade ColourFixed DR not remembering location of child windows when placed on any non-primary monitorFixed: Re-exporting .ase models screws up their normalsFixed: Export Selected as .LWO Model: Exported models loose smooth shading after export.Fixed: DR shouldn't write *.darkradiant files when creating a prefabFixed: CSG Make Room operator does not fill the room on 3-edge prism caseFixed: DR doesn't show readable background image changesFixed syntax error in OBJ export scriptFixed: Grid size number format in status bar is showing unnecessary post-comma zerosFixed: Undo after changing func_static entity classname results in lost child primitivesFixed: Changing entity class from the spawnargs moves it to the Active LayerThe list of changes can be found on the our bugtracker changelog. Have fun mapping!
  16. I'm planning to release it in the next few days, so if there are any showstoppers, let me know. Minor bug fixes will probably go into the next release anyway.
  17. I've pushed the above two patches to git master, they were enough to get DR to compile and start on my end (VM Ubuntu 17.10).
  18. It depends what you specified when configure'ing and make'ing your wx 3.1.2 package, but obviously the 3.1.2 installation is taking precedence over the Ubuntu-provided 3.0 package. To prevent this, you need to forcedly direct DR to use the 3.0 variant with the --with-wx-config switch. edit: just tested this, when installing the 3.1.2 version, the wx-config symlink seems to be overwritten, so I don't know if it's even possible to instruct DR to use the 3.0 headers and libraries (which are still there but probably useless after installing 3.1.x). Scratch all that, I see there's the 3.0 wx-config still present in /usr/bin/wx-config, so for the records, passing --with-wx-config=/usr/bin/wx-config to configure should direct DR to use the 3.0.x installation. Anyways, I'm definitely interested in compatibility with 3.1.x, so I'll check out what fixes are necessary to get it to compile. Regardless, here's another patch concerning your latest error in PrefDialog.cpp. I'll attach both files here, rename them to .patch. You probably don't need the first one, as you probably already applied it. 0001-Fix-for-wxWidgets-3.1.x-where-the-wxDataViewEvent-si.patch.txt 0002-Fix-missing-include.patch.txt
  19. Here's a patch which should be applicable to your DarkRadiant git master. Rename the file to .patch and apply it. Let me know if your compilation succeeds after that change. 0001-Fix-for-wxWidgets-3.1.x-where-the-wxDataViewEvent-si.patch.txt
  20. Do I get this right that you have two variants of wxWidgets installed on your system? If there is a stable 3.0 release on your system, there should be a corresponding wx-config binary lying around somewhere, and you can point the configure script to use that wxWidgets variant: ./configure --with-wx-config=/whatever/path/to/bin/wx-config If that doesn't work, it's also possible to compile a 3.0.x wxWidgets for yourself, take a look at the openSUSE section on the wiki, it should work for your end too. Apart from all of this, I'd need to check whether the wxDataViewEvent signature has been changed in 3.1.x. I had been using 3.1.x for the Windows build until a few months back, so in principle 3.1 should work just as fine - but maybe the wx team actually changed that signature. edit: yes, in wxWidgets 3.1.x the constructors have been changed. I can take a quick look how problematic it is to adjust it in DarkRadiant.
  21. That's good to hear, thanks for the confirmation. I have another pre-release build ready in the first post (pre5). I don't have any more fixes planned (apart from those stabilising this release), so if you folks could give this another final run, I will wrap up 2.6.0 for release in the upcoming days.
  22. Ok, that's kind of good to hear that this was the same crash reason for all of you. I got this one fixed, I'll prepare a new pre-release build soon. edit: a new build is available in the first post.
  23. I can reproduce your crash, @HMart, it is connected to the "Load last map at startup" setting. I think I can eliminate this one with some time. @grayman: Not sure about how to repro yours. I see the application is crashing on processing Idle events, which might have to do with some stray pointers left behind. Can you give me more details about when it's crashing? Is this right after the app is started and when it's supposed to display the empty Camera and XY views? Or did you manage to load a map or open any windows?
  24. Thanks for the dumps, people, this is appreciated.
  • Create New...