• 0

    posted a message on calling function name
    Quote from lilsparky

    i was thinking of a different horrible way:

    scrubbing _G[] to generate a lookup table for all known functions (recursively descending into tables for methods) and then indexing them by their environment via getfenv and then using getfenv(1) inside my message handling function to look up into that function name table. if no name, then assume an anonymous function, i guess. altho, maybe it's not really that horrible. horrible sounding stuff is often really easy in lua.


    Afaik you won't get every function that way. Consider the following situation:
    function foo() 
        local bar = function()
             -- do evil stuff which calls lilsparky's function
        end
        return bar
    end

    I don't see any way to access this closure (but I might be missing something).

    But since you got a better solution, that won't be a real problem.

    debugstack is of course a much cleaner way than my suggestion.

    I would still like to remind you, that this information should only be used for debuggin purposes, i.e, you should not behave differently based on the name of the called function.
    Posted in: Lua Code Discussion
  • 0

    posted a message on calling function name
    Short answer: Yes.

    Long answer: It should be possible, but I know of only one way.
    A horrible way.

    You could cause an error inside a protected call. This should, if im not mistaken, give you an option to get the stacktrace. You could then parse this stacktrace.


    I doubt that is a good solution though.
    So probably I should ask: What would you need that for?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Map display addons and map data sources
    Well, I think I will just add them to the default map for now and probably rethink this later -- if needed.
    Thanks for all the input.
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Quote from Arrowmaster
    No wrong, you should always JUST FUCKING DRAW THE POINTS ON THE GOD DAMN WORLDMAP AND FORGET ABOUT THE FUCKING MAP DISPLAY ADDONS! The map display addons will show the points as long as you haven't fucked something up like attaching the points in a way that they get positioned below the display addon instead of ontop of it. This is what I ment by "everything just works".

    If the goal is to make it so other addons can find the points for things like TomTom/Routes then convince Ckknight and Cladhaire to finish LibWaypoint-1.0

    No, it is actually only about displaying.
    I don't want to disagree with you -- I really see your point.

    However, I don't know if you ever run Cartographer3 in standalone mode, but I will simply assume you have an idea what I mean.
    C3 currently is not usable in default (that is Worldmap Replacement) mode, nor is Carbonite (both are screwing up instance maps).
    For me this is a reason to not use them (more precise: not in worldmapreplace mode).
    I decided to use C3 seperated for the GoogleMaps kind display (which I would rather not miss).

    Now, lets see this from an display developers point of view, what would you suggest?
    I just guess: "If the display addon is right, thats not an issue!"
    Posted in: Addon Ideas
  • 0

    posted a message on Local Variable Optimization
    do
        for k,v in pairs(largeTable) do
            local var = someFunc(k,v)
            -- do something with var
        end
    end

    compared to
    do
        local var
        for k,v in pairs(largeTable) do
            var = someFunc(k,v)
            -- do something with var
        end
    end


    Okay, I think I did not get it right... are these two now equivalent (functional ofc, but also performance)?

    I think I read not, but I doubt this... If they are not, why exactly?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Local Variable Optimization
    The following example would probably be more helpful:

    for k,v in pairs(largeTable) do
        local var = someFunc(k,v)
        -- do something with var
    end

    compared to
    local var
    for k,v in pairs(largeTable) do
        var = someFunc(k,v)
        -- do something with var
    end


    I suppose the second example will be faster, but I am not sure. In a compiled language, these probably would not matter at all.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Map display addons and map data sources
    Actually, Cartographer3 does not seem to work with any map data source, of in standalone mode. This would not be an issue, if Cartographer3 would work as intended (not blaming anyone here, I know its in early stage).
    In order to use instance maps, I have to seperate Cartographer3 from the worldmap, which results in Cartographer3 not displaying any notes. (For example GatherMate is missing, as well as Rare Spawn Overlay and probably almost all others.

    So the idea is, to make map display addon authors life a little bit easier without every single datasource having to support each display.

    ---

    Now more in detail to the goals of the library:
    1) Allow addons to easily display nodes, edges and areas on any map display frame the user decides (WorldmapFrame, Cartographer3 Standalone, <insert your favorite google maps addon here>).
    2) If possible, allow interaction through the generated nodes/lines/areas (that would not be required on all displays, for example an addon which would display a transparent fullscreen map in the background would NOT want to be clickable). This could be a context menu for example.
    3) We do not need to intercept anything from datasources. Each node is explicitly displayed/removed/modified by the datasource. If we provide callbacks (i.e. context menu) we assume the data source to handle them.
    4) We provide support for popular display addons (one being the default Worldmap, possible more).
    5) We should allow new display addons to register themselves.

    So basically, one use case could be as follows:
    FancyGatherNoteSource calls
    library:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,text or OnTooltipShow, OnRightClick)
    
    with a lot optional parameters.
    The library would then dispatch this (drycoded, the api is probably wrong)
    function library:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
    	-- Default world map
    	displayOnDefaultWorldMap(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
    	
    	-- Extra for standalone stuff
    	if Cartographer3 and Cartographer3.isStandalone then
    		Cartographer3:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
    	end
    	
    	if Carbonite then
    		Carbonite:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
    	end
    end
    


    So the basic idea is, that the library will convert the parameters for the different displays api (assuming there is one). For the default world map we will implement the behaviour, for others we assume an public api which only needs small adaption.


    Now an actual usecase for my navigation addon:
    The user specifies a target (which is not supported by the library), and the addon calculates the shortest route from the users location to the destintation. Then my addon will ask the library to display this route.
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Maybe I was not precise enough:
    The library should provide a fallback for the default WorldMapFrame (if no display addon is available).
    In fact, the library should abstract enough, so that the data source addon can concentrate on what it is used for.

    However, you are right, it is unlikely to expect authors to convert existing addons without a good reason.

    I think I will propose an api draft soon.
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    I'm not sure what is unclear, though.
    The Addon does not need to know anything about other map nodes, it just needs an display to display the route (or the whole graph, or parts of it).
    (In future I'm planning support for including FlightMap data and such, but that is not the point of this thread.)

    I agree, we need lines for that. I suppose we need to define an api for that to. I haven't looked at routes or Carto/TomTom in detail, so I'm not sure how you did it.

    My current approach would be, to define a library which provides a consistent api to data sources. The library would then relay the information to map displays. However, I'm not sure which kind of things we actually do need.
    I certainly need notes/nodes and lines/edges. However, some addons might need more, something like areas (Rare Spawn, Questing stuff?) for example.

    Edit: Missed Adirelle's post.
    As you can see (I hope) above, I have redisigned the concept: Map displays don't need to change anything if they already have a public interface for the stuff.
    Data sources won't need to change anything either (but it makes sense, if they wan't more displays supported).
    New displays will be added to the library as the need approaches.
    So in fact, noone except me HAS to implement it. However (I hope) datasource addon authors will want to include it to simplify the developement.

    My path should be displayed, as a path. That is a sequence of points which are connected with lines.
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Actually not.
    What I'm doing is calculating the Shortest Path Problem.
    However, the calculation of that is trivial (I'm using A*).

    This thread is about displaying the results.
    Posted in: Addon Ideas
  • 0

    posted a message on SkillScore ?
    Though clearly not on topic to the original question, it is on topic to the last part:
    http://xkcd.com/325/
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Yes, I figured that out. I can't use TourGuide for solving the SPP. Ofc, I could create a Tour with the calculated route, and hand it to TourGuide which displays it using Cartographer/TomTom... Well... no.

    On the other hand, I could use (assuming Tekkub's permission ofc) TourGuide's code for that. Still not convinced.

    However, thanks for all your input, I think I will need to experiment a bit with the stuff.
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Actually, I'm not sure if either TourGuide or Routes do something I'm Interested in.
    Routes (which I use) solves the TSP, which is fine if you want to farm, but has absolutely nothing to do with solving the shortest path problem (which I'am interested in): Usually the shortest path does not contain all nodes.

    I'm not sure what TourGuide actually does, but I suppose I could use it. However, I am pretty sure that this would not be the intended use.

    Having to hard depend on an addon which actually has a different purpose does not feel right...
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Quote from Seerah
    Wait... Did I miss it? Or did you still not say what you're writing/trying to do?


    Adirelle and OrionShock already explained it, but I will try to explain it.

    I want a way (e.g. a library) to communicate (local, not with other players) map note information from data sources (GatherMate, ...) to map display addons (Cartographer[3], AlphaMap, ...).

    The reason, ofc, is that I am currently writing/planning a "navigation system" which would provide a sequence of notes (the route).

    While it is true, that most users have not more than one custom map addon, different users might have different. Same goes for data sources, as (Gatherer vs GatherMate: usually you have only one, still there are users for each).


    Now to some technicall aspects:
    Your (OrionShock) suggestion would store all notes in the lib.
    I'm not sure whether this is best. Let me propose somethin else:
    local db
    
    function lib:AddDataSource(addonName, type, iterator)
    	-- i have omitted the boring table creation
    	db[addonName][type] = iterator
    end
    
    -- Probably not needed
    function lib:RemoveDataSource(addonName, tpye)
    	db[addonName][type] = nil
    end
    
    -- Optional
    function lib:GetDataSource(addonName, tpye)
    	return db[addonName][type]
    end
    
    function lib:IterateDataSources()
    	return pairs(db)
    end
    
    -- Optional
    function lib:IterateDataSourcesFromAddon(addonName)
    	return pairs(db.addonName)
    end
    
    -- Optional
    function lib:IterateDataSourcesWithType(typeFilter)
    	return someFancyTypeFilteredIterator(db)
    end
    


    The basic difference is, that the lib does not need to store the data (the addons already do this) which would save memory.
    One disadvantage is, that it might happen that display addons modifiy the data (they should not... but you never know).

    What do you (all) think of this? Is the saved memory relevant enough?
    Posted in: Addon Ideas
  • 0

    posted a message on Map display addons and map data sources
    Thanks for all the replies!

    Some remark first. Im absolutely NOT talking about the Minimap at all, we have Astrolabe for that. I'm no talking about the world map specifically either.

    Quote from OrionShock
    better to have a lib that you can register your DB of points with that the display addons can then use via a common api.

    but don't use LDB proper, take the code and rename it so that the minimap points to traffic on LDB's turf :)


    I'm actually not quite sure what you mean. I'll just guess.
    I suppose you mean I should not put thousands of minimap nodes into the normal LDB storage, because that could slow other addons down.
    I completely agree.

    Quote from Adirelle
    A standalone library would be more useful. It should provides some query methods, e.g. IteratePoints(continent, zone) and the likes.

    Do you mean standalone versus embedded? Or standalone versus using LDB.
    I fail to see the advantage of disembedded, however I agree that using the exact LDB storage might be bad.

    Quote from yssaril
    don't we already have this lib in form of Astrolabe?

    Quote from OrionShock
    IIRC, astrolabe puts pins on the map and manages position there of. It didn't do DB management or storage.

    Let me clarify this: I do not want a library to store any data for me: I want a library which allows map addons to discover who has what data (ofc only data relevant to them, such as points on the map).
    Astrolabe does something entirely different: Astrolabe displays data on the Minimap (which is great). However, we might be able to fetch Astrolabes knowledge about these points but I fear Astrolabe was not meant for this.

    Quote from Arrowmaster
    Map addons don't need to 'support' anything. Everything just works fine if everybody follows basic best practices.

    I guess you have something in mind. However your message is not exactly precise. Let me guess.
    You suggest, that I could recieve relevant data from the known places (WorldMap, Minimap) where data addons have put them?
    (If you meant something else, please clarify)

    That actually sounds like a nice idea, however I doubt this would be trivial.

    Quote from Tekkub
    You were never exactly clear on what you're writing. If it's an addon that supplies map points, just sent them to TomTom and Carto and you're done. If you're writing your own TomTom, then you should probably write a little lib that abstracts sending a point for the data source, and then routes the waypoint to whatever mapping addon is present. Then a data source addon can include this little lib and stop worrying about finding a mapping addon to use.

    If you need an example, TourGuide provides waypoints, but don't do the mapping.

    I'm sorry. Let me clarify some things.
    First, TomTom has absolutely nothing to do with this, TomTom allows me to draw a fancy arrow to a given waypoint, but this is not what im talking about.
    (Although I will possibli use TomTom for exactly that.)
    Cartographer has two features: the arrow like TomTom and a map display.
    I do care about the map display, however I would rather NOT optdep ALL map display addons (there are not to many, but keeping only 3 different apis uptodate is bad, and there might be more to come).

    I agree however, that I should probably write a little lib that abstracts sending a point for the data source, and then routes the waypoint to whatever mapping addon is present. And thats what I'm talking about.


    Let me sum this up.

    I think we (or at least I) need a library (or a standalone, or a global table or similiar)
    However, there is no reason to reinvent the wheel, so I'm asking for suggestions, how to do this proper.

    I think we need something like
    lib.RegisterDataSource(name,type,iterator)
    for data sources (Gatherer & co, TourGuide, Rare, ...)
    and
    iteratorIterator = lib.IterateDataSources(typeFilter)
    for displays (Cartographer, AlphaMap, ...).
    type should be something like "node.herb.classic.peacebloom", "quest.turnin" or "rare.northrend.unkilled".
    typeFilter could be something like "" (for all) or "node.herb.northrend" for only northrend herbs.
    the iterator would basically return a table of relevant data (which should not be modified)
    Of course, we could then write a little addon which would add these to the classic world map.

    Comments?
    Posted in: Addon Ideas
  • To post a comment, please or register a new account.