Making a Scratch platformer, I discovered that this did not work how I wanted:
...because it just didn't seem to run at the right rhythm for my program.
However, this did work:
...and I notice it being used in platformers such as Sushi Platformer.
Does anyone know what these nested touching blocks actually do?
Update:
#towerofnix is right... I made an experimental project, at https://scratch.mit.edu/projects/118349555/#player
...with the following experimental options:
Results:
Control: Platform detection works, but jitters up and down too much
Experiment1 (per #towerofnix): works, no jittering!
Experiment2: doesn't work, penguin goes down through floor sometimes
Experiment3: works, because it's equivalent to Experiment1!
Scratch isn't magic. It's a normal code interpreter (as far as I know).
Now that that's out of the way, let's be the interpreter™ and figure this out.
touching-color will return true or false.
touching then takes the input true or false.
touching will go through all sprites named true or false.
since there are no sprites with those names (at least not in sushi platformer), just continue.
next is return false, so return false.
therefore the nest will always return false.
not takes the input false, so it returns true.
thus this - - is unnecessary and can be replaced with this -
So if doing that last step doesn't result the same as not doing the last step, we really need to see your project!
You need to do something special here...
You want to stop the jittering, you'll have to stop the gravity. Set a condition on the gravity so that it stops whenever your sprite touches the platform. Then, have gravity reactivate on your jump button. The way this is now, it touches the platform, jumps up (a tiny bit), and then touches the platform again. You need to change the way your gravity works.
If you want to avoid jittering, you can make a block and select "run without screen refresh" and move the entire if
Related
I am creating a basic 2D fighter game and am trying to replace what was the old input system with the new input system. Because of this the old systems update would wait for buttons and then call appropriate functions when they were pressed. Movement was actually the easiest part, simply rigging a 1D Vector and then grabbing the float to use with movement, awesome. However the difficulty is in pressing keys to change things in the game. For example, I have an input 's' which should lead to the method Crouch(). This method changes the animation running and alters the hitbox to be shorter and tell the attack to use a smaller hitbox as well. A Stand() method is called on release of 's' to return everything to the way it is. I have my Player Input object set to 'Invoke Unity Events' which leads to the corresponding method needed. The problem is that even though these events are set to be push and release they are read as a toggle effect instead of press and release triggers(respectively). This does the same thing with my attack function because it forces the animation to play twice, one for pressing and one for releasing. Is there a fix for this or is this currently a bug? Edit: Here are some images to clarify and the code used to reflect everything happening associated with the Attack functionality. Let me know if anything else should be needed
public void Attack(){
anim.SetTrigger("attack");
StartCoroutine(wait());
}
IEnumerator wait(){
if(!isCrouched){
yield return new WaitForSeconds(1.3f);
SHitBox.enabled = true;
yield return new WaitForSeconds(.5f);
SHitBox.enabled = false;
}
if(isCrouched){
yield return new WaitForSeconds(1.3f);
CHitBox.enabled = true;
yield return new WaitForSeconds(.5f);
CHitBox.enabled = false;
}
}
Binding
Action
Think I figured it out. At least for the purposes of this specific thread. The answer was it was not my code. There is what I am going to call a bug in the new Unity Input System. Specifically there were three lines of code all simultaneously being hooked which caused three calls on my method. The fix was commenting out two lines of code. Here's the thread where this is solved, coincidentally found on GitHub help pages, heres the link:
https://github.com/Unity-Technologies/InputSystem/issues/959
the issue is listed as close but its still a problem for me, lol...
The only issue left is that the behavior of selecting the type of button press that I want to use is still acting funky. Mainly the inputs are still simply firing without listening to the type of input I want. I am basically just going to start searching through unity code to find where these choices have impact. If there are no comments/answers in 8 hours I'll accept my own answer because this has technically been answered, it just leads to another question.
I am having trouble with my Unreal Engine 4 project. I'm very new to this and i don't really understand what's going on. I have made ladder functionality so the character can climb up the ladder and stand on the Static Mesh that is on top. But when i want to go down the ladder i want to trigger the "Allow Down" function on Actor "BP_Ladder" but the cast is failing everytime. what is causing the casts to fail?
I've looked around and other people with cast failed problems have mostly had the names wrong but my ladder is called "BP_Ladder" and that is what i'm casting to so that leaves me really confused.
My BP_Dude blueprint (this is being called every tick)
My BP_Ladder blueprint (this is what i'm trying to trigger)
The goal for this function is that the collision of the static mesh will turn off and then allow me to move down the ladder like normal.
I'd really appreciate your help with this, its my first couple of days using unreal engine and the Epic Games tutorials i followed didn't show all of the blueprints so everyone was left helpless with half broken blueprints.
Understanding Casts
In its simplest form, if your Actor can be cast to BP_Ladder, then it will return the casted object on the output pin.
Just to ensure you know how a cast works, I have to point out that you can't cast a given type to some unrelated arbitrary type; it has to be "castable" to the cast destination. So if you think that the Actor object returned by your overlap is genuinely a BP_Ladder, or a blueprint class that derives from BP_Ladder, then you should be OK. But that has to be the case; otherwise it will fail every time.
https://docs.unrealengine.com/en-us/Engine/Blueprints/UserGuide/CastNodes
Sorry if I'm being patronising, but if a cast isn't working 9/10 it hasn't been used correctly.
Debugging
OK that out of the way, if you think you are genuinely casting to the correct type and it's still failing, then you'll need to debug your blueprint with the objective of finding what type is being given to the cast node which results in the failure.
Select the cast object in your blueprint.
Press F9 to create a breakpoint; a red circle should appear on the top left of your cast box
Run your game in PIE mode (Combo next to play, New Editor Window (PIE))
Put the game in a scenario where your cast will fire (I presume touch the ladder)
The breakpoint should trigger; your game window will go grey and you'll get a large red arrow pointing down towards your cast box where you placed the breakpoint
Hover over the Object pin on the input side of the cast box. It should show a alt-text containing details of the variable.
Inside the alt-text box, look for Current value; this should show you the current object type that you are about to cast. You need to ensure that this value is what you expect.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/Debugging
Example
I've taken a screenshot of a working game; in this you will see:
a Breakpoint (the red circle) is shown on the function node (the box)
the Execution node (red arrow) is Create Rolling Stock
the Current value of the variable is DepotComponent...Depot
Final thoughts
There's a couple of gotchas when using blueprints; one of them in this case could be that you can have two classes with the same name (although they might have different internal "script names" - effectively a fully qualified path). When you debugging an object variable, make sure you match the entire path to the location of your asset in your content folder; this will ensure that you are indeed attempting to cast to the object you think you really are.
Another classic gotcha is "hot reloads". Sometimes the editor needs to reload a module after an on-the-fly build but a class conflict occurs internally; this results in the new version of the class getting a different name (prefixed with HOTRELOADED). Watch out for this; it can cause you to be dealing with two distinct types when casting and you don't even realise. A real sanity-sapper. If in doubt, close and re-open the editor; it fixes it every time.
On Begin Overlap is only triggered when you START an overlap, so if you have some logic that sets your "can climb" to false you will need to move outside of the collider and back into it again for another Begin Overlap event.
My goal is to build a 5x5 grid of images. In the following code, row, col and rowcol were created as variables local to the sprite, and newcol, newrow and cats are global. (By the way, is it possible to tell which variables are local and which are global? It's easy to forget or make mistakes.)
The result is a 5x1 grid only, as seen here.
I am unclear as to the order of execution of these statements. Does when I start as a clone get called before or after add_cat gets called the second time? My tentative conclusion is that it gets called afterwards, yet the clone's global variables seem to contain their values from beforehand instead.
When I attempted to debug it with ask and say and wait commands, the results varied wildly. Adding such pauses in some places fixed the problem completely, resulting in a 5x5 grid. In other places, they caused a 1x5 grid.
The main question is: How to fix this so that it produces a 5x5 grid?
Explanation
Unfortunately, the execution order in Scratch is a little bizarre. Whenever you edit a script (by adding or removing blocks, editing inputs, or dragging the entire script to a new location in the editor), it gets placed at the bottom of the list (so it runs last).
A good way to test this out is to create a blank project with the following scripts:
When you click the green flag, the sprite will either say "script one" or "script two", depending on which runs first. Try clicking and dragging one of the when green flag clicked blocks. The next time you click the green flag, the sprite will say whichever message corresponds to the script you just dragged.
This crazy order can make execution incredibly unpredictable, especially when using clones.
The solution
The only real solution is to write code that has a definite execution order built-in (rather than relying on the whims of the editor). For simpler scripts, this generally means utilizing the broadcast and wait block to run particular events in the necessary order.
For your specific project, I see two main solutions:
Procedural Solution
This is the most straightforward script, and it's probably what I would choose to go with:
(row and col are both sprite-only variables)
Because clones inherit all sprite-only variable values when they are created, each clone will be guaranteed to have the correct row and col when it is created.
Recursive Solution
This solution is a bit harder to understand than the first, so I would probably avoid it unless you're just looking for the novelty:
I have written below code for Back button event.
void Update()
{
if (Input.GetKey(KeyCode.Escape))
{
SceneManager.LoadScene("PreviousLevel");
}
}
In almost all cases this is fine. But I have found a small issue. When the user pauses the game, this doesn't work. When the user pauses the game, I do Time.timeScale=0. Initially, I gave a thought of modifying pause method and instead of doing Time.timeScale=0, use a bool variable and modify other pause logic accordingly. But then I also realized that I have over 14 co-routines whose logic is heavily dependent on Time.timeScale and modifying those will take a lot of time. They are heavily dependent on time.timeScale.
I wanted to know, is there any other method where I can write back button logic and which is not dependent on Time.timeScale.
It should work, input polling in Unity is not dependent on the time scale.
Try by inserting a Debug.Log inside the condition, and you should see it in the console.
Watch out if you put the if inside FixedUpdate and not Update: in that case it won't work since FixedUpdate is completely skipped when time scale is 0.
However, if you want a "dirty" trick, you can slow the timescale to a very low number, without using 0, i.e.: 10e-8. But use it with a lot of care, since it can lead to unwanted behaviour.
Input is dependent on time scale: GetButton() works normally but GetAxis() works inconsistently, for example getting mouse movement with GetAxis() works as expected, but getting Horizontal and Vertical returns 0 when timeScale is 0. You can get around this by using Input.GetAxisRaw().
It should also be noted that any axis also counts as a button, so you can also use GetButton() on those but the return value will be bool instead of float.
What is the difference between those two methods? Why should i prefer one?
1)
GameObject.FindGameObjectWithTag("").GetComponent<Rocket>().active = true;
2)
GameObject.FindGameObjectWithTag("").GetComponent<Rocket>().SendMessage("setActive");
thanks!
Sending a message searches through all the components of the gameObject and invokes any function that has the same name as the message. Not a 100% sure but Im sure this uses reflection which is generally considered slow.
SetActive() or the active variable set the gameObject as active or not. If its not active it wont render in the scene and vice versa.
First of all it seems there are several inconsistencies with your code above:
1) Components (and MonoBehavior) don't have an active property (active belongs to GameObject), so the first line of code shouldn't compile. In addition the most recente version of unity don't have active anymore, it's substitued with activeSelf and activeInHierarchy.
And btw, both activeSelf and activeInHierarchy are read only, so you can't assing directly a value to them. For changing their value use SetActive method.
2)
The second line of code shouldn't work either (unless Unity does some magic behind the scenes) because SetActive methods belong to GameObject and not to your Rocket Component.
Now, I suppose your question was the difference between:
gameObject.SetActive(true);
and
gameObject.SendMessage("SetActive",true);
The result is the same, but in the second way Unity3D will use reflection to find the proper method to be called, if any. Reflection has an heavy impact on performance, so I suggest you to avoid it as much as possible.