Page 2 of 2

Re: Lesson 0 - The science behind mods

Posted: Wed Feb 13, 2013 12:34 pm
by Feralidragon
^ Yeah, the thing is like you said the point wasn't seeing John doing "animation".
I called these as "tasks", because just like if you had a list of things to do, you would only do one after the other, and never 2 at the same time (unless someone helped you with the tasks, and this would be what I referred to "multi-threading"), and code works exactly the same way.

Animation is just a very specific feature of UnrealScript, which only setups a few variables up (relative timers, frames and the sequence to animate) and lets the render do the rest, and I never mentioned anything specific as animation or anything else in my examples.
But again:

Code: Select all

PlayAnim('Anim1', 1.0);
PlayAnim('Anim2', 1.0);
Even those two do not run at the same time, the second PlayAnim is only called after the first PlayAnim returns, as all it does is to setup a few flags and properties for the render to detect it later and update the animation over time, it does not do the animation by itself, therefore one cannot ever say they run at the same time since that continues to be false, that's why the second PlayAnim always overrides the first.

In fact, my example applies to every single language out there.
Apparently this isn't obvious to TheLame.

Thanks for your input Anth. :)

Re: Lesson 0 - The science behind mods

Posted: Wed Feb 13, 2013 1:30 pm
by TheLame
anth wrote:I think TheLame's issue is that if "doing homework" and "going out and play" were animated actions, an external observer would only see john going out and play in real time. This is obvious since animations are rendered in a sequence of Render() calls. But that's not really the point here :) The example isn't supposed to have observable real-time behavior.
Thank you very much :-)

My point exactly. If Ferali wants to learn someone how to code in Uscript he cannot set aside the Tick and CPU load as he does here.

It's a matter of creating something that will work in the game.

let me explain in code:

Code: Select all

if (GameIsRenderingFeralisExample)
 log("This game lags and players leave server because of it beeing unplayable");
else
 log("if the mod is somewhat close to beeing fun the player will stay and enjoy the game.");

Re: Lesson 0 - The science behind mods

Posted: Wed Feb 13, 2013 2:46 pm
by Feralidragon
You still didn't get it...
Please, do me a favor and give me your own definition of "Tick" and what it does in the engine, and how it's so UScript-exclusive in your opinion, so I can understand better how you are thinking to be able to explain things in a way you can understand.

You're mixing things that should not be mixed up from a coding standpoint. I am doing these lessons exactly in a way to make sure the end developer knows the difference between coding, UScript and the game or engine itself.

Doing so will allow the end developer to be able to work seamlessly in any language and not be bound by the chains of a single language in the context of a single platform (which even there your initial claims are not true).
Mixing these from the start will lead to nothing but confusion and twisted ideas of what coding in UScript or any other language actually is and works like, and will make things look harder than they actually are and will make said end developer thinking that things work in a way deviated from what's actually correct and factual.

The concept of coding has nothing to do with CPU load (which is nothing more than the number of clock cycles or instructions it needs to process something, and not the instruction itself), that's what Algorithms and "code optimization" covers instead.
It's obvious though that in any language you need to consider CPU load, memory usage, and plenty of other things to provide the smoothest way to do something, but that's not bound by UScript alone and is not the scope of this lesson at all (and should not be), since coding != algorithms.

The example I provided for UScript, works in any language in the same manner (not semantically, but conceptually).

Re: Lesson 0 - The science behind mods

Posted: Wed Feb 13, 2013 10:07 pm
by Wises
hmm... Firstly thank you Ferali for even taking the time to teach us coding. Being a very experienced coder your-self I started reading this thread with great enthusiasm.. And then as quick as it started it got LAME.. actually in the second paragraph.

It would seem that in UT Land there are trolls and lamers everywhere who are intent on ruining things for others why?...

you explained yourself and even being a very novice 'coder' myself by any standards I understand fully what you are saying.. I would like to actually complete this course without any 'Retired lame' interruptions please.

In fact .. I reckon Ferali perhaps you should write a Book (Digital PDF) and if you wanted to make a little bit of coin Sell it on Amazon. Because what you have there my friend is a Gift. And in writing a book you won't get held up at the first page by some critique that has nothing better to do then to foil your plans of actually writing a book.

That is what I assume you are doing isn't it LAME? .. I mean why else would you even troll this post if your intentions were not to hinder the process as you most likely have done on many Servers in the past. No doubt.

The point is very clear.. and that is that a computer executes code in series.. one command after another.. if a function is called then it will jump over there and execute that function before returning to the next line of code in the program.

example

Code: Select all

start;
timeWasted=0
begin tutorial;
goto lame;
continue;
goto lame;
continue;
goto lame;
if (timeWasted>=30 then comment else continue)
comment;
stop;

;lame
lets confuse everyone with bullshit;
timeWasted=timeWasted+10
return
This is starting to TICK me off. :mad2:

@LAME thanks for wasting 30minutes of my time.
@Feralli keep up the good work and please continue.

Re: Lesson 0 - The science behind mods

Posted: Fri Feb 22, 2013 12:16 pm
by Chamberly
Read & understood. :tu:

Re: Lesson 0 - The science behind mods

Posted: Sun Feb 24, 2013 8:35 am
by professor
Nice tutes Ferali!,
I can see TheLame doesn't really understand program flow. By his example, the boolean variable bHomeWorkIsDone had better have been in Johns function dohomework() and be set to false or have been set to false somewhere else or I could see John starting his homework then stopping to go out and play too.
Another way to write this (say for instance you didn't want John to do both things but do one or the other) would be like this:

Code: Select all

 CODE: SELECT ALL

if (John.hasHomework()) 
John.doHomeWork(); 
else if (!John.hasHomework())
 John.goOutToPlay(); 
This way John will never do both his homework and go out to play too but only one or the other. Assuming the function hasHomework() is a boolean function.
I hope I haven't added to any confusion or made things more complicated. I've been dealing with UnrealScript for about ten years now and never stop learning new things.
Feralis code will do exactly what he intended which is tohave John do his homework if he has any then go out to play.

Professor

Re: Lesson 0 - The science behind mods

Posted: Sun Feb 24, 2013 2:07 pm
by Feralidragon
Thanks for your input professor. You didn't add any confusion, but I have to make a correction in the code you posted:

Code: Select all

if (John.hasHomework())
    John.doHomeWork();
else
    John.goOutToPlay();
If the first condition isn't met, a second check is not needed since we know what is going to return, given that is the same exact check as the first, but inverted.
But yes, if it was one or the other, it would be along those lines.

Re: Lesson 0 - The science behind mods

Posted: Sun Feb 24, 2013 5:06 pm
by professor
Feralidragon wrote: If the first condition isn't met, a second check is not needed since we know what is going to return, given that is the same exact check as the first, but inverted.
But yes, if it was one or the other, it would be along those lines.
Ah yes, I see! I can also see that I've become a bit rusty. I haven't scripted in a year or so which is one of many reasons why I look forward to more of your tutorials!

Thanks for clarifying that. :tu:

Cheers
professor

Re: Lesson 0 - The science behind mods

Posted: Sat Apr 01, 2023 12:40 am
by Peamole
Does anyone have a tutorial that lists every word used in uscript, describes precisely what each word does (in simple, baby language) and explains the intricacies of syntax?
How about a tutorial that teaches you how to code for Unreal, not how to write an accounting program? Oh, and please no stinkin' "Hello world!" garbage that serves absolutely NO PURPOSE in any game whatsoever! Anybody? Learning this without a class or one-on-one tutor has proven rather difficult for me.
I hope my little rant didn't rub anybody the wrong way. No hash feelings meant.

Re: Lesson 0 - The science behind mods

Posted: Sat Apr 01, 2023 10:30 am
by UnrealGGecko
Exhibit A of what learning UScript does to a man: they start reviving 10 year old topics with an unrelated rant :lol2:

Try this list: viewtopic.php?f=15&t=4716

if the links dont work run them through the wayback machine, like so:
https://web.archive.org/web/20130415232 ... erence.htm

Re: Lesson 0 - The science behind mods

Posted: Mon Apr 03, 2023 1:07 am
by Peamole
UnrealGGecko wrote: Sat Apr 01, 2023 10:30 am Exhibit A of what learning UScript does to a man: they start reviving 10 year old topics with an unrelated rant :lol2:

Try this list: viewtopic.php?f=15&t=4716

if the links dont work run them through the wayback machine, like so:
https://web.archive.org/web/20130415232 ... erence.htm
Lol :wtf: :facepalm:
Thanks. This helps a little.

Re: Lesson 0 - The science behind mods

Posted: Mon Apr 03, 2023 3:26 pm
by UnrealGGecko
Forgot the list, updated xD

Re: Lesson 0 - The science behind mods

Posted: Mon Apr 03, 2023 10:40 pm
by sektor2111
Peamole wrote: Sat Apr 01, 2023 12:40 am Does anyone have a tutorial that lists every word used in uscript
Never need such... All I did in my learning process was to study simple codes and understanding them. Basic elements of programming are needed not stories with words.