I think no one is gonna say no but you can create a poll on your twitter to be sure 
I say do what makes most sense for the long term progress of the project. Focusing on PC for now seems like a good choice.
Hi, Mikayla, I’m so glad to see you back on online. Yeah, that’s pretty awesome result! I hope you get some reimbursement from your work. If not, it will still pay-off in a long run to shave off your idle time. ^^ I haven’t clocked my duel E5 with 56 cores but I’ll try to time it when I start using Mono-UE again. I bet it will clock substantially under 10 minuites. I bought it in preparation for UE4 but I haven’t set it up yet. I bought used E5 cpus and it was very cheap compared to brand new chips. If some one interested in building very cheap muti-core machine, I’ll share some more info. I would be more than happy to see focusing on Windows and get the ball rolling first and then support Mac later on. Honestly, I bet there more 10 times more users on Windows than on Macs and I wouldn’t want that to be a reason to hold us back. Cheers!
@ChrisK I’m certainly curious, I hadn’t considered Xeons. I have a watercooled ThreadRipper 1950X (I upgraded my personal home machine, which I also using for gaming) and I haven’t even tried to overclock it yet…
Sure, I’m glad that you are interested. This is what I used. E5 2680 V4. You can find them around $350 a pop on Ebay. From what I researched, it give you the most bang for the buck. And I also bought Gigabyte MD70-HB1 MB around $300 and the total system cost me around $1500 including Rams. It was quite a beast for multicore machine but the single core clock speed is less than desirable. I bought it for compiling and baking basically. I’ll try to set it up properly and let you know how it performs once I have a chance. Cheers!
@ChrisK wow, yes, that’s some pretty serious bang for the buck. Mine’s my main personal machine so I was also shooting for decent single core perf and stuff like usb-c, rgb lighting and water cooling headers… but I’m almost tempted to build one of those as a build bot
I like this I have been wanting to revisit C# for a long time now the fact that the engine lacked C# kind of made the engine for me too Blueprint dependent and that’s not good for performance.
Also will this have a 4.18 version any time soon? what I really like about 4.18 is that is now has support for Visual Studio Code and since its very light weight its much more preferable for me so I can get scripting with it right away.
@ErnestoEFL I plan to update to 4.18 as soon as it has a stable release.
Never mind I stopped caring about this it didn’t work at all.
Great idea C# in UE <3
Are you kidding… Killing the Mac version (even for a little while)… You just killed my little project.
Hi, Mikayla, it’s been a while since I made the first post but I’m really worried about the current status of the project. I keep on fighting whether I should go with Unity or not. Unity, like I said, I’m not really happy about their progress improving their editor but on the other hand, UE4’s doesn’t give you good programming environment. You are stuck with arduous C++ or messy Blueprint. I was really hoping that Mono-ue will solve my problem but the wait is too long and nothing much has been done since the initial release. Of course I know that it’s your pet project but it makes me to worry that Mono-ue is not getting enough love from you. I tried to be patient but please allow me to ask you the following questions. It will help me to make my decision and to move forward.
- What is ETA of hot-reloading?
1.1 Does this hot-reloading support runtime-hot-reloading(with some limitation, of course)? If doesn’t support runtime-hot-reloading, it only save little more time compared to the current c++ hot-reloading and significantly reduces the benefit. C++ can support edit-and-continue in some sense.
- When debugging is supported, can we debug c# and c++ code from a single Visual Studio IDE debugging session? I hope I don’t have to switch between c++ and c# sessions or to have two debugging sessions to debug c++ and c# simultaneously.
I guess I can wait little longer but above questions are crucial for me to wait.
Cheers!
Hallo Mikayla
First of all , thanks for the great effort.
2nd, I want to help out. But it’s hard to sift through the diffs on Github, so can you give me a short explanation on the engine changes and why they’re needed? I did some work on klawr (and got it even working for 4.13 iirc, though the limitations and speed drop from the COM related stuff made it quite hard to work with). Klawr didn’t need any engine changes, so i’m curious how you get the bindings done.
Rgds
algorithman
The simple answer is that we’re integrating deeper and doing things that other integrations aren’t doing.
The main things are patches to allow us to integrate into the build system, the garbage collector, the input binding system, and the code navigation system. There’s also a few bugfixes and minor cleanups.
You can see the 4.17 patchset at https://github.com/EpicGames/UnrealEngine/compare/release...mono-ue:monoue-patches-4.17. Note that a bunch of these have been upstreamed in 4.18 (and we also upstreamed a few patches into UE4.4 years ago).
It won’t be for long!
The key thing I’m working on right now is simplifying the project format to the more modern “sdk style” csproj format. This will allow a MonoUE project to be as simple as <Project Sdk=“Mono.UE4.Sdk” />, and will be it much easier for me to write a Visual Studio extension. You can see this in progress at https://github.com/mono-ue/UnrealEngine/tree/sdk-style-projects. The tricky part of SDK stype projects is that it requires implementing an MSBuild sdk resolver extension that installs into MSBuild itself. And doing that on Mac will be extra tricky until the 15.5 release of Mono.
The main branch has been quiet while I’ve been working on this branch… once I merge it, main should pick up again. I’ve also been travelling to conferences recently so haven’t had much free time to work on it… that will be changing soon
I’d say a month.
Can you clarify what you mean by “runtime hot reloading”?
This won’t be supported… it’s technically very difficult.
Thanks for the link, much easier now
Runtime hot-reloading means, reloading while game is running, without pressing a stop button from the editor. It was advertised as one of the key feature while back.
The current c++ hot-reloading requires you to stop the game and restart.
A normal project mixed with C# and C++ allows you to trace in/out of C# and C++ code from a single debug session. I wonder why MonoUE would be difficult to support such feature. How would you then, trace into C++ code starting from C# or vice versa? Do you have to have two debug sessions running, one main session and one other session attached to the process? I haven’t work this way before and I’m not sure if it will work well. Or, start a single C# or C++ session and switch to other session if you want to debug the other language? If we have to switch, it will probably means, we have to restart the Editor and it will be against the productivity quite a bit.
Cheers!
Oh yeah, we absolutely supported that before. I thought that was was “hot reloading” meant I should be able to get it working again unless something fundamental in the engine changed.
This uses the Mono runtime, so the .NET/C++ mixed mode debugger can’t be used with it. The Mono debugger doesn’t support mixed mode debugging.
You should be able to attach the C++ debugger once the Mono debugger is connected, and stepping and breakpoints in either language should work - you just won’t be able to step *between *languages. It might be possible for the VS extension to attach both debuggers automatically, I just haven’t looked into it. There are also some gotchas - the managed debugger will be unresponsive while the native debugger has paused execution, as parts of the managed debugger run in an agent in the debuggee.
That’s great! This is one of the important feature I’m looking forward. Debugging network game is really painful if you have to restart everything to have the changes to take affect. ^^
Sure, it looks like I’ll have to open two instances of Visual Studio open to code and debug but it’s the compromise I can live with as long as I don’t have to restart the editor. I hope one day the limitation will be lifted.
Cheers!