What other languages do you know compare to Uscript?

[sektor2111]

For me using fore mentioned wrapping makes things more readable, but speaking about "readable codes" which I could see around UT some way of doing left me shocked. Writing a function on 3 pages not because function was a giant one (bugged of course) but it was written using around 3 pages of spaces and TABs and... very few lines of codes. For getting wheel around that, I've wrapped it first to see how big was the love for Mr. None so often accessed, I had to delete probably more than 2000 TABS and useless spaces thrown around with no purpose...
I'm not gonna quote some conditions written in there, because defaming is forbidden here (forum rules)... several things were copied from some of my mods but greatly crapped and brought to a retarded stage... But that's another story, my codes are working as they are, while the rest of copies using 0% logic and 100% Copy-Paste - is a guess-work... and that's why this way is almost 90% a failure regarding to programming language or syntax used...
EDIT - Almost to forgot main thread subject.
Programming languages generally from my side should have a few healthy and common points:
- Logic in programming (missing mainly here and there);
- Purpose of programming (this amazingly is missing too);
- Optimization - borked, flawed and slow codes are not helpful;
Differences:
- syntax;
- capabilities - power of codes.
UScript is a sort of Java derivated/based but... way more primitive, and always new comers are trapped and annoyed.

My two cents, btw...

[PrinceOfFunky]

Started with Java, then UnrealScript, Lua(just a bit), javascript, PHP, few lines of C and C++ and lately Python. About this last one, thanks to of the giant community and libraries and the high level that come with it I totally replaced Java and PHP with it and a bit of UnrealScript.

[Feralidragon]

Programming languages generally from my side should have a few healthy and common points:
- Logic in programming (missing mainly here and there);
- Purpose of programming (this amazingly is missing too);
- Optimization - borked, flawed and slow codes are not helpful;

Could you elaborate?
Such as examples of what you consider good languages and what you consider to be bad languages, and why?

I am asking this because often programmers want a language which is fast, given that no one wants their code to be slow of course, however the speed of a programming language is actually not only quantified by how many instructions a second it's able to perform, but also by how fast you're able to develop and deliver anything of substance with it.
And more often than not, nowadays the language speed takes a back seat compared to development speed, since machines are cheap and always getting faster, but developers are expensive and aren't getting any faster themselves.

In a way, UnrealScript is a perfect example of this: it's an easy and accessible language and is very fast to develop anything with it, while C++ is much harder in comparison, even though the latter it at least 20x faster than the former.

[sektor2111]

Such as examples of what you consider good languages and what you consider to be bad languages, and why?

I'm talking about UScript and how some coders are doing things.
Some dude was checking 3 types of actors using 3 Iterators - in a SINGLE function - rather than 1 iterator and written properly. Such codes loading iterations are developing the shortest route to a game-crashed - it's what I will never use regarding to design and colors, if algorithms are crapped up.
This is also one of my evil ways to fix bad actors in mods rather than using private solutions. I have loaded iterators too much and then... maps having thousands of actors (monsters and stuff) were crashing, until I've developed another way... background processing - more healthy and smoother.

PS:
I do read this forum because I'm interested when UT community will want to recruit a team of coders in purpose to do some Ex-Official UT update as long as the game is way too bugged and "factory" doesn't seems to be interested about doing something here - at least UScript things properly conformed are going to vaporize a bunch of problems - I know what I'm saying here because I'm no longer using default main files in my private servers (until I'll throw everything in a single multi-server). The rest of discussions for me are entirely irrelevant and boring.

[Feralidragon]

Some dude was checking 3 types of actors using 3 Iterators - in a SINGLE function - rather than 1 iterator and written properly.

Sometimes using multiple iterators with different classes instead of a single one with an "if" statement is the right solution in terms of performance, even if in terms of time complexity it looks absurd, given the real difference in speed between UScript byte code and actual C++ machine code (in the time UScript evaluates 1 single iteration, the native code could have evaluated 20 or many more).
And although we can talk about that sort of thing in another topic perhaps, if you have examples like those around you can share, it would be very cool to discuss them out.

PS:
I do read this forum because I'm interested when UT community will want to recruit a team of coders in purpose to do some Ex-Official UT update as long as the game is way too bugged and "factory" doesn't seems to be interested about doing something here - at least UScript things properly conformed are going to vaporize a bunch of problems - I know what I'm saying here because I'm no longer using default main files in my private servers (until I'll throw everything in a single multi-server). The rest of discussions for me are entirely irrelevant and boring.

It all depends on what you mean by "update".
If it's to "conform" packages in the same way you have been doing privately, and having it done publicly instead, that's calling for trouble, so you're probably going to remain alone in that endeavor.

If it's to build a framework to fix, and even add easy and secure ways to do certain things without messing anything up, as new packages altogether, which can be further updated over time with no bad consequences, I am already planning to do something similar, but it's still so far away down the road from even being started (given that I have to finish something else first), that you may as well not consider it for the time being either, but just know the intent is there at least.

And there's also XC_Engine which allows to do that directly it seems, especially on the "replacing functions" department.

Either way, all of these are very interesting talks to have perhaps in separate topics.

[Red_Fist]

Program this math, and make it work on a silicon chip-GPU

https://www.geforce.com/whats-new/artic ... ay-tracing

[Higor]

There's only so much that can be done if you can't alter the original code.
XC_Engine is only doing 15% of the things an actual UT update would do if it were rolled by a team UT99.org coders.

/***/
And TBH, programming languages by default can be better or worse for certain types of tasks.
Each comes with it's native toolset and extensions to make said tasks easier to code, taking Python for example... a C.R.U.D application can be finished in less than a day, if written from scratch and with decent testing and optimization.
Java's more verbose in that aspect and therefore takes more, let's not mention C/C++ when it comes to that, where you'd need to build a lot more of high-level stuff in order to get a working application.

It all comes down to the characteristics of the program you're trying to make and use.
Python is vastly superior when it comes to administering own datas, but is terrible at protecting/obfuscating a program.
Java is like a more verbose UnrealScript with loads of native OS access, but with questionable memory management from it's JVM which forces the programmer to add limitations/workarounds to applications that employ lots of memory.
PHP is obviously targeted for specific kinds of environments, and can be handy as it can serve clients with nothing but a web browser while protecting some of its internal functionality.

It's not about better or worse, it's about which is more convenient to use given your goals and knowledge.

[sektor2111]

And there's also XC_Engine which allows to do that directly it seems, especially on the "replacing functions" department.

That's one point which is not a complete answer. May I elaborate a sample ? Allright, let's walk through a bad script called ScriptedPawn ruining the charm of MH game. NOT everything can be fixed with XC_GE, but you can prevent troubles by adding simple sanity checkers in STATES where they need to be. Berserker recursive crash is completely removed if somewhere is added a "Sleep(0.2)" so to so speak creature should have a "reflex" in his reaction as a normal life-form, crashes are gone this way. Other stuff can be not fixed as much as it can be improved and operational, here we can chat about some "defaultproperties" of several projectiles which can bring back in stage, being used used some messed up maps. When these properties are defaulted properly you don't even need any line of code executed for tweaking, they are good by default. There are other options generating packages perfectly compatible with original borks making a Coop/MH and even a DM server to work better and stable, that's the point.
For non XC users (or XC haters) PlayerCanSeeMe crash can be solved by simply removing the crap from everywhere where is called in new packages properly conformed - then everyone is happy.

And yes,

If it's to "conform" packages in the same way you have been doing privately, and having it done publicly instead, that's calling for trouble, so you're probably going to remain alone in that endeavor.

by making things to work flawless is disturbing for trash lovers, I gotta admit... I'm not convinced that some admins did not do this already and even more. Some topic with "forged object" is an evidence about this and... I have encountered this problem in my "beta" attempts, but now everything is normal, and me alone in endeavor I have a major advantage - I can test a lot of options for certain things by making WEEKLY changes without disturbing community with 1 GB of unknown packages - that's my master advantage of experimenting in a closed "lab", so here I cannot complain . But I keep looking when coders will get pissed and will start doing the right thing. I'll point you to a community still developing things for "Win98SE" if you can believe that, there are still users doing stuff outta M$ if they don't care about their old products . What seems to do community is exactly like buying the best spray trying harder to make a sh!t to smell better. There is a more simple solution to replace that sh!t with something else better and a good smelling, but if people are always getting the harder way or other useless way, this is not such a big issue for me.

As a reference for 1 iterator replacing 3 there can be reasons to not mess with 3 iterators especially in maps having 4000+ actors and even more (see UTR awesome loads - 7000+) - I know what I'm saying here. A single function doesn't break execution cycles, it's increasing them, but you don't have to believe me, my way of doing has stabilized packages in my playground (at dreams stage 10 years ago) and that's why I'll keep doing things in my way without "concepts" and fancy failures.

Probably I could figure many advantages of this poor UScript and maybe differences from other languages are exactly the simplicity and making things doable even by NON-Coders - me as a direct sample which I have a poor coder experience (a few small BASIC apps done years ago...).

[Feralidragon]

There's only so much that can be done if you can't alter the original code.
XC_Engine is only doing 15% of the things an actual UT update would do if it were rolled by a team UT99.org coders.

If the original code was released or at least accessible by some, only the sky would be the limit in what could be done.
But UTPG ruined those chances completely for limited access at least, so only a full public release could potentially make wonders.
However, there's still a lot that can be done. The engine is still quite stable for its age and the amount of time Epic actually dedicated to it, and the public headers allow for many things to be done, so we cannot complain.

It's not about better or worse, it's about which is more convenient to use given your goals and knowledge.

This.

sample ? Allright, let's walk through a bad script called ScriptedPawn ruining the charm of MH game. NOT everything can be fixed with XC_GE, but you can prevent troubles by adding simple sanity checkers in STATES where they need to be.

I remember, being mentioned at least, that states could also get overridden as well.
I think someone else (Chris?) did something to replace states and posted it in one of Higor's topics about XC, although I am not sure if it was incorporated at all in it.

And yes,

If it's to "conform" packages in the same way you have been doing privately, and having it done publicly instead, that's calling for trouble, so you're probably going to remain alone in that endeavor.

by making things to work flawless is disturbing for trash lovers, I gotta admit... I'm not convinced that some admins did not do this already and even more. Some topic with "forged object" is an evidence about this and... I have encountered this problem in my "beta" attempts, but now everything is normal, and me alone in endeavor I have a major advantage - I can test a lot of options for certain things by making WEEKLY changes without disturbing community with 1 GB of unknown packages - that's my master advantage of experimenting in a closed "lab", so here I cannot complain . But I keep looking when coders will get pissed and will start doing the right thing. I'll point you to a community still developing things for "Win98SE" if you can believe that, there are still users doing stuff outta M$ if they don't care about their old products . What seems to do community is exactly like buying the best spray trying harder to make a sh!t to smell better. There is a more simple solution to replace that sh!t with something else better and a good smelling, but if people are always getting the harder way or other useless way, this is not such a big issue for me.

I already mentioned this before I think, but the problem with conformation it's how messy and illegal that solution is.
For private use? Be my guest, you're free to do whatever you want privately.
For public use? It's illegal to do it in the first place, then it's a mess given that the base version of the packages are not getting increased, and they will require updates whenever something wrong is found in them, so you end up with tons of different files with the same package name, and not versioned at all from the engine perspective.

Sure, modifying the packages directly to fix them is the direct cut solution, but it has really bad implications if done as public releases, and doesn't solve anything for everyone as private (other than your own servers, and whoever contacts you to get them, of course). It would only work if we could effectively patch the game from within and increase the version (something like a v460 for example).

Otherwise, the way I see it, the best course of action is to eventually build new packages which implement the required polyfills to fix things underneath, and perhaps complement with XC stuff.
It's not as clean from a "software" point of view, but solves the problem with distribution.

As a reference for 1 iterator replacing 3 there can be reasons to not mess with 3 iterators especially in maps having 4000+ actors and even more (see UTR awesome loads - 7000+) - I know what I'm saying here. A single function doesn't break execution cycles, it's increasing them, but you don't have to believe me, my way of doing has stabilized packages in my playground (at dreams stage 10 years ago) and that's why I'll keep doing things in my way without "concepts" and fancy failures.

It still depends.
Maps could have 10k actors, but if you're looking for 2 particular classes of actors, for which only Actor is the common parent, and which are not expected to exist in high numbers (singletons or just maybe a dozen of each), it's still preferable to use 2 iterator calls where internally it will transverse the 10k actors twice (20k internal iterations), rather than doing 10k and run UScript for every iteration, since 10k iterations in UScript are at least theoretically 10x slower than 20k iterations in C++.
It comes to a point where even using linked lists to transverse a list of pawns looses its efficiency completely when the ratio between the number of pawns and the number of other actors is high enough.

That's why I asked for examples, to understand which is the case you were talking about.

[sektor2111]

That's why I asked for examples, to understand which is the case you were talking about.

Umm.. the guy doing the mess can read these and will feel a bit "under heavy attack" - a bit true I gotta admit but let me see. If you want to debate:
- Movers - there is not linked list as for PawnList or NavigationPointList, etc., NotifyList, etc...;
- Carcass - NONE links;
- Projectiles - Null Links to each-other and so on.
So to speak everything goes slow when it is used foreach Carcass, foreach Movers foreach triggers, etc. Not everywhere linked lists are working and... these hacks are more healthy in a state code as I could figure later. Patching a map is doable even slower (during 2-3 seconds) because no one will get hurt.

The rest of ReplaceState problems I wanna know what compatibility exist with client which has no clue about the new state used by server. Without to see an operational SAMPLE I won't be convinced about "all good" things. I'd rather prefer to do what is DOABLE easily and without more noise. At least I'm happy to see answers to the problems which were haunting me for years. If UTPG "conformed" files for completely mess up Editor ("thank you", guys), my way is different. Amazingly solution to work with screwed files is known from OldSkool times - THAT one is not compiled normally as already explained in codes so by using "domestic" coding for changing OldSkool will not work, now draw your conclusion, I think more coders owning their own servers have screwed files any nothing has exploded so far.
Another sample (perhaps you'll love this ) Path Seeking in a server was removed by UTPG not fixed in a conformed 451 Engine.u file, being an "exploit". What Exploit ? Oh, well, WarpZoneMarker is crashing server at ShowPath when Path heads through such a point and is probably the same issue like in other Navigation stuff which UTPG was happily removing rather than fixing what Epic themselves were messing up, and even saying "debugging stuff" - no wonder . Do you know why I don't want XCGE to "fix" 436 Navigation flaws like "ShowPath" supposed laggers (sometimes yes - admin dependent) ? Because I wanted them Fixed, not Removed (removal is not a fix after all) and... MHBotyMan4 mutator by self person is now running ON-Line with no crashes at once with default testing stuff.
And then, I'm probably happy with this UScript and its concept, finally I got the point. I'm not sure if someday I will attack natives because C++ is a hard task for me else imagine that usually I do what I want in my yard without even to blink or to post something in public.

Speaking about terms like "illegal", if you read EULA, even there cheating is claimed forbidden. That's why in UT'99 NO ONE is cheating , because this is not accepted... ahah...

[ANUBITEK]

Definitely not a wizard by any sense, still entirely a noob. I've only really using UnrealScript for UEngine 1, 227i for the past... Damn, 3 years now? I studied Python before hand, which helps because I'm moving to Godot with my project so I have to learn GDScript which is similar in some way to Python (no idea how, didn't use it much). I kinda get Java but never got into libraries and such. I think I touched HTML for Android plus Java, I don't remember what the complimentary language for colors and text and whatever else actually was so that's my best guess. As a tangent, Godot is nice in that it allows for sprite flipping and has support for 2D sprites in 3D terrain, but you can't instance a rotator as a variable and it is infuriating. Really made me rethink some of the code I've written already. I still don't really know how to create individual levels, it uses a Node-Scene system wherein everything considered an Object by UEngine standards in-game is a "node" and you group nodes together to make "scenes". The "scenes" can be instanced on a tree and... Pfff, got me past that. I'm still learning Godot.

[Feralidragon]

- Movers - there is not linked list as for PawnList or NavigationPointList, etc., NotifyList, etc...;
- Carcass - NONE links;
- Projectiles - Null Links to each-other and so on.
So to speak everything goes slow when it is used foreach Carcass, foreach Movers foreach triggers, etc. Not everywhere linked lists are working and... these hacks are more healthy in a state code as I could figure later. Patching a map is doable even slower (during 2-3 seconds) because no one will get hurt.

That case is tricky, because of the carcass and projectiles.
In a normal game, one iterator each would probably be the most efficient way of do it, however in gametypes like MH or which has a lot of projectiles being spammed and a lot of carcasses, it's hard to tell, a benchmark would be needed.

But I think it's possible to optimize it automatically in some way, through the usage of similar strategies that databases employ to speed up their queries: hashmaps, binary search trees or/and even statistics on how many actors of any given class are there at any given moment to know which approach to use. But I am not sure if this would be over-engineering something which generally is not a problem though.

Speaking about terms like "illegal", if you read EULA, even there cheating is claimed forbidden. That's why in UT'99 NO ONE is cheating , because this is not accepted... ahah...

Although that argument doesn't even work, simply because the fact that if someone else does it does not mean you're free to do it yourself, changing and releasing standard packages to the world goes beyond the EULA I think, it crosses into copyright territory, which Epic takes quite seriously.

Certainly they won't sue you, but are certain to send you a C&D letter someday. They have sent those letters for less (Shadow received one to stop his SDK, because they were under the impression he was changing the engine in some way to do his SDK, although they let him continue it once he clarified that he was just using their public headers to extend the engine, not changing it).

Definitely not a wizard by any sense, still entirely a noob. I've only really using UnrealScript for UEngine 1, 227i for the past... Damn, 3 years now? I studied Python before hand, which helps because I'm moving to Godot with my project so I have to learn GDScript which is similar in some way to Python (no idea how, didn't use it much). I kinda get Java but never got into libraries and such. I think I touched HTML for Android plus Java, I don't remember what the complimentary language for colors and text and whatever else actually was so that's my best guess. As a tangent, Godot is nice in that it allows for sprite flipping and has support for 2D sprites in 3D terrain, but you can't instance a rotator as a variable and it is infuriating. Really made me rethink some of the code I've written already. I still don't really know how to create individual levels, it uses a Node-Scene system wherein everything considered an Object by UEngine standards in-game is a "node" and you group nodes together to make "scenes". The "scenes" can be instanced on a tree and... Pfff, got me past that. I'm still learning Godot.

Godot... I had to look it up, and it does look interesting.

But it seems that they support C#, which you're probably better off with, for a few very strong reasons: it's a language used in a wide variety of software, it's similar to Java (so if you ever need to get into Java, you get automatically halfway there), and should you decide to use something like Unity instead, Unity scripting is also done through C#, and they've recently deprecated all the other languages and will stick with C# only.
Unless an engine only supports a proprietary language (such as UScript in Unreal Engine up to UE3), you should always opt for a more generic and widely used language, for your own good.