Things that took you WAY too long to figure out... | Forums

[stllbreathnbdy]

So, I'm ashamed to say it took me until just today to figure this out. I was daydreaming at work(as usual) when I realized how to make wheels and, things of the like, rotate all while moving with other objects with the OPE. Wheel---xyz coordinates of whatever the wheel sticks to. Bam.

I felt brilliant, and absolutely moronic all at the same time

What other silly things have you guys admittedly taken way too long to figure out?

[Smeghead89]

that holding down break in mid air will make you flip/spin faster and feathering which kind of uses the same technique, i only learned these 2 moves in the last couple of months and iv been playing trials for years

[rlmergeuser]

What the hell the purpose of a filter is and how to use it, to this day i i find filters odd and hard to use, i find them to be quite lacking in something or an awkard thing to use, i hate how once they turn green and activate an impulse is needed for them to function it is so annoying, then if i put a 1 tick interval trigger on it the logic is messed up and sounds get played constantly at 1 tick which to my ears there is no sound, instead i use alot of trial and error with delay event, it still works but is just more time consuming, at least it's easier to understand.


Another thing i've started to figure out is how to use operations properly, i only have used the two input, but the others i have now clue on how to use them or where.

[stllbreathnbdy]

^once I figured out filters that blew the doors off what I could make! That was a revalation

[Smeghead89]

i wish i knew how to use filters or even what they are/can be used for, the 1 thing my tracks are lacking is animations and special effects, i just find some of these tutorials so head hurting that i just stick with what i know - not a lot

[stllbreathnbdy]

I use filter primarily for skill games. Great for menus, or any sequences of events. Filter checks a value, and based on that it unleashes a new operation. It's a simple tool, but balancing a ton of them together does tend to make by brain fart. It's like trying to do 325 x 571 in your head . It's all basic when broken down, but it's so easy to lose focus.

What do you think a filter could do for you in a trials track? I've only had one real idea myself, a series of filters checking the bikes speed to determine the proper amount of explosive force needed to blow the rider onto a platform...it's not exactly pure trials

[Lukeyy19]

Operations are where I stop in the editor, I can't be dealing with all that stuff, that's too much math for a video game, data sources and set value events are about my limit for using math in this game, after that, creating becomes more of a chore than an interesting logic puzzle.

Once I watched through all the tutorials and played around a bit i got the hang of things like Physics joints, Filters, OPE's, Data Sources etc pretty quickly, if you have a basic understanding of how coding logic works it becomes a lot easier, it's like coding, without all the difficult and complicated code to remember.

But I did only just fully work out the Area Affecter the other day, I had never used it before and when i tried to use it in my latest track i balls'd it up and couldn't figure it out but it was so simple in the end.

Edit: about using filters in trials tracks, my Activate! track used filters to determine if all buttons had been pressed before opening the door, but in a basic trials track i may use a filter to detect if while you're in an area trigger, if you crash to activate a death cam, so as you enter the area i set a value to 1, then if you crash the filter checks the value and if it equals 1 it switches the camera, if not, then you're not in that area and so it doesn't.
Also i have a track set in the sky, i have a filter set to check if your height is higher than a certain height, if it falls below that amount you crash and the camera fades out so you don't see the character fall to the floor ruining the immersion of the floating track. It's a lot easier and simpler than using fail areas and area triggers everywhere.

[stllbreathnbdy]

Ah, fail cams and area triggers, ok.

You know, I've spent hundreds of hours screwing off in the editor, but I've yet to really make a good drivable, physics controlled vehicle...physics and me don't play nice

[rlmergeuser]

Alright, time to drop some knowledge.

What the hell the purpose of a filter is and how to use it, to this day i i find filters odd and hard to use, i find them to be quite lacking in something or an awkard thing to use, i hate how once they turn green and activate an impulse is needed for them to function it is so annoying, then if i put a 1 tick interval trigger on it the logic is messed up and sounds get played constantly at 1 tick which to my ears there is no sound, instead i use alot of trial and error with delay event, it still works but is just more time consuming, at least it's easier to understand.


Another thing i've started to figure out is how to use operations properly, i only have used the two input, but the others i have now clue on how to use them or where.

i wish i knew how to use filters or even what they are/can be used for, the 1 thing my tracks are lacking is animations and special effects, i just find some of these tutorials so head hurting that i just stick with what i know - not a lot

I can understand where the confusion comes from.
Filters are rarely needed when creating a standard trials track without any sort of interactive objects.

It's not until you start working with somewhat complex logic the use of filters becomes apparent.

Filters are basically the equivalent of "if statements" in almost all programming languages.
The concept is "if this is the case, then do this, or else do that."

This is useful for checking how many lives are left if a character dies for instance, so that it can either respawn the player or end the game.
Here's some pseudo code (don't worry, it's explained by the text after each double slash):

[code:2q4p1mz6]
Variables:

livesCounter; // Number of lives left.
isDead; // Either "true" or "false" depending on wether player is dead or not.

Code blocks:

if (player.isDead == true) // If player is dead, run the indented code in the brackets, otherwise skip this code and continue.
{
if (livesCounter == 0) // If the lives counter is zero, which means there are no lives left, run the following code in the brackets. Otherwise skip to the next brackets.
{
// Game over code here.
}
else // We're still in the same 'if statement', but the code in these 'else brackets' are what's going to run if the lives counter is not zero.
{
livesCounter--; // Decrease the lives counter by one.

// Respawn code here.
}
}
[/code:2q4p1mz6]

In the track editor, this would be the equivalent of having two generic filters.

The first would check if the player is dead, it would do this by checking wether a variable data source is one (true), or zero (false).
The variable data source would of course have to be set to either one or zero some time before this check is made.

If it's zero and the player isn't dead, the false impulse continues to some other line of code blocks.
However, if it's one, the true impulse goes on to activate the second generic filter so that we can do another check.

This second generic filter checks another variable data source that is the container of how many lives are left.
If this variable data source is zero it means the game is over, and the true impulse would lead to a set of code blocks that instruct the game to end.
If it's any other number than zero, it means there are still lives left, and the false impulse would lead to code blocks that are made to respawn the player.

So as you can see, there's a reason these generic filters don't send out impulses on their own, that would defy the purpose.
The purpose is to perform a check on wether a value is true or not, or if a number is within a certain range or not, right when we want it to and then act accordingly.

Operations are where I stop in the editor, I can't be dealing with all that stuff, that's too much math for a video game, data sources and set value events are about my limit for using math in this game, after that, creating becomes more of a chore than an interesting logic puzzle.

Once I watched through all the tutorials and played around a bit i got the hang of things like Physics joints, Filters, OPE's, Data Sources etc pretty quickly, if you have a basic understanding of how coding logic works it becomes a lot easier, it's like coding, without all the difficult and complicated code to remember.

But I did only just fully work out the Area Affecter the other day, I had never used it before and when i tried to use it in my latest track i balls'd it up and couldn't figure it out but it was so simple in the end.

Edit: about using filters in trials tracks, my Activate! track used filters to determine if all buttons had been pressed before opening the door, but in a basic trials track i may use a filter to detect if while you're in an area trigger, if you crash to activate a death cam, so as you enter the area i set a value to 1, then if you crash the filter checks the value and if it equals 1 it switches the camera, if not, then you're not in that area and so it doesn't.
Also i have a track set in the sky, i have a filter set to check if your height is higher than a certain height, if it falls below that amount you crash and the camera fades out so you don't see the character fall to the floor ruining the immersion of the floating track. It's a lot easier and simpler than using fail areas and area triggers everywhere.

I used to feel the same way about mathematics; in fact, I really sucked at it.
I couldn't multiply in my head even in my teen years.

It's not until recently that I developed an overwhelming love for math as I realised it's absolutely crucial for programming games, or really anything worth programming.
Even for a simple 2D game if you'd want it to be polished in the way it handles, an understanding of linear algebra, trigonometry, and geometry is absolutely required.

Creating anything that involves less than that has become too boring for my taste.

One thing I'll have to disagree with you on is the simplicity of "coding" in the track editor.
Programming in written form is much more simple and involves less work than doing something similar with the visual coding tools in the track editor.

The reason for this is because most programming languages are what's called "object oriented programming languages" (OOP).
This doesn't mean you use visual objects to program, it simply means that each portion of the total code that has a certain individual task can be made into its own object, or "class".
For instance, the way a certain enemy type behaves would be a class, the way a certain vehicle handles would be a class, even a lives counter would be a class.

Basically anything that should be reusable will have its own class.

The idea is that you don't have to rewrite the code if you're going to have hundreds of enemies or hundreds of vehicles, you simply use each class as a template or a starting point for an object.
Then the game can dynamically spawn several instances of the same object to serve as enemies, and they all follow the rules from the enemy class.

In fact, you can have classes within classes.
If you're going to have a boat you could simply create a boat class that extends the vehicle class, meaning that it would use vehicle as a blueprint, or starting point.
It would inherit all of the vehicles behaviours, like steering, but it would also contain additional code that lets it drive in water for instance.

No need to rewrite everything for each instance that is going to be used. This is what is sorely lacking with the track editor.

-----

One thing that makes me irrationally angry is when I play an FPS created in the track editor, and it makes use of physics objects in order to do certain things.
Like pushing around a big ball with physical forces to make to player move instead of doing it using the math tools.

Going the math route opens up other possibilities in terms of animations, like camera shake / view bobbing, proper jumping and so on.

[sparkierjonesz]

if you look at peoples coding for advanced games you will see that each task has it seperate coding

in a game i made i got coding thats basicly a get(int x) and would give 3 integers back
but thats not real oop but it gets the job done
but i basicly created sets of coding each with an own purpose, moving, lives, damage etc
only difference between oop and this is that you have to know the limits and create all coding before it will be used

the only thing the game cant do is create new stuff(except the emiter but not that usefull for animations/ope stuff) or new objects with additional coding