search

DinnerBuffet / TTSCarcassonne

Script and data for the Tabletop Simulator mod
MIT License
45 stars 23 forks source link

[Feature] Highlight the dropzone of hovering meeple #6

Closed lilasquared closed 4 years ago

lilasquared commented 4 years ago

Great mod @DinnerBuffet. We were using a different one for a while where it just has bags of tiles and you do everything manually but this one really helps for players that don't know the game that well. One minor thing is that the red cubes indicating dropzones for roads, fields, castles, etc. are hard to hit precisely when you're not familiar with the mechanics of Tabletop Simulator. Is it possible to show the one that is currently hovered over or active as a different color as you are hovering? This would just give some visual indication that you are on the right space. A good example is the curved road pieces where one of the corners is a field and is very close to the road.

If not, that's okay too! Thanks for the awesome mod!

DinnerBuffet commented 4 years ago

Hey, that's a great idea! I think it would be possible, but it might require a bit of guesswork.

Bit of background, the position of the meeples are calculated to the closest fixed positions on the tile, which are where the cubes are spawned ie. https://github.com/DinnerBuffet/TTSCarcassonne/blob/master/tile_positions.jpg

For legacy reasons these positions are completely de-coupled from snap points. Also, the snap points were all created by hand, so there's additional room for error. Since I originally implemented it, I think TTS has added more functions for snap points that might make it possible to predict which snap point it will go to, and then find the closest position to that. If it's not, though, I might just have to pick the nearest cube, which could mean that the meeple may snap to the cube that isn't being highlighted. I worry that this could be an even worse experience and/or lead to loads of bug reports, but I might give it a try.

Side-note, I always intended to replace the cubes with a model that makes more sense, like a translucent meeple model, but never got around to it. Maybe I should do that...

lilasquared commented 4 years ago

Yeah definitely wouldn't want that. It is really more of a nice to have to improve the experience if you are bored at home with nothing to do HA. But seriously great work with this!

DinnerBuffet commented 4 years ago

Thanks! Unfortunately I have a job where I can work from home, so I'm not as bored as I'd like to be. It does sound like a fun idea to add, though.

I created an item in Trello to track it: https://trello.com/c/hiH43nPp/130-change-the-color-of-the-tile-position-markers-so-that-the-player-can-tell-which-is-being-hovered-over

If I can find a way to get the nearest snap point, there's a good chance I will take a stab at it, though not sure when.

lilasquared commented 4 years ago

Haha fair enough! I'd be interested in taking a look at it too but have no idea how to create my own "build"? of this and "deploy"? it to test on tabletop sim.

DinnerBuffet commented 4 years ago

I left some instructions in the Readme. They were a bit out of date but I just updated them.

The code is not pretty by any means, but the parts you'll want to look at are in hint_markers.ttslua. The entry points to the code are all in tts_events.ttslua

I did look into the documentation a bit and it is possible to get the exact location of each snap point.

The coordinates of these points are relative to the object, so you'd need to add the position of the object itself in order to get a global position. Might need to also take into account the scale of the object, but I'm not sure. In order to for sure know which snap point the object will go to, you'd need to check every object by looping getAllObjects() and you'd need to do this every frame via a coroutine since there is no event for when an object is moved.

You'd probably need to hack in some shortcuts in order to avoid killing people's CPUs. Maybe only check snap points on the tiles directly under and around the meeple (which can be retrieved from tileGrid[xIndex][zIndex].tileGUID) or maybe only taking into account 2 dimensions, ignoring the Y-dimension when calculating distance.

All kinds of fun implications to making this change :) Let me know if it's something you want to take a stab at. Otherwise, I think I'll get to it at some point.