Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16733
  • Joined

  • Days Won

    51

Posts posted by greebo

  1. 12 hours ago, Dragofer said:

    When going back and forth in undo history, a mapper might want to inspect various entities i.e. to check the current values of their spawnargs. Selecting something would discard the redo history. This is generally different from a modelling program, where seeing selected verts is usually enough.

    This is exactly the use case I had in mind that got me to open this thread and ask. I recently moved back the undo queue to select an item I had deleted earlier, selected it, copied it to the clipboard, then redid all the steps and pasted the item into the map. A move like this is no longer possible when the redo stack is cleared by selecting the item.

    But then again, I'm used to selections being undoable from Blender, where this is quite a time saver. It's very easy to mis-select a vertex when moving fast, and being able to remove those wrongly selected items by hitting Ctrl-Z is really nice.

    12 hours ago, Dragofer said:

    Also, we already have the selection group system as a way of saving and later returning to an earlier selection. Would just be good if it were easier to modify the nodes in a selection group without having to dissolve the whole group and later reselecting everything (basically 'Select Group Parts' for selection groups).

    For this one feature I'd be interested whether anyone is using it at all - are many people using selection groups in their maps? I found it less useful myself, and the workflow is clunky, having to think of a name for the group before saving. - edit: scratch that, I've been thinking about selection sets here.

  2. I'd like to get some feedback about this old feature request, before I start working on it. What do mission authors think, would it be beneficial to have the selection status be included in the undo/redo operations? Like, you select two items, and by hitting Undo the most recently selected item is de-selected again (hitting undo again will proceed to de-select the first one).

    Thoughts?

  3. 1 hour ago, coldtobi said:

    One thing that might work is to re-normalize the git repo before doing a release:  (requires * text=auto in .gitattributes)

    $ git add --renormalize .
    $ git status        # Show files that will be normalized
    $ git commit -m "Introduce end-of-line normalization"

    (Stolen from https://git-scm.com/docs/gitattributes)

    Yes, I came across the same page. I'll try to do that some time and will try to keep it in mind before the next release.

  4. Hey tobi,

    with tarball, are you referring to the sourcecode.tar.gz in the Github releases page? If so, this file is automatically created when I click "publish" on a new release in Github, I cannot influence its contents.

    I'm not even sure I placed .gitattributes myself in the repo - I believe my local Git client is already configured to commit Unix line-endings only, but will check out CRLF-style locally. So I could live with removing the .gitattributes file from the repo, I don't need it personally. I can also offer to fix the count_loot.py file or any other file you report to me as faulty.

    8 hours ago, coldtobi said:

    or making sure that line endings are OK at the time of push/commit  (maybe using some git hooks) -- disclaimer: did not research if that is possible/feasible

    I would have guessed that the .gitattributes file should do exactly that, but maybe it's only working in the check-out direction, not when committing files.

    @OrbWeaverWhat's your take on that, do you prefer that .gitattributes file staying under version control?

  5. 1 hour ago, CodeLikeCXK said:

    I see, so if I could find windows arm64 version for them, how should I configure the compilation for it?

    Sorry, I'm afraid this question is too vague for me to answer. It's all about the VC++ solution, if you intend to use Visual Studio. All the dependencies need to compile against that new platform, the produced binaries can then be linked with the main application and DLLs.

  6. DarkRadiant's main codebase is not relying on any intrinsics as far as I can recall right now, it's generally kept very close to the C++ standard for portability reasons. Third-party libraries like Eigen might use platform-specific stuff, but I assume they are portable as well.

    It all comes down to whether the third-party dependencies provide a port to the platform, these are some of them:

    A problem might be the openGL version that is supported on your target platform. There could be some openGL API calls in DarkRadiant that may cause troubles.

    • Like 1
    • Thanks 1
  7. @datiswousCan you try to open the file gl/zfill_alpha_vp.glsl and change the version check in the first line to 130 instead of 140? It's possible that GLSL 1.30 is good enough, it worked for me locally at least.

    #version 130
    
    in vec4 attr_Position; // bound to attribute 0 in source, in object space
    in vec4 attr_TexCoord; // bound to attribute 8 in source
    ...

    I think the interaction glsl files might have a similar check in them, maybe you'll run into the next file - you can try to do the same change there.

    About hat GLSL version, I remember checking the version history, and GLSL 1.40 was released somewhere around 2009? I have been thinking I'm pretty much on the safe side here, but maybe I've been wrong about this.

    • Like 1
×
×
  • Create New...