Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Thore

Pages: [1] 2
Share New Actions / SetParent Canvas Issue (and alternative action)
« on: September 22, 2018, 02:14:21 PM »

When using "Set Parent" on objects within the canvas, Unity will throw the error notification shown below. It still lets you play, but there are scaling issues.

Code: [Select]
Parent of RectTransform is being set with parent property. Consider using the SetParent method instead, with the worldPositionStays argument set to false. This will retain local orientation and scale rather than world orientation and scale, which can prevent common UI scaling issues.
HutongGames.PlayMaker.Actions.SetParent:OnEnter() (at Assets/PlayMaker/Actions/GameObject/SetParent.cs:38)
HutongGames.PlayMaker.FsmState:ActivateActions(Int32) (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/Classes/FsmState.cs:205)
HutongGames.PlayMaker.FsmState:OnEnter() (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/Classes/FsmState.cs:175)
HutongGames.PlayMaker.Fsm:EnterState(FsmState) (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/Classes/Fsm.cs:2767)
HutongGames.PlayMaker.Fsm:SwitchState(FsmState) (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/Classes/Fsm.cs:2714)
HutongGames.PlayMaker.Fsm:UpdateStateChanges() (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/Classes/Fsm.cs:2642)
HutongGames.PlayMaker.Fsm:Start() (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/Classes/Fsm.cs:1925)
PlayMakerFSM:Start() (at C:/Projects/Playmaker_1.9.0/Projects/Playmaker.source.unity/Assets/PlayMaker/PlayMakerFSM.cs:548)

Though I have no idea what I am doing, I somehow created an action using the suggested SetParent method which works and doesn't throw errors. I named it SetParent3 (there is already a second one in Ecosystem).

This action will do the (basic) trick, however, it currently has no other parameters (I have no clue how/what). If a regular wants to complete it, and upload it to ecosystem, you're super welcome. It would be best, I guess, when the default "Set Parent" works universally.


Share New Actions / ColorMix
« on: September 20, 2018, 03:56:06 PM »
Humble beginnings, part three. I made another tiny action.

You provide two colors, and a mix value (0.5 is 50% of each), and it returns you the resulting color, which you can store and use from there.

Use Case
You can tint sprites using the color field in the inspector. This action makes it possible for example to tint "just a bit" towards a second color, which is particularily useful when sprites use different tints, or when you want to change the amount of tint based on some gameplay parameter.

Playmaker Help / SetEventData + Enum?
« on: September 19, 2018, 09:47:28 AM »

I'd like to use SetEventData, which has all sorts of variable types in it, except for the enum. The critical part of the action is in the method, where all available types are listed.

Code: [Select]
               Fsm.EventData.BoolData = setBoolData.Value;
Fsm.EventData.IntData = setIntData.Value;
Fsm.EventData.FloatData = setFloatData.Value;
Fsm.EventData.Vector2Data = setVector2Data.Value;
Fsm.EventData.Vector3Data = setVector3Data.Value;
Fsm.EventData.StringData = setStringData.Value;
Fsm.EventData.GameObjectData = setGameObjectData.Value;
Fsm.EventData.RectData = setRectData.Value;
Fsm.EventData.QuaternionData = setQuaternionData.Value;
Fsm.EventData.ColorData = setColorData.Value;
Fsm.EventData.MaterialData = setMaterialData.Value;
Fsm.EventData.TextureData = setTextureData.Value;
Fsm.EventData.ObjectData = setObjectData.Value;

Fsm.EventData.EnumData is unknown, and I don't know how to declare enums in the fsm script. I'm aware that I can convert enums to something else, and then pass this on, but I'd like to keep things tidy and neat, if possible.

Can anyone help me with a bit of code that adds Fsm.EventData.EnumData to the Fsm script?

Share New Actions / Sprite / SetOrderInLayer
« on: September 06, 2018, 04:38:13 PM »
Gets the SpriteRenderer of suitable GameObject, and sets the "Order in Layer" property to an integer you provide.

In 2D games with a camera set to orthographic projection, the Z axis is ignored. The layers are used to roughly sort what is background, foreground etc. But within those layers, you use order in layer to determine what is in front of something else. With this action, you can change that order.

In my case, a character carries a weapon on their back. When the weapon is drawn, it needs to change order in layer so it's drawn in front of the character.

Share New Actions / GetAxisRaw (Tighter, Snappier Input)
« on: August 29, 2018, 02:32:19 AM »
Hello :)

You feel that the movement of your character could be "snappier" or "tighter", especially for a platformer? Then you want to try out this action.

What it does.
The action is identical to GetAxis, but has a checkbox to switch to GetAxisRaw, also at runtime. This also gives you the ability to try out the difference as you play, which is good for prototyping.

A little bit of explanation
The typical way, Input.GetAxis gets the input from the player in a smooth way: assuming a controller with an analog stick, the axis value is smoothly cranked up to to 1 when you push right (-1 when left). Now, there is a twin called Input.GetAxisRaw, which does not smooth out the input. It's either hard left (-1) or hard right (1), with gives a snappier and tighter control, which might be more suitable for your game. You can also use the raw to calculate your own smoothing (see Unity's documentation linked to above).

General Discussion / Tutorial: Custom Scripting 101
« on: October 07, 2017, 11:01:53 AM »

I came across this small video series and found it super useful. It goes over stuff that is probably second nature to coders, but for us Playmaker people often quite obscure, especially when you transition to some light coding and custom actions yourself. Enjoy.

Playmaker Help / How to: FSM to FSM Communication
« on: October 02, 2017, 02:23:37 PM »

Despite that I have built quite a lot of mechanics with Playmaker already, I still feel unsure about the FSM to FSM commuication, which is an increasingly common challenge.

For example, creating a new object and passing variables to it. What's the best way to go about it? Are Send Events always fast enough to ensure the variables are set in Start state? Or should you create the object, have Start run empty (or only do configuration that are self-contained), set variables, and then trigger a global event to really set it into motion?

Another example: When a projectile hits a target: what's the best way to do this? Is it better for the Health FSM to be hit, then get projectile information, or is it better that the projectile hits an object, and passes its variables onto the object? Or some combination thereof?

Are there any good tricks that make communication between FSMs less complicated? A rule of thumb or something of the sort?

I also ask because I've seen many different tutorials and even more ways how this can be done, but none stick out as clearly superior. Any pointers, and reasons?

Action Requests / Camera: Smooth Follow Action + Distance Damping?
« on: September 17, 2017, 08:50:21 AM »

I struggle somewhat to get a more advanced camera going, that needs to change how fast and loose it follows the player (I want this based on distance, but possibly also on other parameters). Smooth Follow Action works fine, but it always snaps into place.

I tried also the following: I created a game object, called Shadow which uses Position Smooth Damp. I get the distance to player, substract that from a value and feed this as the smooth time. In other words, the greater the distance, the faster it will follow. The shadow now follows the player in a rubberband-like manner. The further away you go, the faster it will try to catch up.

I set the camera to Smooth Follow Action, and another time also as a simple child (for the offset) of this Shadow object, rather than the player directly, which gets me somewhere near what I want. The problem is that this creates the typical Non-FixedUpdate jitter, in whatever variant I tried.

Maybe there are other ways to get what I want which is: divide the screen into three parts vertically, A|B|C. When the player is within B (the middle section), the camera is supposed to relax and move slowly. When the player moves towards either A or C (towards some threshold, A|B or B|C) the camera must speed up and basically lock onto the player as long as they run in this direction. Ideally, it's possible to "lock" into the player and release gradually by float.

If you have any idea how I can build this, or any pointer what I could try, I'd greatly appreciate it.

Playmaker Tips & Tricks / Improving The Workflow
« on: September 15, 2017, 12:40:30 PM »
It can be hard to keep an overview, once there are dozens of FSMs buzzing and sending events and variables around. There are also ways to make it easier, or more fun, to work with it all.

Here are a couple of workflow tips that will help you, or inspire you to manage your project and will help you staying on top of the ever-growing list of FSMs.

Renaming Actions
On Windows, you can press F2 to rename items (folders in Explorer, Game Objects in Unity, also paths in the animations, …). Did you know that you can rename actions, too? Place the action you want to use, then press F2 (or double-click) and rename it to something that gives you an idea what it does in your context. You can make the action list more intelligible and less abstract this way, almost like pseudocode. However, this makes it more difficult to see what the original action name was. Don't despair. Just hover over the little book icon and the tooltip tells you.

As pointed out by djaydino below, be mindful when working in a team. You can of course keep the action name, and just add to it, e.g. "Get Game Object: Player 1" or if it's obvious from context "Get: Player 1" and you have the best of both worlds.

Floating Labels & Headlines
This is more of a hack. States are also simply boxes with a name on it and a (possible) comment box underneath. You can appropriate them as a headline and paragraph, or as a floating label.

Place an empty state not connected to anything, and colour it (right click on state) with a colour used only for that purpose. That way you can tell these non-functional bits apart more easily. Now name them, and place them anywhere you like. You can add a kind of headline to functional parts of the FSM, for example.

Incoming Event
Let's suppose you have a state where you GET variables from somewhere else, or you read from a script. In other words, the FSM relies on incoming information. This is hard to see in the graph overview. How about using this hack in a similar vain as the floating label.

Create an empty state floating in thin air. Add an event like "Send Variable" or "From Script" to it, and connect it to a state which actually gets the variable from somewhere else. Colour both the state and the link, perhaps use the circuit link style to make it stand out from functional bits. Now you have something similar looking as a global event "coming in", but you can name the state and the event anything you like, and see clearly where variables are injected.

Tagging Nomenclature
I use some simple keywords I'll add into the states "description" field (in the State tab), like #Anim, #Send, etc. I use these to tell me straight away where dependencies are. I then see where, for example, animation events are send off. Short tags do the trick, and are fast and better to comprehend than longer explanations.

Global Events ALL CAPS
Global events are typically named uppercase. That way you can quickly tell them apart, and there's no issue with uppercase spelling (e.g. was it "turn on" or "Turn On"? It's "TURN ON")

Comment Action
Did you know there's an actual comment action? It's very useful to add information inside the states without cluttering up your graph.

Comment Action Dividers
Since you can rename actions, see the tip above, you can rename the Comment action into _______________, +++++++++++, ###########, ..................., ————————, ––––––––––––, --------------- and so on. Now you can structure your action list that way. Neat, isn't it?

Comment Action as Headline
Especially when you want to keep your graphs clean, you'll cram a lot of actions into one state. To still keep an overview, you can place Comment Actions, switch them off (just to be sure) and name them like /// EVERY FRAME /// etc. this way, you can group a block of actions with a headline.

Documentation URL
I haven't used that feature yet. However, the FSM has an option to include documentation right on the FSM tab.

Colour Coding
You can set up additional colours in the playmaker preferences and colour states and even the links (also separately). I sometimes succumb briefly to colour, but refrain from doing it, unless to draw attention to something. If every FSM looks like a rainbow, you have no clarity. Other users (see comments below) use them to differentiate whole groups of states.

Color Naming
You can name your colours and add new ones in the preferences, and that way determine more precisely what they mean. If you call the colour "WIP" (work in progress), you will probably use it consistently, and you will also see in two years what Red was supposed to mean.

You can switch on grid snapping which makes structuring and arguably grouping better. Obviously, you can move the states around and group them. Use this for your advantage. Arrange the states of loops close to one another, then leave some nice distance to the next functional block, that way you can keep a good overview even in one FSM that does many things. Forget about symmetry and other such superficial criteria. Think of the FSM to flow top-down, for example; or from left-to-right -- whatever serves your purpose.

You can also control on which side the link arrows come out, by selecting the transition, hold CTRL and then left/right arrows to lock them in place. While I am at it, CTRL+Click on a state creates a FINISHED transition. CTRL+dragging out the link creates a new state that's already connected to the transition.

Naming Conventions
You have a VampireEnemy, and a SlimeEnemy? It may be better to adopt a general-to-detail naming convention for your variables. EnemyVampire, EnemySlime, etc and they are listed next to each other. Using space seems to create no problem, like "Enemy Vampire"; no need for clunky_names. Commonly, variables are also typed like enemyVampire (first lowercase, then every new word attached, starting uppercase). This convention is interpreted in Unity Editor as separate words when used in scripts (enemyVampire makes "Enemy Vampire").

FSM Paths
Name your FSM for example "Gameplay/Jumping" and you'll see in the FSM navigation bar right above the graph view, how it is now tucked inside a menu point "Gameplay". You need to keep this in mind when referencing it.

Right click on the graph view and set a watermark. You can add your own graphics into the folder and use them. Depending on your game, it can give you another quick and visible bit of information. Differentiate game logic FSMs and those that are for UI or effects, maybe. You can mark critical FSM, or use it as a stamp to assign ownership of the FSM when you work in a team (alien-head means Alice is responsible for this FSM). Maybe your game has two opposing sides pitched against each other, with nearly identical FSMs: watermark the sides. Watermarks can also be coloured images. I use this to mark FSMs with player input (movement, jumping, controllers etc). 

Variable Categories
When you select a variable, you can also set a category in the variable tab. Categories you once typed in, appear behind the tiny arrows next to the input field in subsequent variables. That makes it easier to keep the categories consistent. The same tip as above: don't succumb to categorize just because you can. The most important categories you want to use is Runtime and Config. In Config, you put those variables that you need to adjust; variables that are given. Into Runtime, you group all the variables that are overwritten and used for computation when the game is running (where it is pointless, or even game breaking when you adjust them).

On-the-Fly Variables and Events
A small workflow tip. You probably noticed that you can define variables and events right in the action. You find the option in the small dropdown menu where you set them. Once you do define an events there, a red box is popping up, telling you that no transition exists with that event (since you haven't yet added it). If you click on this box, it will create the transition on the fly. This happens when you pick an event that has no transition yet, and it's the fast way to populate especially switches that call for great many events. If you ever want to define ten types of events to use later, stop right there, and mind this trick.

Generic Events
(Non-global) event names don't have to be unique. You can create new events for each state individually ("go to jump"), but you can save some time if you pick more generic names, like Do, Next, Done, Fail, True, False, etc. The state only cares about the events as set in it.

Global Event Tricks
When you send a global event to an FSM, it will find it, and induce the flow there, no matter where it is. For this reason never use global events for anything other than to specifically communicate "globally". But you can also use this inside one FSM. Suppose you anyway use a global event called "AWAKE". Instead of looping back with a link, you can also send AWAKE to this same FSM, going back. This might be useful when your FSM is large and you want to "jump" from one place to another. Watch out, though, it might be a sign that your design is too much spaghetti, and perhaps needs to be broken up.

Shortcut Method Do Once
That's more a design pattern. Many actions do their thing. Then they trigger an event when they are done, or when some condition was met. You can often times leave the events not filled in, say Float Compare, only care about whether the float is smaller, and ignore equal and greater. You can take advantage of this fact, because this is good shortcut. That means, when you place such actions further above in the list, and they get triggered, the rest of actions down below will be skipped.

For example, you want that the actions below are only triggered once. But the sends keep coming in, constantly retriggering the FSM. Place a bool test with a variable that stands for "did we do this already?" on top. If true, do event "Skip". At the very bottom or in a subsequent state you set the variable "Did we do this already?" to true. Hence, when the list was used once, it's set to true, and when the chain is triggered again, the bool on top will recognize this and skip the rest. Later you need to reset the bool to false again. Take advantage of this to create a short cool-off period of retriggering events.

Think Ahead
It can be useful to get a fresh beverage and open a simple txt editor and type out what you exactly want to achieve. What kind of elements do you probably need? Are there different ways to solve the problem? Can you make it simpler with less dependency? Also, think about what exactly your mechanic is trying to solve; what gameplay purpose it will have? It might seem silly, but you should think whether your platformer really needs jumping, for instance. Imagine seriously how a game would be like without that mechanic (this is also great to get innovative games). Consider also inverting the problem, if you cannot trigger something, can you untrigger it? You measure from player to obstacle, how about from obstacle to player? etc. Make this a habit, and you have some clarity when you approach the situation.

Do the Research
Unless you know exactly what you're going to do, check some resources to give you a good turbo start on the frequent problems; get a glimpse of what kind of variables you probably need; and perhaps even find detailed talks, papers or videos on such seemingly simple things like jumping or camera movement (here, here) in a platformer -- stuff that is going to put your game above the competition when implemented with some juice.

Perhaps this is useful to some people. :) Please add your own ideas, or comments below!

EDIT: expanded a bit, made some improvements to the text.

Playmaker Help / FSM ↔ Mechanim (Set Animation Trigger behaves like bool)
« on: September 12, 2017, 01:26:34 PM »

TL;DR: I send a Set Animation Trigger to mechanim, but instead of sending only an impulse, the triggers appear to be on or off, behaving like bools. I ruled out that I accidentally set them every frame.   

Q1: You see the triggers are filled or "on". They were triggered once (correctly) after spawning, because the character drops down shortly. The states that send the anim trigger are passed through only, and marked with the exclamation marks. There are none on Ground.

Q2: Why keeps velocity fluctuating as you see in the screenshot despite that the character is completely at rest? (it seems to have no effect on gameplay, though)

EDIT: I found out that triggers work like bools, but are supposed to be reset when the animation clip transitioned. Someone over at Unity wrote this:

Quote from: User
... Use triggers only if you are sure the animation will play full, from begginig to end, before issuing another trigger...

Feature Requests / Interface/Usability: State/Action Hashtags
« on: September 11, 2017, 10:26:35 AM »
What does it try to solve?
Where did I trigger the animation? Where do I wait for input? Where did I use this variable again? Where was the FSM state that I wanted to improve? You know these problems. You have to click through FSMs which can be quite laborious, and you cannot see at a glance what's relevant for you.

The solution comes in several stages. The basic one is a solution, the others make the feature even better.

Basic: Introducing State/Action Tags. The user can #hashtag words in the State Comment, which are then searchable. That way you can instantly see, and find, whatever is relevant for you.

Improved: In the improved version, the hashtags on a state are added automatically, when certain actions are added to a state (and removed accordingly). The user has to switch on an option, and then determine somewhere which actions should automatically add the hashtag to the state they're in. It's probably unwieldy to maintain a huge list, so how about an input field that is directly next to the manual and options button at the actions (but once set on an action, it obviously counts for all identical actions anywhere). It's first blank, but there you can set the tag's name and a label colour. See my quick mockups how it could function.

Use Case 1: You have a few places you aren't quite happy with. You simply add #WIP to the state's comment field. Weeks later, you have no idea where you wanted to make improvements. Luckily, you can use the tiny search bar, type in # and it shows you the hashtags you have used, or you when you remember that it was #WIP, you can type that in straight away. Click through the list in the hamburger menu next to it, and quickly go to the correct state.

Use Case 2: Suppose, you have some FSM and you are interested to know precisely where stuff is sent off to the animator. This can be quite hard to see, especially not at a glance, unless you use colour-coding which can be quite cryptic. Luckily, Playmaker now offers automatic hashtags! You go to the options and switch them on. Now a tiny label icon appears right next to the manual and options icon on the actions. You go find just one instance, say "Set Animator Bool", hit the label button, where you define the tag and a label colour. Et voila! Now everywhere where "Set Animator Bool" is used, you see the labels appended after the comment (if no comment, at the same place).

Use Case 3:   Oh noes! You just cannot find any instance where you used "Set Animator Bool". No problem, just make a state anywhere, add the action, and then set the label. If you used the action already, they're now all visible. If not, fine, all future instances will be automatically labelled.

Playmaker Help / How to fix a GUI update problem?
« on: September 10, 2017, 08:14:02 AM »

I have a holder Game Object, and as a child, a GUI text Game Object. The whole thing sits in the canvas, and generally works just fine. An FSM on the holder is constantly (loop, not every frame) checking some condition, and when the condition is met, either activates, or (via another route) deactivate the GUI text child. It's thus very simple. The loop either goes one route, and has it active, or the other route, and keeps it inactive. This also works correctly.

This object is a prefab and a few of these populate the scene, and they all work just fine. Except one, or two, occasionally, that are not visible (as if inactive) despite that they are truly are active, and are supposed to be visible.

What happens: The Canvas does not show it, or update correctly. I tried the "U GUI Canvas Force Update Canvases" action to no avail. Also, when I move the object a bit by hand during runtime, it suddenly correctly displays the actual state.

I could do something hacky like move the thing by a few pixels and see if this forces the update, but that cannot be a good solution. Any ideas?

Playmaker 1.8.4

Action: Load from File
Expectation: Trying to load a file that does not exist should lead to triggering the Failure Event. Likewise, if something is found, it should trigger the Success Event.
Bug: When no file is found, it prints out "FileNotFoundException: Could not find file "<path>", but the state is stuck in the state where this action sits, rather than triggering the failure event.

I also like to request a tooltip change on File Path to "e.g. Assets/Test.txt" to make it clearer. For consideration: I tried to understand how paths work, I often encountered the path to look like this "(Application.persistentDataPath + "/test.txt")", so there could be an issue with some type of builds (but I don't know).


EDIT: found out that it ignores both Success Event and Failure Event. On success, it continues to next action (or to next state via finished), and is still functional.

Found this after I wrote the below, my report is a bit clearer:

Playmaker version 1.8.4
(latest as of now)

Action: String Split
Issue: \n \t  separators don't work.

Expectation: According to tooltip, \n should accept a line break, and \t should accept a tab as separators.
Bug: It will treat any n or t as separator, e.g. D'artagnan will be split up. Also, will not split up at actual line break or tab.
Repro 1: make a string value, and set it to D'artagnan, then try the action with \n and \t.

Repro 2:
  • create test.txt in asset folder, put d'artagnan Athos Aramis Porthos but each name into a line (or tab).
  • Make a new FSM, add action "load from file" in first state.
  • path is Assets/Test.txt, set variable e.g. "Test"
  • next state, add the String Split action, try with \n or \t, and string array as e.g. "Data".
  • Play, watch Data

Related, a small improvement would be to update the tooltip of Action "Load from File" (which I'm using in conjunction). Change the tooltip to: "e.g. Assets/Test.txt" giving users an instant idea where the text to load is expected.


Hello :)

The Issue
I can easily add a script to an object by name (with the "Add Script" action), but then I find no way to access this script for further use, (for example with Get/Set Property). How can I access the script attached?

When I want to reference it, I need to specify "Object Type" from the menu, or use drag and drop and it creates the reference on the fly, but since "Add Script" is dynamic, I don't know beforehand which script is exactly added at runtime. Any ideas? Alternatively, is there a way to define Object Type by string?

Edit: yet another possibility, could a few lines be added to "Add Script" so that it allows the object to be stored for further use?

Thanks in advance!

Pages: [1] 2