The Mono Project likes scripts. Does Epic Games?

everything BoredEngineer has posted, especially
'Regardless of that, you are suppose to be able to learn new tools and workflow to do your job. This is something that you find as requirement for any technical position in the world. ’
[/QUOTE]

cause… we are… customers?
ofc if you prefer using Skrokum and adding into that all the .net features great but wouldn’t be just more expensive and less rewarding (even just in terms of popularity and accessibility)?
[/QUOTE]

Just want to point out, @ that from our perspective you are asking development time from Epic which could be directed to solving any number of actual issues with the engine to instead go towards implementing C#. If C# comes to Unreal I’m sure we will all test out the integration, but at the end of the day most of us would rather have a bug, for instance variables being reset to parent default on BP child classes in levels (or even in the child class editor), fixed rather than having C#. [Nothing like having to have a BP class for every single different instance of an actor in your level just because a value is reset to default no matter what.]

You may be a customer, but we’re all paying exactly $0/month (at least if you aren’t making money from a UE4 game) for access to this tool. I am a ‘customer’ too, so my voice counts as much as yours. If an EPIC dev replies to this thread with ‘Hey , we’ll start on this on Monday’- I can’t complain. I have no more priority to the dev team than you do. The bug I mention must, actually, be more complicated to fix than C# is to implement, because this has been in the engine for nearly (or over) a year with no fix despite people trying to fix this. Maybe it’s just user error. However, Epic have actually said no to C#.

As for your challenge to implement a reverse for loop in BP?

C++ @



FString FinalString = TEXT("");
for (int32 Idx = Array.Num() - 1; Idx > 0; Idx--)
{
	// Move on if it's not even
	if (Idx % 2 != 0)
	{
		continue;
	}

	FinalString = FinalString + Array[Idx];
}


Blueprint Macro


Actual Function (as a macro)


If you were smart and wrote the base function in C++ and call from BP


So yes, it IS messy, and takes up more room than it should. Surprise, surprise. But take a good look at that final image. This is what it should look like to take a string array, reverse its order and concatenate it into a single string in BP. Why? Because this would be making use of UE4. All of UE4. The function is easier to write in C++, so write it there and call it from BP. All the power of C++, all the visual aspect of BP.

sorry Brian, I didn’t recognize you.

debugging experience (how do you debug an optimized code?)

no **** sherlock, but C# like Java intellisense will always be faster than C++ intellisense, same for compile time.

and visual studio is just a text editor, don’t use it.

you know of.

Make a try, then you will be able to finish that highschool project and finally get a degree.

And instead I will still use it whenever I want! how does it make you feel?

That’s why you should never have a second child, cause it will derive your mother’s attention.
It makes sense, if you are a little boy.

after spending 20 minutes on painting a picasso we are still at the starting point. compare C++, blueprint and C#. C# is still missing, how can you compare it?

Well it’d seem the only one throwing a tantrum is you, so we can assume you’re the 2 year old.

If you can’t be bothered to show a C# example, why are we expecting Epic to actually integrate it?

Also, I’m so sorry I tried presenting a clean Blueprint- perhaps I should revise it just for you.
67a49d97d5255fb9ce12d914a8fa42b3.png

var whatever = //find me the type
await // return the execution to the caller immediately
world //world context
.Players
.where(p => p.Age > 20 || p.Age < 60) //filter by age
.where(p => p.Age % 2 == 0) //filter again
.OrderByDescending(p => p.Name) //Ordering
.SelectMany(p => p.EnemiesInSights) //select the property that you want from all the players and merge them together
.where(p => p.Life > 40) //filter it
.select(p => new { Life = p.life, Name = p.name } //make an anon object (non previously declarated)

//Groupby (equal to a Distinct in this case)
.groupby(p=> new { Life = p.life, Name = p.name })
.select(p => p.first())

.asQueryable()/.asEnumerable() //I don’t want to execute it right now, maybe I will return it so I can do more filtering and I can give the compiler a to optimize even more
.ToListAsync() //execute now async and return me a list of objects with all the related methods

.configureAwait(false) //do not wait for synchronize with the original context

//foreach in parallel
Parallel.ForEach(whatever, p =>
{
p.sendsomething();
});

your turn now.

IMO, that’s objectively just wrong though.

Either way, I’d rather Epic focuses on other areas of the engine instead of diverting resources towards this. We already have two really good languages and there are other more important things that need attention. Again, all my opinion. Anyway, C# users still can use C# in Unreal if they want to, it’s just not officially supported.

EDIT: Also that C# example above, as a non-C# user - makes little to no sense to me at all. C# is great for some but not others, same as any language.

A question to the OP and other C# supporters - how much time have you realistically invested in using C++ with the engine. Have you gone start-to-finish with a project for example?

@: They probably spend all their free time arguing about C# :rolleyes: No time for real projects when heated C# debate is still ongoing!

Thinks are defined by what they do. Although headers ain’t the only part of C++. Headers are still genuine useless trash… And sadly, they are also a fairly big part of C++. So…

Seriously? C++ is only made of headers? And at least half of that what makes C# great in the first place, it didn’t even inherit from C++ in the first place?

Cool, I’m done talking to you… Unless you can explain to me why it is a bad idea to create a hybrid to have everything we want inside one package.

There is no C# for UE4. The download for UE4 C# 4.5 ain’t available anymore… And that’s some 4.5. Probably even unfinished.

Have you ever asked yourself, that a native C#, may actually be something even someone like Epic Games might want? Or, if M$ just made a native C#, that it could do the same to C++, that C# did to Java? A native C# and a managed C# combined into one language, is even worse to Java and C++, because it would be one hammer with one swing but double the damage! It wouldn’t even need a new programmer community for its managed side, because all the C# programmers just could come flocking over enjoying a familiar yet more powerful language.

I vote for imperialistic superiority! Now, where is Micro$oft’s Death $tar?

I hate you… -.-

Signs Out from the Epic Games forum

Signs In to the Epic Games forum

But actually, I was talking about a hybrid, really…

Signs Out from the Epic Games forum

Try to keep this thread on topic guys. We have no problem with a heated discussion, but keep the focus on the at hand and refrain from making things personal between yourself and the person you are replying to.

We want to keep this discussion open, so please keep it civil.

Thank you.

+1!
I could really not understand, why ppl do not discuss in peace and harmony together?
Unity has a nice logo and the UE4 logo is impressive too.

For Unity a BP solution(similar) exists in the Unity store, you can buy even complete game templates there.
Some of the Unity templates use the new Unity BP system.
UE4 has an impressive Marketplace too and there you could buy cool stuff too.
But no BP scripting system, because it’s still implemented.

Blender has a cycles nodesystem for years too.
Not really similar to the BP scripting node system, a bit more like the material editor nodes.
Blender uses phyton for scripting and ppl questioning for decades now, to get a phyton / java / c++ translator.

Why we not be warm and friendly and add c# to the wishlist?
These multitranslatingtools would be, what we indiegamedevs could need well!
Jumping between applications and pasting universal scripting nodes in CorelDraw(for example), to setup and calculate some vectors(2D), for testing and when everything works, then Strg+c, open UE4 and then Strg+v and everything works like expected.
That could be good for timemanagement, if you ask me.

For translating stuff between single languages, lilke c# and c++ are tools out there since years.
Perhaps there is a nice coder out there, to integrate it inside UE4. https://cscpp.codeplex.com/

https://varycode.com/img/code_conversion_conveyor.png

Theoretically it would make more sense for me, to wipe out other gameengines then UE4 from the market, to end those translateproblems?
One Gameengine, one world, one sky, one OS(Win 10) and one sun we share! #playersunite #nwo

That could really be a step into a better world, if you ask me.
We can easy reproduce that in realworld too!
Stop translating, fusion everything, through limitation.
I think sometimes it’s no racial trouble intended and could not be solved, like racial trouble problems, when theoretically only one race would exist in the future.

Yeah cause it’s totally ok for you for not knowing anything about C# and still join the discussion, and when someone points that out you just remove their comments.
why don’t you remove yourself from the conversation since you don’t belong ?

Iteration time is more than acceptable when it works at all, yes. As your project grows and gets more complex, hot-reload breaks more often than not. It’s quite telling that not even the Unreal Tournament guys have it working. So yeah, iteration times are a big maybe.

EPIC HAHAAHHA

Just stop the arguing in general, this is not getting anywhere

Go back to unity if you want c#

you do realize that I am the one that made that quote right?

First of all I never joined this discussion, my name is not @ in case you missed that. I posted what you quoted above to try and keep this thread from going completely off the rails.

Your comment was removed due to it’s tone/content only. As I mentioned before, which you have once again ignored, keep your focus on the topic. Everybody who uses the engine “belongs” in this thread, as this discussion will affect everyone even if only indirectly.

Any further mention of this will be removed, and if this thread continues going downhill we will close it.

Edit: talked with a moderator and he gave me back faith in humanity.
Eitherway, I leave the conversation sorry @Diddykonga if I derailed your post :slight_smile:

I have questions how many people asking for C# are waiting for C# before using Unreal Engine 4? Also for those who aren’t what are you using C++ or blueprints? And one last question for those saying C++ is outdated why aren’t you using skookum script it’s a brand new language that is getting a lot of support and received funding from epic why do you stick with an “outdated” language? Anyway can someone please answer I just want some reason to believe C# is the future.

How to create a native C#

We wouldn’t have to, if C++ actually could keep up as a language with modern standards. :confused:

Ok, to be fair. It ain’t that simple to make a new really powerful high level language, or even improve on that what we already have without introducing new problems or break compatibility etc…

However, to make a native C#, one would only need to take C++, and make it slick. You know, the new experimental module system is also going to introduce new keywords. Yes… it seem with every new standard, C++ may bloat up like a balloon. Also we do require to compile and run native code alongside managed code. Managed C++ that was superseded by C++/CLI, was created by M$, too, and can actually do this.

Managed C++
C++/CLI

So the interesting thing about C++/CLI is that in can communicate in native and managed syntax and even compile into the same exe/dll from the same VS project. A .Net language would require P/Invoke to call to native code, but C++/CLI is more directly. And P/Invoke is quite error prone.

I haven’t tried yet to compile the entire Unreal engine under /CLR, but ideally, this is how a imagine a hybrid. That I just could take a standard C++ written code, and compile it inside the same V$ project with my own managed C# in it. Well, I’m actually not intend to add C# to the engine itself, but I would need an installed Unreal engine to provide my own V$ project for the game with external dependencies/headers.

M$ would need to implement a managed C# compiler that is able to pass on its compilation results to the final exe/dll. Since a C++/CLI does have managed code support, it only should be a matter of feeding it into the right pipe line (or whatever a tech savvy programming language designer would call that). From , then M$ is free to determine a new slick syntax for a native C#. It would be the third contributing compiler in addition the standard C++, and the managed C#. As a mentioned before in another posts, the native C# would be the “target syntax”, and the standard C++ would be the “migration syntax”. The goal is to rewrite the source code from the migration syntax to the target syntax to effectively wipe C++ out from existence! Or, in computer science terms: to effectively supersede C++ with C# in any application all over the world!

But not so fast, before you can say hello to your new God, C#. We need a slick native C# syntax first. Currently C++/CLI does require you to use the keyword “ref” if you wanted to declare a managed class. So like this:

public ref class ManagedClassOne {};

Well, no more new keywords please! I would suggest to put C# code into two separated file types. One file type for manged C#, one file type for native C#. I’m skeptical about that “^” sign, too, but it would be up to M$ the community to figure what to do with the “->” as well (maybe a “:” instead?). The thing is, that the design of a native C# would be quite free from the standards of C++. If there is anything that could make native programming better. M$ just could implement it without having to bother about C++. Header shouldn’t be allowed to be created with in a native C# at all, but only allowed to be included from other libraries. And certainly you can say goodbye to “::”.

I don’t make any excuses. I’m not going back to Unity just because of C#. And I’m also not intending to use blueprints more than on the top-level and for very, very simple logic.

C++ can not kill me! -.-

But… maybe… I can outlast it! Har… har…

And regarding Skookum script. Yeah, its IDE is messy… Though, I only spend very little time with it. For now, I just stick to C++ and see what Xamarin, or rather M$ comes up with. There are ways to avoid C++ pitfalls, so I just continue to learn more about it.

<removed>

But seriously, before I got into UE4, I used an open source engine and it’s core was written in C++ and game scripts in … a script. Before that I used QuakeC with another open source engine. When I saw BP I was like “blasphemy!” since I couldn’t understand it and already got used to reading and understanding (game logic / framework) C/C++ code and its subsets. Eventually I had to make a choice and I chose UE4. After working (hands on) with BP, I can’t see myself going to any kind of scripting. Granted, most likely I will need a C++ programmer to optimize my BP eventually and move it to C++, but by then I will have working game (or a prototype). I think it’s a big win for everyone to get stuff done with what you have in UE4, reach your payday and then, if you still feel that UE4’s C++/BP is something that prevents you to achieve greater things, you can implement C# in UE4 and submit pull request.