I'm looking for a way to remember which cells the player has their combatants in, so that in every battle the combatants will be in the same cells that they were previously. If the player uses a move command to move a combatant to a new cell, the combatant's new cell location should be updated and remembered.

What's the best way to go about doing this?
  • Hm, I'd say using custom scripts is the only way to do this currently. Using ORK's built-in functionality (e.g. storing cells in found objects) would only work if it's always the same grid game object and the scene is never changed.

    You could e.g. write custom event nodes to store the combatant cell's CubeCoord (its position in the grid) and place the combatant on the cell matching the stored coords.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • I am using a single battle scene and small 3x6 grid that is never changed, but the player is transferred to this scene every battle.

    I poked around the Store Grid Cells node, and I noticed an option to "Use Global Objects". Would this allow the storing of the combatant's grid cells even after the scene is changed?

  • edited August 15
    No, there's no way to find those game objects again, since they are destroyed when changing the scene.
    This would only work when staying in the scene.
    Post edited by gamingislove on
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Darn, well what is the ideal way to write a custom node? Any guides or tips?

    I don't want to alter the original ORK code, so I'm making a separate script. Just to trial and error it, I've copy-pasted the "Place On Grid" node in BattleGridNodes.cs in a separate file, using the same name space and requirements. Everything seems fine except there is an error on line 287.

    The line: combatants[i].GridCell == null
    The error: 'Combatant' does not contain a definition for 'GridCell'

    Not sure what I'm doing wrong at this point unless there are special steps needed to make a custom node.
  • Seems like you've copied the node from a previous version, there where some changes in the API in recent updates. Change combatant[i].GridCell to combatant[i].Grid.Cell to solve this.

    Also, I'll look into adding new nodes for storing a cell's coords and finding it based on that.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • The next ORK version will include 2 new nodes to store a cell's grid coordinates into a Vector3 game variable and store a cell into found/global objects based on grid coordinates from a Vector3 value (e.g. from the previously stored game variable).

    That'll allow you to create such a system :)
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Ah, yes I have not upgraded ORK to the most recent version. I'll give that line a try though

    That'll be awesome, thanks GiL! I can't way to experiment with the new nodes!
  • First, I'd just like to say thank you for updating ORK with these new nodes, GiL.

    Unfortunately I've gotten stuck getting them to work.

    In my Battle End Event, I'm using the 'Grid Cell To Variable' node to SET a global Game Variable to the Player Group's cell positions.

    Then in my Battle Start Event, I use the 'Grid Cell From Coordinate' node to SET a local Object Key to the previous Global Variable from the last step.

    After that node, I use a 'Set Grid Cell Combatant' node to place the Player Group to their positions in the local Object Key.

    This does not work - the player group leader is placed on the enemy grid(which shouldn't even be possible) and the other player combatants are not placed on the grid at all.

    I suspect that the 'Set Grid Cell Combatant' node is not finding the data from the Found objects variable. Should I be using this node or something else entirely?
  • You need to store the individual combatant's positions in their own object variables - otherwise you'd just store one combatant's cell.
    I'd say it's best to store it (Grid Cell To Variable) whenever changing a combatant's cell, e.g. in the grid move event when moving to a cell.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • edited September 7
    Ah, I see!

    So I've fooled around with this all day, and it still isn't working. My Leader Player Combatant is always placed on the first cell (0, 0) no matter what I do.

    Here are screens of the 3 nodes I'm using, in the order they would be called. If you could, do you see anything that looks off?

    For the Move Command Event:
    image

    For the Battle Start Event:
    image

    image
    Post edited by TZen on
  • Keep in mind that you initially don't have a stored grid position, i.e. you should either initialize the variables to default positions (e.g. in the combatant's object variable settings) or use a flag to check if variables are stored or not.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • I am accounting for that, I'm using 2 different battle start events. The first one accounts for not having any initialized value in the variable, and just places the party on the grid.

    Then I use the grid move command to actually store the combatant's cell in a variable.

    Then I have a second battle with a different battle start event. This battle uses "Grid Cell From Coordinate" and "Set Grid Cell Combatant" nodes. And this is where the entire thing fails and places the combatant at cell (0, 0) everytime.

    All I can think is that I'm using the wrong settings for the nodes (seen in the screenshots I showed you), or that perhaps the nodes are bugged.
  • Hm, I'll test this - the screenshots look correct at first glance.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Thanks! I'm eager to hear the results.
  • Hi GiL, have you had a chance to test this?
Sign In or Register to comment.