u/goodwarrior12345

Hi everyone! I'm trying to make a control panel of sorts where you click or press an interact button while looking at a control element and the control on that element moves depending on where you were looking. Here's an example.

In order to do this, and to avoid doing computations in world space, I first convert the trace impact point into local space using this logic, and then use the local space version of the impact point to do further calculations. This works perfectly fine if I just place my blueprint into the level.

However, if I then put that control element inside another blueprint as a Child Actor Component, my logic starts working all weird, and I can't see a reason why it would do that. When I look at the debug info, it seems like my World to Local macro does absolutely nothing to the point when my slider is located inside another blueprint. Why is that? And what do I do to work around this? Is this even the right way of doing what I'm trying to achieve - determining where exactly on the object the trace hit?

Thanks!

Hi, I've been losing my mind for a while now trying to get this to work and it still doesn't, so I decided to try and ask here in case someone here has already gone through the rigamarole before me. This post is probably going to be pretty long - sorry about that, but I just want to write down everything I've tried so far to better diagnose the issue. I have a project I'm working on mainly on my Windows machine that uses C++23 and C++ modules, and I also use the standard library with import std; and import std.compat;. My build system is CMake and, if it's of any relevance, I use CLion. On Windows with MSVC everything works without issues.

However, I'd also like it to work on my M1 Pro Mac. This is where issues start to arise, because as it turns out, while LLVM's Clang ostensibly has module support, Apple Clang is not the same thing, and doesn't support them. Online resources say I have to install LLVM's Clang to make it work. Fair enough, so I did that. However, I'm still having issues.

I set up a test project to diagnose the errors. It's as simple as:

import std;

int main() {
    std::cout << "Hello, World!" << std::endl;
    return 0;
}

And then I have a CMakeLists.txt file that looks like this:

cmake_minimum_required(VERSION 4.2)

set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "451f2fe2-a8a2-47c3-bc32-94786d8fc91b") # 4.3+
set(CMAKE_CXX_MODULE_STD ON)
set(CMAKE_CXX_SCAN_FOR_MODULES ON)

project(untitled)

set(CMAKE_CXX_STANDARD 23)

add_executable(untitled main.cpp)

So right off the bat, CMake fails on scanning for module std, which seems to be an LLVM bug (or a CMake bug?), as running the sed script I found here fixes it. If I run it, however, and try to build with CMake again, I get this error:

: && /opt/homebrew/opt/llvm/bin/clang++ -g -arch arm64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/untitled.dir/main.cpp.o -o untitled  lib__cmake_cxx_std_23.a && :
ld: archive member '/' not a mach-o file in 'lib__cmake_cxx_std_23.a'

Notably, this error persists even if I replace import std with #include <iostream>. I have no idea what's happening here. Well, apart from the fact that it's a linker error, but I haven't really found a way to deal with linker errors like these in CMake's documentation yet, and even if I did, the error itself is really cryptic. If I compile it from the command line with the header included, it compiles and runs fine. With importing the std module it doesn't, but if I precompile the module and use it in the compilation prompt as described here, it works. Problem is, I have no clue how to get CMake to do the same. I tried looking it up but haven't found much.

The other thing is std.compat. I need it for my "main" project because it includes things like <cstdint>. It's not like I couldn't use headers for this, but I'd rather avoid mixing headers and modules if I can help it. If I try the same command as in that Wordpress article on std.compat, it fails to compile, saying "module 'std' not found." Not really sure how to fix that. I briefly tried installing GCC and seeing if that would help, but using that gave me strange compilation errors, so I dropped it.

So that's the test project. The main project, rather than failing to link when building with CMake, fails to compile instead. I get this error stemming from me using std.compat in one of my files:

In module 'std' imported from /opt/homebrew/opt/llvm/share/libc++/v1/std.compat.cppm:84:
/opt/homebrew/Cellar/llvm/22.1.6/bin/../include/c++/v1/__new/allocate.h:39:30: error: call to 'operator new' is ambiguous
   39 |     return static_cast<_Tp*>(__builtin_operator_new(__size, static_cast<align_val_t>(__align)));
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/homebrew/Cellar/llvm/22.1.6/bin/../include/c++/v1/__memory/allocator.h:92:19: note: in instantiation of function template specialization 'std::__libcpp_allocate<EventListener *>' requested here
   92 |       return std::__libcpp_allocate<_Tp>(__element_count(__n));
      |                   ^
/opt/homebrew/Cellar/llvm/22.1.6/bin/../include/c++/v1/__new/global_new_delete.h:49:54: note: candidate function
   49 | [[__nodiscard__]] _LIBCPP_OVERRIDABLE_FUNC_VIS void* operator new(std::size_t __sz, std::align_val_t) _THROW_BAD_ALLOC;
      |                                                      ^

Again I have no idea why this could be happening, or how it's even possible that there's an issue with compiling standard library functionality.

So my question is, how do I fix all this? Has anyone here gotten C++20 modules and std module specifically to work on a Mac? This has been so unbelievably frustrating to deal with, with all the strange, opaque errors that make seemingly no sense, and not much in terms of solutions from what I've found online. I can't get rid of std modules in my main project, either, because one of the libraries I'm using depends on it. If anyone here has any suggestions besides just ditching modules completely, I'd greatly appreciate it!