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.

Messages - Deek

Pages: [1] 2 3 ... 6
Aw man, wasn't aware that there was already a package for most NavMesh related stuff. I only searched for things like "Nav", "Nav Mesh" and "Agent" :P (maybe those keywords should be added to the package, otherwise you have to specifically know that it's called something like 'Path Finding').

Oh well, no biggie. I'm gonna remove them from the Ecosystem again (except for 'Nav Mesh Agent Move To' since that one has quite some useful additions), because most of them have pretty much the same functionality as the ones in the package.
That's why I don't think there's the need to merge any of them to update the package and it should be better to keep the fundamental actions in that package and have the few more specialized/custom made actions loosely floating around in the Ecosystem to keep them even more optional.

I'm actually glad that there's already a more exhaustive list of actions for this Unity feature, because it means there is less groundwork to be done and keeps away the need for more actions in that regard.

Share New Actions / Various Navigation Actions (NavMeshes, -Agents, ...)
« on: February 04, 2018, 06:26:31 AM »
- Removed most of them again, since there's already the 'Path Finding' package on the Ecosystem that contains similar functionalities -

I started creating actions for Unity's 'Nav Mesh' pathfinding system, since I recently started using it and there didn't seem to be a lot of them on the Ecosystem or anywhere else. If you find any problem with them or want additional features on one of them, let me know (either here or on my main post).

Action Name
Nav Mesh Agent Get Acceleration★★★
Nav Mesh Agent Get Angular Speed★★★
Nav Mesh Agent Get Auto Braking★★
Nav Mesh Agent Get Auto Repath★★
Nav Mesh Agent Get Auto Traverse Off Mesh Link★★
Nav Mesh Agent Get Avoidance Priority★★
Nav Mesh Agent Get Base Offset★★
Nav Mesh Agent Get Height★★
Nav Mesh Agent Get Path End Position★★★
Nav Mesh Agent Get Path Next Position★★
Nav Mesh Agent Get Path Status★★★★
Nav Mesh Agent Get Remaining Distance★★★★
Nav Mesh Agent Get Speed★★★
Nav Mesh Agent Get Stopping Distance★★
Nav Mesh Agent Get Velocity★★★
Nav Mesh Agent Has Path★★★★
Nav Mesh Agent Is On Nav Mesh★★★★
Nav Mesh Agent Is On Off Mesh Link★★★★
Nav Mesh Agent Is Path Pending★★★
Nav Mesh Agent Move To★★★★★
Nav Mesh Agent Pause★★★★
Nav Mesh Agent Reset Path★★
Nav Mesh Agent Resume★★★★
Nav Mesh Agent Set Acceleration★★★★
Nav Mesh Agent Set Angular Speed★★★
Nav Mesh Agent Set Auto Braking★★
Nav Mesh Agent Set Auto Repath★★
Nav Mesh Agent Set Auto Traverse Off Mesh Link★★
Nav Mesh Agent Set Avoidance Priority★★
Nav Mesh Agent Set Base Offset★★
Nav Mesh Agent Set Height★★
Nav Mesh Agent Set Speed★★★
Nav Mesh Agent Set Velocity★★★★
Nav Mesh Agent Warp★★
Nav Mesh Find Closest Point★★★★

Oh ok, so you want it to go vertically and only clamp the sides. You could still use my first suggestion with slight modifications:
- In your STRAFE LEFT state you seem to be missing to get the x-position of your player on update, without that your camera just stays in one place
- In my first example I was using a float operator action to add a horizontal offset of 0.3 which moves the camera to the right, but in your case where your camera is mainly centered on the player it makes more sense to set the float operator to divide between 0.5 and 0.9 to achieve something like the camera in the video, where it doesn't go all the way to the players x-position but to a degree in its direction (the more you divide it towards 0, the less your camera will move to the players position, creating an indirect "clamping" of your cameras movement)

If you want to actually clamp the camera, you would need to use the action 'Float Clamp', specify the min/max values and restrict the 'CameraFollowPlayerPos' variable with that; but the other suggestion with the float operation should be better, since it automatically creates an offset between the camera and the player like in the video.

Also in my first example I was using the "... Advanced"-variations of built-in actions from the Ecosystem that add the option to run the action functionality on fixed update, which makes any movement rely on physics rather than time-based calculations. So if you encounter any jittery/stuttery movement I'd suggest trying those (but then you'd also need to run all those actions on fixed update for it to work).
Whenever possible, it's usually better to run actions in fixed update when it comes to RigidBody stuff, like movement or change in position.

I couldn't view your referenced video (either removed or geo-restricted) to get a grasp of what your goal is, but my best quess is that you want your camera to follow the player only on the x-axis.

For that I present you two options:
1. Get only the x-axis in the world position of your player on fixed update, give it an offset if you don't want your camera to center the player and set the x-axis in world position of your camera, like this:
Then you can set the height (y-axis) of your camera individually because it doesn't get touched by these actions. The operation in the middle adds an offset of 0.3 in world space, meaning the camera (in my example) is a third further to the right on the x-axis, so that I always see ahead of where he's going. If your player isn't just going into one direction, you can dynamically change the offset to the direction hes facing and how far he should look there. This method also allows your player to jump or fall, without the camera following the player.

2. Follow the player smoothly with the camera with the action "Camera 2d Smooth Follow" from the Ecosystem, and calculate the 'Y Offset' value against your player's y-position; which is a bit more complex and inaccurate, but this action allows for the camera to have a smoother, more wobbly effect, especially when changing directions.
There's also the Corgi Engine asset specifically build for 2D games which comes with several functionalities that help moving the camera according to the player's position and even adapting it to several objects-of-interest on the screen, and maybe other assets that allow to manipulate the camera more easily, but I think you can come pretty far with PlayMaker alone.

In general, when it comes to moving any camera around, it almost always leads to guess-work, which offset is ideal and where to put the camera at what time; that's why this is an area where I suggest you to experiment and play around, to see which setting feels best for the vision you have.

Share New Actions / Re: ...just another big Custom Action collection
« on: January 19, 2018, 06:48:18 PM »
Thanks for your feedback and sorry for the late reply (busy workweek).
I've noticed that error message already back then when creating that action but started to ignore it, since there were a few ways to circumvent it; though I knew that this was anything but ideal.
That's why I looked into it (and also because of your "reminder" :P ), created a better version and found out a few things on what caused it.

You can now get the improved and working action "Send Events" from the Ecosystem, should likely convert any 'Send Event Multi' actions to that and delete the SendEventMulti.cs from your Custom PlayMaker Actions folder (or keep it if you want).

The problem was, that the default 'Send Event' action uses an FsmEventTarget (Self, Broadcast, ...) and an FsmEvent variable, which get linked internally, so that depending on the selected EventTarget, the Event either only shows global variables or also local ones and automatically checks if the selected target does have the global event or not.
Since I was using an FsmGameObject[] (-Array) instead of FsmEventTarget in my "Send Event Multi"-Action, the FsmEvent variable had no target at compile time to check against, thus it always showed all available events and threw an error if it couldn't find a matching event/transition by default.

First I created another version with an FsmEventTarget[] instead of the FsmGameObject-Array, but that also didn't seem to work and made everything more bloated + you had to click more often to set up even one entry.

After that I thought of letting the user only define the EventTarget once and have him be able to select several of these targets, but since I couldn't directly manipulate the FsmEventTarget class itself and intervene it's functionality, I had to create my own version of it by creating a custom inspector that mimics the default functionality by only showing the relevant fields depending on the selected target type and hooked up matching functionality in the actual action.
I've added even more options than the standard version provided, like only sending events to FSMs with the right FSM-name, searching for SubFSMs by their name and hiding/disabling the delay field when either Broadcast All or Every Frame is selected.
But even after that, the error still showed up and I couldn't find a way to tell the FsmEvent that it should only show global events when a certain EventTarget was selected, until I found that someone already posted a similar problem on this forum (here).
I adapted that "temporary" fix (since it seems like he didn't add that NoErrorCheck-attribute) to get the FsmEvent into thinking that there is an FsmEventTarget available which won't get drawn by my custom inspector and now it stops showing that pesky error.

So the final result isn't 100% perfect, but at least way better than my inital attempt.

There are several approaches on how you can debug such behaviour:
1. Observe the AudioSource components you're referencing, to see if any of them or their GameObjects get disabled at runtime;

2. - if all those actions are in one state, you can use the halving-technique by disabling/deleting half of all the actions, then run the game to see if the error still gets thrown; if yes: halve the remaining ones, if no: undo and disable the other half until you close in on the action(s) that are causing trouble (of course you shouldn't save the scene during debugging to easily roll back any changes)
- if you have those actions in several separate states you can just exclude certain states by not transitioning to them to see which of the remaining states throw errors and then narrow those down by halving their actions;

3. Use the FSM Log to see what actions and transitions the current FSM goes through or the FSM timeline to see, when which state/action gets called (both show only information at runtime and are located at the Menu Bar>PlayMaker>Editor Windows);

4. Check if there are any errors in the Error Check window (at the bottom left of the PlayMaker Editor, normally showing 'No Errors' with a green circle) that could give additional info on wrong action setup

But judging by the error you're receiving, my best bet would be that there is just some other action possibly from a different FSM disabling the targeted AudioSource(s); if so you'd need to find that through different means.

Alex Chouls is the creator of PlayMaker (at least from my understanding) and you see his personal directory in pretty much every PlayMaker related log because it traces the error back to its source and that's where they keep/kept the original/main PlayMaker version that gets distributed to every user (some details might be wrong but that's the gist of it).

Also weirded me out whe first using PlayMaker to see a different directory than my own in the console, but it seems that they either didn't care to change that or that Unity requires a source path anyway.

Regarding your problem: Could you provide a screenshot of the action and the AudioSource component you're trying to access? Reading from the log you're using the Action 'Play Audio' and referenced an GameObject with an AudioSource in "Game Object" that is disabled (or the GameObject itself) at runtime when this action gets called.

Playmaker Announcements / Re: PlayMaker 1.8.5 LateUpdate handling change
« on: December 30, 2017, 02:18:38 PM »
I went through my scripts searching for every instance of OnLateUpdate() to make sure they are up-to-date after this change (luckily quite easy with VS2017) and found that (unlike most PlayMaker and custom actions) the following actions aren't updated with the OnPreProcess()-prerequisite yet:

PlayMaker Actions (1.8.5):

Custom Actions:

For the iTween one you'd need to add:
Code: [Select]
public override void OnPreprocess()
    if(updateCall == PlayMakerUpdateCallType.FixedUpdate)
        Fsm.HandleFixedUpdate = true;

    #if PLAYMAKER_1_8_5_OR_NEWER
    if(updateCall == PlayMakerUpdateCallType.LateUpdate)
        Fsm.HandleLateUpdate = true;

For every other action the following suffices:
Code: [Select]
public override void OnPreprocess()
    #if PLAYMAKER_1_8_5_OR_NEWER
    Fsm.HandleLateUpdate = true;

You might want to delete this (my) post after updating those actions to keep this topic clean or notify me to do so.

Playmaker Help / Re: API FsmVar get/set 'Category' and get 'Used' count
« on: December 27, 2017, 07:16:19 AM »
For the categories you need to get the reference to your desired FSM (or iterate through all available FSMs by using Fsm.FsmList or Fsm.SortedFsmList). Of course you also need the PlayMaker using directive:
Code: [Select]
using HutongGames.PlayMaker;and from there on you can get all variables and in there all categories, like so:
Code: [Select]
yourFSM.Variables.CategoriesThis holds an array of all categories in that FSM (the first entry is empty, because it's the default category where all unsorted variables land), which you can get or set (though I couldn't find how to set the category of single fsm-variables).

For reference, here is how I get a list of all categories from a specific FSM in my own debug window:
Code: [Select]
string[] allCategories = activeFSM.Variables.Categories;
for(int i = 0; i < allCategories.Length; i++)
    //skip empty categories to only display relevant ones
    if(allCategories[i] == "" || allCategories[i] == null)
    GUILayout.Label("Category " + i + ": " + allCategories[i]);

Unfortunately, I also couldn't figure out how to get the used-count of each variable and I think it only gets calculated inside the PlayMaker Editor window script or somewhere else, but I might be wrong. There could be something in other directives like HutongGames.Utility or a helper function nested inside Fsm.[...], but I haven't found anything related yet.

Playmaker Help / Re: Does Playmaker has Cache or something?
« on: December 27, 2017, 06:32:14 AM »
Do those still persists after you pressed the 'Clear' button in the console window or after restarting Unity?

Usually those types of warnings are only messages/notifications that are there to inform the end user.
If they don't stay there and you don't need these variables anyway, you should be good to go.
If they do, you might want to copy one of those errors or make a screenshot of them and post them here.

It could be that the missing variables are still referenced in some actions inside the FSM they were previously in, though it should also show related errors in the Error Check window (in the PlayMaker Editor at the bottom left). Then you would have to go through them and change the linked variables.

Playmaker Help / Re: Compare colours
« on: December 22, 2017, 04:46:13 PM »
Because I thought this would be a good idea for an action, I made one that is comprehensive enough so that you can specify how many colors should be compared to one another and what parts (r, g, b, a, or any combination between them).
With it you can send single events on matching occurrences or save as a bool, if at least one color matched the specified part of the main color.

Even though you already created a small fsm that handles your requirements, you might still want to use my action to cut down the logic into one action.
I'll probably put it onto the ecosystem soon enough, but for now you can find it in the attachments to this post.

Playmaker Help / Re: "Send event" followed by "Mouse Pick Event"
« on: December 19, 2017, 12:21:38 PM »
The problem doesn't lie within the "Send Event" action (so you can ignore that one), but with how the "Mouse Pick Event" functions: It only checks where your mouse is currently at and sets that in relation to the specified GameObject.
If the raycast that gets shot from your current mouse position hits a collider/trigger on that GameObject, it fires the 'Mouse Over' Event, in any other case it fires 'Mouse Off' (the 'Mouse Down' and 'Mouse Up' events can also only fire when the mouse is currently over that GO).
It fires 'Mouse Off' whenever it can't detect the GameObject, which can be caused by several things:
  • the 'Ray Distance' is too small / the GameObject too far away (unlikely)
  • the targeted GameObject doesn't contain a collider or rigidbody
  • you need to specify the layer of the targeted GameObject in the 'Layer Mask'
So you should really only use the 'Mouse Off' event option when you are certain that the mouse is currently over the desired GameObject and want to detect if it moved away from it.

Feature Requests / Re: HideInInspector-Attribute for custom actions
« on: December 17, 2017, 12:50:54 PM »
I created this request just before learning about
Code: [Select]
EditField("<variablename>"); with which you can draw single fields in a custom inspector. So there's no real need for that HideInAction attribute.

By using standard variables you would lose the ability to set the fields to none if you want the variable to be an FsmVariable, and I don't think you can access private variables from the inspector (at least I tried it back then, though with FsmVariables), but thanks anyway.

Share New Actions / Re: Authoring Custom Actions
« on: December 16, 2017, 08:55:27 AM »
That would be very neat and there seem to be various ways to create/generate c# code at runtime, like  CodeDOM, Roslyn, T4 Text Templates (apparently not supported by Unity), or just having several static classes/dlls that get integrated when needed, though it seems a bit over-ambitious and quite the time sucker.
But if you're determined to do this, I would be absolutely looking forward to it and also interested in seeing your progress on this (you might lead a little dev diary in the "Work In Progress..."-section or somewhere else, where you could also get feedback from others on what to improve or can ask for help when you get stuck somewhere).

GUI-wise it shouldn't prove much of a problem, but I see a few more other possible obstacles on that endeavour:
- in actions you only see the variables, not the functionality behind it, so you would need two ways to customize, one for adding variables and one for adding the functionality behind it
- the code blocks would have to interact with each others flawlessly, making it also difficult to add to them, as that could break functionality on other parts, and since they get added at runtime and likely are supposed to be combined with any other code block it makes debugging even more difficult

Just trying to show some difficulties that you could encouter, but you should definitely try it.

Feature Requests / HideInInspector-Attribute for custom actions
« on: December 15, 2017, 08:53:09 AM »
It would be great if the [HideInInspector] attribute could also work on custom actions, since it doesn't seem to do anything on variables and it would be helpful when creating custom inspectors to hide certain fields (as I'm also not friends with automated properties).
If you'd do create an extra attribute for that, might as well call it "HideInAction" to differentiate.

Pages: [1] 2 3 ... 6