{"action":"created","issue":{"url":"https://api.github.com/repos/craftyjs/Crafty/issues/917","labels_url":"https://api.github.com/repos/craftyjs/Crafty/issues/917/labels{/name}","comments_url":"https://api.github.com/repos/craftyjs/Crafty/issues/917/comments","events_url":"https://api.github.com/repos/craftyjs/Crafty/issues/917/events","html_url":"https://github.com/craftyjs/Crafty/issues/917","id":82250670,"number":917,"title":"Proposed API for the DiamondIso component","user":{"login":"airza","id":1684084,"avatar_url":"https://avatars.githubusercontent.com/u/1684084?v=3","gravatar_id":"","url":"https://api.github.com/users/airza","html_url":"https://github.com/airza","followers_url":"https://api.github.com/users/airza/followers","following_url":"https://api.github.com/users/airza/following{/other_user}","gists_url":"https://api.github.com/users/airza/gists{/gist_id}","starred_url":"https://api.github.com/users/airza/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/airza/subscriptions","organizations_url":"https://api.github.com/users/airza/orgs","repos_url":"https://api.github.com/users/airza/repos","events_url":"https://api.github.com/users/airza/events{/privacy}","received_events_url":"https://api.github.com/users/airza/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-05-29T04:14:53Z","updated_at":"2015-07-21T19:18:16Z","closed_at":null,"body":"I'm adding more functionality and would like to propose a public API for this to make sure I'm not missing anything or doing it inefficiently.  This will also help the docs, and make sure I'm writing the correct unit tests.\r\n\r\ninit: function (tw, th, mw, mh, x, y)\r\nCreates the grid.  Tile width and height are specified by the first two parameters.  The map's width and height are specified by the second two, with the X axis being down-right and Y axis being down-left.  The X and Y coordinate indicate the map's placement on the canvas, such that the top of the tile at (0,0,0) on the grid has its top corner here.  Right now\r\n\r\nplace: function(obj, x, y, layer)\r\nPuts an object (obj) into the grid at X Y and grid height layer.  If the object's height or width isn't a multiple of the grid height this probably won't work.  There's no need for a sprite or whatever to actually fill the entire grid, but its actual crafty size has to fit correctly in.  We should probably have a switch that will determine if the grid updates that object's realX/realY position as well. Destroying an object also removes it from this grid.\r\n\r\nIt's not clear to me from a design perspective if tiles should have their current grid location passed back to them by this function- is it a more maintainable architecture if all of the code that can tell objects about the relative location of other objects lives inside of the grid object itsself?  I really have no idea.\r\n\r\ndetachTile: function(obj)\r\nRemoves an object from the grid's storage and returns it to the user.\r\n\r\ncenterAt:(x, y)\r\nThis function currently centers the viewpoint on a given tile (Supposedly).  Since sometimes one probably wants units to be centered on a given tile this one makes sense to keep in (I don't think the centering is exactly perfect though, i should fix that.\r\n\r\ngetZAtLoc:(x,y,layer):\r\nUsed both internally and externally- the map sets up certain Z values so that tiles render correctly on top of one another. This may be possible to make private, but right now entities that walk on top of the map use it to get Z values for where they should be walking.\r\n\r\n\r\ngetOverlappingTiles: I don't remember why I wrote this method.  LOL.  It currently loops through the entire grid to figure out all of the entities which currently are under one another on the board,  which is probably useful if you have drag and drop functionality.  It seems like Crafty.findClosestEntityByComponent is a much better choice for anything you could use a grid for, so I'm going to remove this.\r\n\r\npolygon:  This looks like it's trying to do something with the bounding box of elements, but it's not correct and it's not clear why the grid should handle drawing the areamap of a tile.  I'm going to delete it.\r\n\r\ngetTile(x,y,z): Gets the tile at x,y, and layer Z.  Pretty straightforward.  Since we may want to turn this into a sparse representation internally someday this is going to be a getter.\r\n\r\ngetTileDimensions():  Returns the tile height and width  (Which right now have to be the same)\r\n\r\nfindPath(Start, End):\r\nThis i've already implemented - when given a start/end X and Y coordinate, it will look at things on the grid with the component \"Obstacle\" and find a way around it.  It would be nice to work with the collision library on this somehow, but collision on the grid and on a 2d screen work two fundamentally different ways.  This only currently works for things on Z level 1 that are walking around on top of Z level 0.  It returns a list of squares on the grid that the entity should walk through.\r\n\r\nTrivially easy upgrades for this would include:  A parameter to specify additional components that represent obstacles, and a parameter to allow diagonal movement.  (Right now the advantage of having the \"obstacle\" component is that the grid can store the collision map and then call it up when an entity walks around.)  Movement fails for squares on the grid with an obstacle at level 1 or that are empty at level 0.\r\n\r\nmoveEntity(startCoords/object, destination,speed):  Moves an entity on the map using the most efficient route available.  Always walks through the middle of each tile (it's not difficult to change this or allow a specified path.)  Currently it updates the entity's placement in the grid when it reaches the center of the square, but probably it should update as soon as the entity moves in.  It's also a method attached to its own component since i haven't gotten brave enough to try adding new components to the library.\r\n\r\npos2px(left,top,layer):  This returns the x/y coordinate of the tile at this location (IE, where the x and y of a tile would have to be placed in order to be correctly placed at this X Y Z.)  Layer isn't implemented yet, but is a simple addition of tile height to the Y coordinate.\r\n\r\npx2Pos(x,y): This returns which tile on layer zero the specified coordinates are on.  This could theoretically be updated to specify different layers, but right now I don't see a super obvious reason to do so.\r\n\r\n\r\nThe remaining functionality that i think needs to be added:\r\nrotate(Clockwise/Counterclockwise):  Rotates the grid left or right, in place, so that everything is in every other position.  Triggers \"GridRotate\" on every single entity in the grid, passing a translation function that correctly translates realX/realY/z coordinates.  (I think this is a simple linear transform, and hopefully not many entities on the grid need to bind to this.)  The X/Y coordinates of the grid probably shouldn't rotate unless there is a compelling reason for them to do so.  We COULD make every single function which interfaces between pixels and grid locations dynamically change based on rotation, but this would be a hellscape.\r\n\r\n\r\nThe current entities which I am developing/would like to develop in conjunction with this proposed functionality:\r\n\r\n\"Obstacle\": It counts as something you can't walk through (No code needed for this, it just helps performance for pathfinding if the grid collision map isn't dynamically updated for every single pathfinding call.)\r\n\r\n\"PathFollower\":  Currently has one function:\r\nfollowWaypoints(Array[Array] waypoints,speed):  It follows a list of realx/realy coordinates at the given speed using the tween component.  Calls \"Waypoint\" at each one and \"WaypointsDone\" at the end.  Needed for grid movement!  Also handy for objects that want to move in set paths on the map, though.\r\n\r\nDoes anyone have any questions or comments about this proposed API?  It will come with [drumroll] updated documentation for the diamondIso component, and should allow us to remove the regular iso (I'm not clear if anyone is using the other one and its component system is kind of unintuitive.)"},"comment":{"url":"https://api.github.com/repos/craftyjs/Crafty/issues/comments/123451212","html_url":"https://github.com/craftyjs/Crafty/issues/917#issuecomment-123451212","issue_url":"https://api.github.com/repos/craftyjs/Crafty/issues/917","id":123451212,"user":{"login":"airza","id":1684084,"avatar_url":"https://avatars.githubusercontent.com/u/1684084?v=3","gravatar_id":"","url":"https://api.github.com/users/airza","html_url":"https://github.com/airza","followers_url":"https://api.github.com/users/airza/followers","following_url":"https://api.github.com/users/airza/following{/other_user}","gists_url":"https://api.github.com/users/airza/gists{/gist_id}","starred_url":"https://api.github.com/users/airza/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/airza/subscriptions","organizations_url":"https://api.github.com/users/airza/orgs","repos_url":"https://api.github.com/users/airza/repos","events_url":"https://api.github.com/users/airza/events{/privacy}","received_events_url":"https://api.github.com/users/airza/received_events","type":"User","site_admin":false},"created_at":"2015-07-21T19:18:16Z","updated_at":"2015-07-21T19:18:16Z","body":"Yeah, it's the latter type - when you place or remove a tile from the grid on the 1 or 0 z layer it checks to see if 1)the tile on the 0 z layer is in place (IE, there's a floor) and 2) there's no tile with the \"Obstacle\" component on the z layer 1.\r\n\r\nI don't have any linkups in place with the existing collision map since I did things with the mouse - you click on the tile and then it uses the pathfinding at the grid level to see which boxes are non-crossible If I was trying to leverage the existing collision functionality for this, it seems like having a collision box projected onto the surface of the board for solid tiles would be the way to go.  Then entities walking could have a subcomponent where their feet were that invisibly checked collision."}}