• 1) I did have an input key in the zoom settings that did something (was set to a zoom up and zoom down mouse origin input key). But I've disabled that and the camera still "drifts" towards the level of zoom I last pushed it in. Now my zoom settings are:
    Allow Zoom enabled, Remember zoom disabled, reset on target change disabled, block on target change disabled, zoom factor 1, use axis enabled, axis key (a none key), zoom key change 1, limit change disabled.
  • edited November 2020
    1) Drifting is due to the Height Damping, which makes the height change smoother, but doesn't change the final/target height of the change.
    Due to using the mouse movement for the changes, I'd recommend a lower zoom factor (e.g. 0.1-0.5) and either a height damping of 0 (i.e. direct translation without any smoothing) or a higher value, e.g. 5 or more.

    You'll probably need to test different values/combinations, as it also depends on the min/max height you use - e.g. having a large height difference with low zoom factor could make it a bit tedious :)
    Post edited by gamingislove on
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • 1) Ah! That makes so much sense!!! And it works like a charm! Thank you!
    gamingislove said: 2) That should be possible using the event system:
    - use one of the raycast nodes to e.g. find a position on the ground
    - use a Rotate To node to rotate to the found position (or object)
    - use a Grid Direction Rotation node with Nearest rotation to lock to the nearest grid cell rotation
    2) I've been working on this and struggling a little.

    2a) The first problem is that the camera isn't always pointing at the ground because it's up/down zoom can cause the camera/screen to be oriented such that it will hit the ground (i.e. if it is high up looking down on the player) or such that it looks out into the skybox (i.e. if it is low down looking slightly up at the player.) So I tried to put an object with just a box collider around the whole arena on it's own layer (named Backdrop) and use that as the backdrop layer. However I can't get it to ever hit that item? It'll hit the floor just fine as long the raycast is on the ground layer, but not the object. Is there something I'm missing here?

    2b) Second issue is that the character isn't rotating to the point of the raycast when the raycast does hit something (I have debug nodes telling me when the Raycast hits something or misses) and I'm not totally sure why. I'm using a Raycast to Variable node using local variable origin, value type game variable, value CameraLook, variable origin local, operator set, distance 100, layer mask backdrop, ray origin screen, all other settings disabled.
    Then I have a Rotate To node using actor, user, wait between, ignore X and Z, value type game variable, variable origin local, variable key CameraLook.
    Finally a Grid Direction Rotation with rotation nearest, actor user, wait between enabled.
  • edited November 2020
    2a) I'm not sure if a raycast from within a collider can hit the collider - try setting up separate colliders around the arena instead.

    2b) When defining the variable key in the Raycast to Variable node you'll usually use the Value value type, since you want to define the key that is used. Using the Game Variable value type will store it into a key that's stored in a string variable for the key you defined - this can be useful for complex systems, but doesn't work well in regular stuff like this :)
    Post edited by gamingislove on
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • edited November 2020
    2a) that worked!
    2b) and so did that. Thanks! I was definitely a little confused about what the right way to have it set up was between the various different nodes. It makes sense that you'd use value for that one and then game variable for the next one.

    3) Alright. I currently have the player control set up using Button player control type (with standard WASD controls), and Mouse camera control type. The controls are working exactly how I want them to but ultimately we hope to publish to consoles, so I need to change this so that both work basically the same but use analogue sticks (one for player control, the other for camera control). Is there a way to do this? Does it just involve changing the assigned input keys around? I'm not seeing a clear way to do it but could definitely be missing something.

    4) I'd like to set up two buttons, call them Next Target and Previous Target, so that when they're pressed the camera rotates to the first target to the right or left (respectively) of where the camera was aiming when the button was first pressed. I'm assuming that these should be set up as abilities, similar to the grid movement abilities that you've helped me make here. But do you have any pointers for where to get started with that?

    5) is it possible to have buttons that the player, through a menu, can assign abilities to? For example the quick access slots for abilities in Dragon Age Inquisition, or action bars in WOW. I'd like to be able to set it up so that players can assign different consumable items to the different directions on the D-pad in their inventory screen for access during combat, and to do similar things with their magic abilities.
    Post edited by Whatexists on
  • edited November 2020
    3) Since you'll probably also want PC players to be able to use controllers, I'd recommend setting it up for both right away by using ORK Input Key input origins for the input keys you reference in your settings.

    The ORK Input Key input origin allows you to use the input from multiple other input keys in a single input key, kind of like a 'master' input - e.g. you can combine keyboard and controller input into a single input key.

    Another alternative would be using a 3rd party input solution that can use multiple input sources (and e.g. also allows the player to change input configurations). I've used Rewired in the past and it works very well and is easy to set up. @braytendo posted a great tutorial and custom code to call from ORK here.
    Basically, ORK gets the input from the 3rd party tool like it would from Unity's input manager or via key codes.
    Post edited by gamingislove on
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • 3) Alright. Thank you!
  • 6) Currently when a battle ends the camera control returns to the first combatant of the player group, unless it ended on a different combatant of the player groups turn in which case it stays on them. Is there a way to make it always go back to the first combatant of the player group? And is there a way to make that combatant always the same combatant (e.g. the "main character" [my has 6 potential main characters and you choose from one at the start of the game. Out of combat you should always be running around as that dude or dudette.])
  • 6) Well, you're probably changing the camera control's target during the battle, either via the battle camera or in an event.
    Try using a Camera Control Target node in your battle end event using the Reset option. That should reset the camera back to the player combatant.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • edited November 2020
    6) I am changing it. I've put Camera Control Target nodes using the Reset option at the start of the battle end event and all of the turn end events. And it's still staying on the last controlled character instead of swapping to the main character. Currently Camera Control Target is disabled under Battle Camera and Battle Camera Type is Allow Events.

    Also a note: you can continue to control the last controlled character instead of the main character, but following is still enabled so you can run away from the main character but the main character won't follow you and the moment you release the controls the character your controlling will run back to wherever the main character is.
    Post edited by Whatexists on
  • edited November 2020
    6) Hm, is the main character part of the battle group or are you using a locked non-battle player?
    Resetting the camera control target would transfer the control to the player combatant at that time, i.e. in the battle end event it'd still be the battle leader (which is usually also the player).
    Post edited by gamingislove on
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • edited November 2020
    6) I am not sure and not sure how to check. =\
    They're added in a game start event via a Join Active Group node with group origin Active Player Group. Use game object disabled, use combatant group disabled, from other group disabled, use inactive enabled, learn abilities enabled, use start inventory enabled, use start equipment enabled, use init event enabled, set level default for both level and class level settings.
    Then a Spawn Player node.

    the Ally is added via a dialogue event started during the game via a Join Active Group node as well with different settings: Group Origin Active Player Group, use game object enabled, object actor, actor (the ally).
    Post edited by Whatexists on
  • 6) Well, if you're not sure, you're most likely not using it :)
    This would be a setup like e.g. in a Pokemon game, where your player isn't taking part in battles. In ORK, you'd make the player combatant leave the battle group and lock+hide the combatant (i.e. usually in your start event right after joining the combatant to the group).

    Hm, try using the Camera Control Target node and use the player group actor instead of resetting.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • 6a) that's really interesting. we're not doing that. Although I wonder if that would at all help with a problem we've been having where the camera resets to the player character during enemy turns and in between turns, including during the turn start events of allies. If we did a set-up like that could the player be in a like... overlook position so during enemy turns or inbetween turns the camera went back to an overview? Or is the player combatant simply not around in that scenario?
    (I've tried figuring out a solution to this before and figure out things that sorta worked but that we weren't entirely sure we liked. Not knowing what we want is part of the problem. Except that we do want the camera to be on the ally during their turn start event when there's a 'this person's turn is starting, are you ready?' banner that waits for input, and that when an enemies are doing things we'd like to be very clear what they're doing, especially if they're attacking allies.)

    6b) hmm... that does reset the Camera to the player character but the camera appears to be only part of the problem: it doesn't reset controls the player character as well!!! So the camera rotates around the player character but movement controls still control the ally I was controlling at the end of the combat.
  • 6a) That can be done in whatever way you want - e.g. either you destroy the (field) player or have it stand around at the side ... anyway, in battle, the player is recognized as the player's battle group leader (i.e. usually the first member of the battle group).
    If both player and camera control are on a different combatant, I assume that you've either transfered the controls somewhere (e.g. in a battle event, or using the Control Block Settings in your battle system's setup) or the player changed.

    6b) Sounds like you probably changed the player (combatant), or transfered control.

    I guess it's getting a bit too complex and the information too distributed accross multiple posts - could you summarize your setup:
    - used battle system type (also, you're using grid battles, right?)
    - control block settings of your battle system
    - battle camera setup (Battle System > Battle Camera)
    - what are you doing in battle start/end event and generally in battle events when it comes to player and camera control and maybe changing player (i.e. actually changing controls, e.g. via Camera Control Target - just using a camera position doesn't impact that)
    - are you using the Group Member Keys (Base/Control > Game Controls)?
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Sign In or Register to comment.