Quote:
|
Originally Posted by magill
What is needed is the classic "Lewis and Clark" method....  (compass and pacing)
I doubt that "height" is a meaningful measure -- just because visually there looks like a pass there, doesn't mean that it isn't simply a "pretty backdrop painting. --- at any rate... |
The trouble is, if you're going to do any routing whatsoever - such as finding a path between an arbitrary point A, and a quest objective, you need to know what is, and what isn't passable terrain. If it was going to be something like the path between two predetermined locations, that could be as easy (but time consuming) as just walking the path yourself, and use that. However, in this case - the path can't be predetermined, and certainly drawing a linear path between the two points would help as much as it wouldn't. Now, ordinarily - if we were talking about a game, there would be an invisible grid with passable and unpassable nodes where the lines would intersect. In this case, finding the path would be a logical "connect the dots" game, connecting passable nodes from start to finish points. This is most likely what LotRO uses for their AI pathing, as does Valve's Source games. This same technique could probably be used for this case, as long as the grid was detailed enough to work through the narrowest of paths. However, before that can be done, such a grid would need height/obstacle information in order to classify the nodes.
Quote:
|
Originally Posted by magill
I just stumbled across your WP blog (chasing OSX and LOTRO "stuff") and noticed a comment about /loc in "Of Coordinates and the LotRO Client"
I believe that the comment "For each complete cycle, lx and ly will increase by 8 points. So essentially, every 20 points ox or oy increase or decrease, lx or ly will increase or decrease by 1. Even understanding that, it’s not very handy to attempt to use a 2-part x and y coordinate, so for actual placement purposes, it’s beneficial to convert these into a single x/y coordinate set. Now, there’s really no “official” method of doing this – or at least, no way of telling what that method is. " relates to Land Blocks. (That is what they are called in LOTRO.) Which is to say, somewhere in a discussion of "Distance Imposters" I encountered the explanation of how Turbine only reveals what's in the next or next two (I forget) land blocks, hence the "pop-up" effect seen with distance imposters. That said, I believe the reference in /loc is to "tiles". Put another way, "/loc" is so that the Devs can pinpoint the specific tile which has the "bug" in it. --- I don't really know anything more than this as I've never really bothered to investigate the issue... and to see where it is all explained.
... so I just went and looked through the Forums a bit and found this description...
|
After I posted that, it did occur to me that these land blocks, and the map tiles corresponded to each other - and that when I looked at this previously, I seem to remember making that connection (back around, before the plugin concept). At any rate, the fact that I'm not using the Google Maps API is even handier in this regard, because I can use 200px tiles instead of the 256px tiles Google Maps uses. So even in a zone based map, I can maintain the original tile layout - making a lot of things a lot easier on the coding end.
Quote:
|
Originally Posted by magill
BTW, I've been playing LOTRO (and DDO before that) on the Mac using Codeweaves CrossOver Games (CXG) [which is basically the folks who provide the home (computers, storage, staff support, etc.) for WINE] since the pre-betas of both. (I'm a lifetime/founder). I also happen to be a retired Unix SysAdmin, so I have never had an issue using the Unix underpinnings of OSX to link various things around, independent of the Mac GUI. It's pretty trivial to generate a symbolic link between the Bootcamp and OSX partitions so that the same LOTRO files can be accessed by both.
|
I agree, a symbolic link really would be the best case to use in that situation. Although my experience with Unix, and Unix based operating systems is still pretty minimal, Google is my best friend
. In the case of the guide, I wanted to make things as user friendly as possible - as if Mac users are anything like Windows users, the UI is pretty much all they know.
That being said, I think someone should try a different approach with LotRO and WINE/Wineskin. Currently it's being run in a single bottle, when there's really two to three separate apps here. However, my knowledge is a little sketchy on exactly how they all work together. I know that the launcher launches the client via command line parameters that includes a hash that seems to be seeded by the time/date - as it changes each sign on. I'm also fairly certain that for patching, the launcher makes library calls to datexport.dll; but as far as how that hash is generated, or the purpose of TurbineInvoker.exe, I'm not sure. I'm also not sure exactly how pyLotRO works, nor how closely it works with the Windows API. However, what I'd like to see is a version of the Launcher as a native OS X app, while keeping the client itself in a wrapper/bottle. This way it would escape that issue that WINE alternatives have with games that have a launcher.
Anyway, that's a bit off topic here, but it did bear mentioning regardless