asherglick / burrito Goto Github PK

Textures are not currently cached or re-used, instead they are loaded off of disk each time they are used in a path or an icon. There should be a live texture cache that a texture is pulled from instead of being duplicated.

The cache should be cleared whenever a new marker file is loaded.

Burrito Link should be automatically run when Burrito is launched. This would cut down on an additional step. On Linux this would require some sort configuration file to indicate what wine environment variables should be set, and what the wine executable path should be. This config file will need to contain at least the same information that is included in the lutris run script.

as discussed in #25 the current implementation of burrito-fg fails to connect to the x server sometimes. This seems to be an issue with breadx.

The .so files seem to not be included in the built executable generated from the github workflow. If possible these files should be bundled into the executable, otherwise they should be included alongside the executable.

Is there currently a way to convert marker data from the TacO format to Burrito's JSON format on our side as the user?
i ask because i'd like to have markers based on the latest GW2 TacO ReActif Pack
if it's not currently feasible user side, it's okay and completely understandable.
i was just curious if there was anything i could do at the moment

using github is beyond most casual players. maybe have a burrito discord server or request a channel in the gw2 dev community server to help users/gather info for bugs in an accessible way. most people are likely to have discord because of existing communities like fast farming, hardstuck, most guilds (even smaller ones) have their own, wvw servers each have their own, most streamers have their own and such.

having a own discord server comes with the burden of moderating and other stuff. but gives the freedom of managing and making relevant channels easier.
while having a channel on gw2 dev community makes it much easier as there's no maintenance.

also wanted to mention that http://gw2.link/hub exists which has a central repository of pretty much all gw2 related discord servers.

Areas would be the third datatype on top of Icons and Routes. They are a similar type to Routes but function as enclosed spaces instead of just lines.

This idea was conserved early in the burrito design but thus far the only use cases are for Guacamole (#2) or for being able to have a color-fill in the minimap.

Burrito can read the interface size but does not have the ability to adjust its own scaling to match the game's UI scaling. The scale needs to be propagated to several components of the UI for everything to work, specifically the mini-map and the values used by the mini-map to occlude the 3D shaders.

We can use the public github API to check to see if there has been a newer release then the one currently being used. In order to do this some release metadata will need to be saved into the distribution itself, and a new piece of code that runs when burrito launches will need to query the github release API endpoint https://api.github.com/repos/AsherGlick/Burrito/releases to see if there are newer releases.

The API lists newest releases first and at the time of writing seems to return the newest 30 releases. I think something as simple as saving the release name on automatic build, and checking if that release name against the newest version will be sufficient. This check will not be performed on builds that do not have a release variable set so that local development does not run into issues where their local build is not equivalent to the newest version. Versioning will be as follows. An alpha- prefix will denote an earlier version then a beta- prefix or no prefix. A beta- prefix will denote an earlier version then no prefix. Finally no prefix will have a major and minor component.

EG:
alpha-1.2
alpha-1.3
alpha-1.4
beta-1.0
beta-1.1
beta-2.3
1.0
1.1
1.2

full details https://gitlab.com/coderedart/jokolay/-/issues/21#note_805580495
I am trying to finalize the details how jokolay handles marker packs. to make things as simple as possible so that i can implement merging marker packs or splitting them, able to edit and send only the "json patches" (apparently, there's json-diff rfc :D ) etc.. but ofcourse, a lot of it was work to make sure that xmlpack could be converted to and from jsonpack without any loss of details from the user perspective. to achieve that, i needed to smh make sure that i'm reading a pack, just like taco does (including the "quirks").
after some messy work, i was able to successfully use rust x cpp bindings to deserialize xml, deduplicate nodes and serialize again with rapid xml, which would allow us to skip A LOT of errors with syntax/formatting when we use rust xml crates.
at the moment, we still need to deal with attribute names which are misspelled like misNize instead of minSize, or weird values of attributes like alpha="3.0" etc. there's a bunch of work to do like writing tests, handling exceptions properly etc..

I have been trying to make it simpler so that i can be used by other crates too. just wanted to know if Burrito interested in this. either by extending the crate already used in Burrito by using bindings or just simply using jokolay's crate directly. as far as i know, the only function that Burrito needs is xml_to_json_pack where it supplies the .taco archive to the crate and it returns back the .zip with all xml files merged into one json.

if you choose to extend the existing crate, i will send in a pr after i make sure that it is polished enough. unless someone really wants to extend it themselves because ffi is fun :)
if you choose to use jokolay's marker format crate, I would appreciate it if you give me any criticisms after reading the offtopic stuff at the bottom before i finalize all the details of a json marker pack or tell me if you have any particular ideas. at first i was really anxious to ask this because well.. its hard to ask others for their time (especially when i am noob ) , but between the timelines where i try and where i don't try at all, i will want to live in the timeline where i tried.

OFFTOPIC

you can ignore this following as its not directly related to Burrito itself. this is just me asking for advice :)
as of right now, tekkit's pack which has ever 35k markers (stats from https://mp-repo.blishhud.com/ ) and 3-5k categories can be put into a json of around 6-8 MB in size.
Blish tries to split a xml marker pack into files named by the map id (eg: queensdale is 15.xml). so that i can only load the markers from that file when a player loads into a pack.
I had no intention of doing so because jokolay uses super high quality crates and fortunately, keeps the memory usage down reasonably, and by having full marker pack in ram it simplifies stuff like editing markers where i can be SURE that when i create a marker with an id, it is unique across the pack.
but other overlays might run into issues with such large packs, and it is true that when not editing a pack, just loading only the markers from the current map is better. jokolay can still load all markers from all map files even if the marker pack is split into multiple files, so this decision is purely based on what other overlays would desire.
Burrito, OTOH, splits marker pack into files based on category, which is not feasible when we are running into thousands of categories in a single pack.the jsonpack also only involves the markers/trails, the trail binaries themselves are stored as a mesh in their model space with first node set to origin, so they can be used by multiple trail tags by just specifying a position, and we can just transform/offset the mesh. these binaries are version 3. imagine if you made a trail that is a circle of radius 5 meters, and then you can just use it EVERYWHERE instead of re-recording trails OR even worse, duplicating them for every Trail Tag. this is partially motivated in hopes we can all eventually store these marker packs as gltf scenes, which i'm sure Burrito (which uses godot) as well as Electaco (which uses three.js) would really appreciate as both of them natively support gltf (and all the benefits like optimisation eg: compressed meshes, textures like ktx2/binomial, all the tooling whether offline or online etc..). well, it is still far, but a good dream.
and this might also eventually lead to this area tag #10 that has an open issue. version 4 trails will automatically connect the first and last nodes of a trail to create a polygon which can serve as area. can be used everywhere with the position offset specified in Trail tag of xml/json. ofcourse, all of these would need to be exported back to version 2 trails which taco uses when exporting it to an xml pack.

Burrito was deigned around 1080p screens and had that value hard coded into it. There is no technical reason why it should not be able to be scaled up to larger screen resolutions as discussed in part of #23.

There may need to be some work on adjusting the minimap shader location code if it is not something that is already computed correctly.

This can be implemented via a setting that can be changed manually. Or more complexly it can be obtained via the size of the guild wars 2 window.

Burrito keeps the panel with window list active, which obscures a part of the game. This is sadly enough of an issue for me for this to be unusable. I am not sure if anything can be done about it on Burrito's side.

Burrito

No Burrito

This issue tracks the implementation status of the Marker and Trail Attributes.

references to marker/trail attribute definitions.
https://blishhud.com/docs/markers/attributes/achievement
http://www.gw2taco.com/2016/01/how-to-create-your-own-marker-pack.html

First, we will focus on Markers

• (xpos: f32, ypos: f32, zpos: f32) - position of the marker in world space. required

• mapId: u32 - the map id in which the marker exists. required

• guid: Uuid - used as a unique id for this specific marker. to refer to/store in activation data etc.. required

• type: string - format "cat1.cat2.cat3" when we want the marker to inherit attributes from cat3 which is a child and inherits from cat2, which is a child of and inherits from cat1. attributes only get inherited if they don't exist already. categories are necessary so that we can only show markers from categories which are enabled in the menu. required.

• iconFile: path - image used as texture for this marker. only png files supported for now. optional.

• iconSize: f32 - default size/scale of the icon. atm, doesn't have units like meters or inches. default 1.0. optional

• alpha: f32 - how opaque you want the object to be by default. between 0.0 (fully transparent) to 1.0 (no transparency. default). optional.

• fadeNear: i32 - in inches (ingame unit). at this distance from player the marker starts to fade out. negative numbers means it never disappears. default is -1. optional.

• fadeFar: u32 - in inches (ingame unit). at this distance from player, the marker completely fades out. negative number means marker won't disappear at any distance. default is -1. optional.

• minSize: u32 - pixels. marker icon, if visible, must be atleast minSize pixels in size. optional.

• maxSize: u32 - pixels. marker icon, if visible can't be bigger than this. optional.

• color: string in format "#rrggbbaa". just use a online color picker and they will give you the hex codes of a color. color tint of marker. optional

• resetLength: u32 - for beheavior 4, this tells how long marker should not appear after F. for behavior 5, it represents how long the map cycle is. optional

• autoTrigger: bool - tells us if going near marker triggers it. quirk: the triggers need more explanation if its going within a range or pressing F etc..optional

• hasCountDown: bool - whether we should display countdown timer when we trigger it. optional

• triggerRange: f32 - distance at which the marker is triggered by the player. need to check if inches or meters. optional

• achievementId: u32 - id of achivement in gw2 api. needs apikey. hides the marker if achivement already done. optional

• achievementBit: u32 - bits representing partial completion of achivement in api. optional

• infoRange: f32 - distance at which info should be displayed. optional

• mapDisplaySize: u32 - size on minimap/map. optional

• mapVisibility: bool - marker should appear in main map.optional

• miniMapVisibility: bool - marker should appear in mini map. optional

behavior - integer. it describes the way the marker will behave when a player presses 'F' over it. The following values are valid for this parameter:
[ ] 0. the default value. Marker is always visible.
[ ] 1. 'Reappear on map change' - this is not implemented yet, it will be useful for markers that need to reappear if the player changes the map instance.
[ ] 2. 'Reappear on daily reset' - these markers disappear if the player presses 'F' over them, and reappear at the daily reset. These were used for the orphan markers during wintersday.
[ ] 3. 'Only visible before activation' - these markers disappear forever once the player pressed 'F' over them. Useful for collection style markers like golden lost badges, etc.
[ ] 4. 'Reappear after timer' - This behavior makes the marker reappear after a fix amount of time given in 'resetLength'.
[ ] 5. 'Reappear on map reset' - not implemented yet. This will make the marker reappear when the map cycles. In this case 'resetLength' will define the map cycle length in seconds, and 'resetOffset' will define when the first map cycle of the day begins after the daily reset, in seconds.
[ ] 6. 'Once per instance' - these markers disappear when triggered but reappear if you go into another instance of the map
[ ] 7. 'Once daily per character' - these markers disappear when triggered, but reappear with the daily reset, and can be triggered separately for every character

Trail attributes are mostly same.

• type: string - reference to the category just like marker. required
• guid: Uuid - a unique id. required
• trailData: path - file that contains actual trail data which represents the route. without this, trail has no meaning. required
• texture: path - similar to iconFile ofmarker. optional
• animSpeed: f32 - i have no idea what this is. optional
• trailScale: f32- width of the trail. need to find out what units to use for this. optional
• color: u32? - need to check. but similar to marker's color.
• fadeNear: i32 - similar to marker.
• fadeFar: i32 - similar to marker

We can update the status of attributes, and whether we want to explicitly ignore certain attributes or change how they behave (minSize/maxSize).

When a texture is first rendered in 3D it is forced to be sRGB. This causes issues when the same texture is being used for 2D and for 3D. We should have two instances of each texture loaded, one that can be in sRGB for 3D and one that can be in standard RBG for 2D.

Maybe there is a cleaner fix for this where both 2D and 3D can use the same texture but I am not aware of it.

This can probably be easily implemented alongside #18

A new code generator should be added. It should be able to take the documentation pages from the marker documentation. And write the files

• category.hpp
• category.cpp
• icon.hpp
• icon.cpp
• trail.hpp
• trail.cpp

For the generator should populate all variables into the class, later tasks will add the parsing logic itself.

Similar to #4 if burrito has control over the window we should indicate that a click or keyboard keypress that did not interact with the burrito UI itself was still consumed by burrito. It can be a bad experience if a player has a menu open but tries to click on the game but the game does not react. This notification should relay the concept "yes you did click, but it was not registered by the game".

Possibilities include: A toast menu, or "dps-eqsque" text appearing when you click, a small ripple element when you click, etc.

Similar to #13 but allowing for burrito to be auto-closed when guild wars is closed. This would make it nicer for users by not requiring them to click an extra button or two to close Burrito after exiting Guild Wars 2.

Currently there is a red border that appears when Burrito takes control over the entire screen. This functionally works but can be upgraded to be a more visually interesting, as well as be more indicative that the mouse and keyboard are being captured by burrito.

Guild Wars 2 has a specific special effect around the screen in certain situations, maybe mimicking something like that while making it visually distinct from the in-game effect is a good idea.

I have a rather complicated setup to allow me to run GW2 through steam using lutris so that I can use a controller to play the game. I have all the variables stored in a bash script, which is kind of required to use it all correctly, and my current work around is to simply duplicate this script and run it manually in order to get the game link working. I have the autolaunch plugged with the same environment variables, but it's not launching on its own.

I'm running the latest git.

export` SDL_VIDEO_FULLSCREEN_DISPLAY="off"
export STEAM_RUNTIME="/home/melechtna/.local/share/lutris/runtime/steam"
export LD_LIBRARY_PATH="/home/melechtna/.local/share/lutris/runners/wine/lutris-GE-Proton7-7-x86_64/lib:/home/melechtna/.local/share/lutris/runners/wine/lutris-GE-Proton7-7-x86_64/lib64:/usr/lib/libfakeroot:/usr/lib/libstrangle/lib32:/usr/lib/libstrangle/lib64:/usr/lib/openmpi:/usr/lib32:/usr/lib:/usr/lib64:/home/melechtna/.local/share/lutris/runtime/lib32:/home/melechtna/.local/share/lutris/runtime/steam/i386/lib/i386-linux-gnu:/home/melechtna/.local/share/lutris/runtime/steam/i386/lib:/home/melechtna/.local/share/lutris/runtime/steam/i386/usr/lib/i386-linux-gnu:/home/melechtna/.local/share/lutris/runtime/steam/i386/usr/lib:/home/melechtna/.local/share/lutris/runtime/lib64:/home/melechtna/.local/share/lutris/runtime/steam/amd64/lib/x86_64-linux-gnu:/home/melechtna/.local/share/lutris/runtime/steam/amd64/lib:/home/melechtna/.local/share/lutris/runtime/steam/amd64/usr/lib/x86_64-linux-gnu:/home/melechtna/.local/share/lutris/runtime/steam/amd64/usr/lib:$LD_LIBRARY_PATH"
export DXVK_HUD="0"
export DXVK_LOG_LEVEL="none"
export STAGING_SHARED_MEMORY="1"
export __GL_SHADER_DISK_CACHE_PATH="/home/melechtna/Games/guild-wars-2"
export WINEDEBUG="-all"
export WINEARCH="win64"
export WINE="/home/melechtna/.local/share/lutris/runners/wine/lutris-GE-Proton7-7-x86_64/bin/wine"
export GST_PLUGIN_SYSTEM_PATH_1_0="/home/melechtna/.local/share/lutris/runners/wine/lutris-GE-Proton7-7-x86_64/lib64/gstreamer-1.0/:/home/melechtna/.local/share/lutris/runners/wine/lutris-fshack-6.14-3-x86_64/lib/gstreamer-1.0/"
export WINEPREFIX="/home/melechtna/Games/guild-wars-2"
export WINEESYNC="1"
export WINEFSYNC="1"
export WINEDLLOVERRIDES="d3d10core,d3d11,d3d12,d3d9,dxgi=n;winemenubuilder.exe=d"
export WINE_LARGE_ADDRESS_AWARE="1"
export game_name="Guild Wars 2"
export PYTHONPATH="/usr/lib/lutris:/usr/bin:/usr/lib/python39.zip:/usr/lib/python3.9:/usr/lib/python3.9/lib-dynload:/home/melechtna/.local/lib/python3.9/site-packages:/usr/lib/python3.9/site-packages"

LUTRIS_WINE="/home/melechtna/.local/share/lutris/runners/wine/lutris-GE-Proton7-7-x86_64/bin/wine"
GAME_EXE="/home/melechtna/src/Burrito/output/burrito_link.exe"

"$LUTRIS_WINE" "$GAME_EXE"
exit 1

If a node is selected while the node editor window is closed, when the window is re-opened the options will not be greyed out and will be clickable. If one of those options is clicked before a node is selected it will cause a null pointer error when trying to lookup the currently selected node's attributes.

This should probably be fixed by making it so that any time the currently selected object is set to null the node editor window is also fully greyed out. Maybe that is how it currently is and we just missed a spot. If so then we should add code to grey out the window when it is hidden.

xml_converter/src/attribute/specialization_filter.hpp needs the EOD elite specs added to its list to be able to parse them properly.

A suggustion from reddit user /u/art_of_stars

A plugin system to allow other developers to further customize the functionality of Burrito without having to upstream the code. Currently there is no method of doing this but Godot's Pack Scene format is a good contender for an easy and extendable way to handle plugins.

A first placeholder to be something fun in the future.

A method of extracting all of the contributors from github and injecting them into a credits page in-app.

people will definitely have issues with Burrito. as we can see in #25 where dev had to ask for distro/wm versions, it wastes time of everyone involved to be waiting for the basic info.

i think it would help if we can have an issue template guiding what info they are supposed to provide to help with debugging or pinpointing the issue. the most basic info they can provide is Versions of their Distro/ Desktop Environment or Window Manager / Lutris and the runtime used for gw2 / Burrito and burrito_link.

and maybe the output/logs of burrito/burrito_link in terminal.

there seems to be a simple issue template from https://github.com/stevemao/github-issue-templates .
also, we can provide the commands they need to run which they can copy paste to get the relevant versions.

➜  ~ gnome-shell --version
GNOME Shell 40.3

➜  ~ cat /etc/os-release
NAME="EndeavourOS"
PRETTY_NAME="EndeavourOS"
ID=endeavouros
ID_LIKE=arch
BUILD_ID=2021.04.17

➜  ~ ./burrito.x86_64 --version
3.3.2.stable.official

Hello and thanks for this Linux friendly TaCo <3

Markers on main interface and fullscreen map are good, but seems offset minimap wrong, real path (red) is under the displayed path (yellow).

Why?

When using windowed fullscreen in Guild Wars 2, alt tabbing to the game makes burrito invisible.

I tried using wmctrl (you may replace :SELECT: with a substring match) instead of "keep above others":

wmctrl -r :SELECT: -b add,above

But the issue still persists (I don't know why). I also found another issue (#53) where the overlay also overlays over other windows. It's very annoying playing a game in window mode instead of windowed fullscreen.

I think this is the "most needed" feature other than easier setup of burrito links, etc, etc.

The way Discover Overlay works is how an actual overlay should work, not a window that is on top of another window.

I wanted to build the latest of this project from source, but was unable to find any build instructions. I tried following the instructions on the godot site, which uses the scons command to compile a project, but that is looking for a SConstruct file that is not present in the repository. How do you build the project?

Burrito files are currently stored in .json format. Most of the data in them is either structural data {}``[] or floating point numbers. These are traditionally poorly encoded in the JSON format.

Using protocol buffers is a good compromise between a strict custom packed binary file and JSON formatting.

Another option instead of protocol buffers is to use Godot's binary serialization. The upside to this over protocol buffers is that it is built into the godot codebase and additional protobuf code will not need to be created. A downside to this is that it is not schema based meaning that it would be harder to handle future proofing the file. Using the built-in serialize would also make it more difficult for other programs to interact with it. This may still be an option for a short-term solution.

It is unclear what the best design for implementing a menu where markers can be enabled or disabled. At the time of opening Burrito only opens files and displays their entire contents. However there are situations where you want multiple marker files to be displayed at the same time. Such as a combination of Tekkit Workshop's map completion markers combined with an overlay of the boundaries of all the Task Hearts.

If enabling / disabling subsets of markers is deemed to be not-the-best use case then it should also be decided if a file UI is the best interface or if a custom UI would be better.

In order to access the Mumble Link API a chunk of memory must be allocated. Burrito should do this automatically but does not currently. Early testing worked because Arcdps creates the shared memory file though so gw2 starts writing to it when that happens. But if you launch GW2 without arcdps then Burrito will crash because it is trying to read from an out of bounds memory address because nothing has been linked to it.

Guac will be an event-driven programing language used to control triggers in-game and representable in a taco marker file. It will probably be included as either a compiled AST and or a full text representation that gets compiled to an AST on load.

Maybe this is overkill, but it would allow the creation of more complex markers and guides such as Dungeon, Fractal, and Raid boss instructions.

Example Proposed Syntax

# The set of one or more triggers that would cause this action
triggers {
	player_enters_area()
	player_leaves_area()
	player_enters_radius()
	player_leaves_radius()
	timer_expires()
	timer_reaches_count(count)
	player_enters_combat()
	player_leaves_combat()
}

# The list of zero or more conditions that must all be true for this action to be executed
conditions {
	or (true(), false())
	not(false())
	and(true(), true())

	player_in_area("area_name")
	timer_has_not_reached("timer", count)
	timer_has_passed("timer", count)

	flag_value("flag_name", "value")

	true()
	false()
}

# A series of one or more actions to be executed in order if all the conditions are true
actions {
	set_ui_image("image_path")
	clear_ui_image()

	start_timer(length)
	pause_timer()
	clear_timer()

	show_area("area_name")
	hide_area("area_name")

	show_icon("icon_name")
	hide_icon("icon_name")

	show_path("path_name")
	hide_path("path_name")

	display_message("message") # Future

	set_flag("flag_name", "value")
}

This concept is inspired by the old Warcraft III trigger system but much more simplified and in text-form instead of a more complex GUI.

I'm simply making a note that it doesn't layer correctly with KDE, however, I'm 90% sure that, like with resolutions higher than 1080p, this can be overcome with wmctrl, I'll report back once I've worked out how to do it, it should also theoretically work with any DE, however I'm unsure if wmctrl works properly with wayland as of yet.

While I have not tested it yet on windows, something leads me to believe that this is not how the markers are supposed to look.

It creates an extra line from the center of the map to every zipline point.

I see that taco_to_burrito.py should be able to convert Teh's Trails successfully with some adjustments to the XML file. Can I get the adjusted XML file or a list of adjustments that I need to make to make it work? Currently, I am unable to convert it.

The Quick Edit Panel should have icons instead of the short-text bits it currently has. These icons can be simple but they should be as descriptive as possible.

I have a 21:9 monitor, and when i open burrito the outline of the overlay on my monitor only fills maybe 2/3 of the screen. is there a way to fix this myself? if not, I'd like to request support for bigger monitors

I'm running GW2 via Lutris, and using lutris-fshack-6.2.1-6-x86_64 as my runtime.

i've successfully made the .sh file and modified it to point to burrito_link, and it spits out the following when running so that part is fine:

/run_burrito_link.sh
hello world
successfully opened mumble link shared memory..
Client: The Winsock DLL status is Running.
Client: socket() is OK!
{"name":"Jyryn","profession":8,"spec":34,"race":2,"map_id":18,"world_id":268435458,"team_color_id":0,"commander":false,"map":18,"fov":0.873,"uisz":3}

however when i run burrito.x86_64 it shows the following:

/burrito.x86_64
Godot Engine v3.3.2.stable.official - https://godotengine.org
WARNING: initialize: XOpenIM failed
   At: platform/x11/os_x11.cpp:200.
WARNING: initialize: XCreateIC couldn't create xic
   At: platform/x11/os_x11.cpp:508.
OpenGL ES 3.0 Renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
OpenGL ES Batching: ON
 
accepted peer: 127.0.0.1:49656
New Map
Saving Old Map
Loading New Map

and while i can load markers, the overlay refuses to stay on top, however does show the proper markers if i alt-tab. i can even see it working in real time if i change zoom in game and quickly tab out.

so the issue it seems to me is it refuses to overlay the game. it'll overlay everything else, but not GW2. no idea why. Here is a screenshot showing what i mean, on this very page.

any help for a (somehwat) linux newby? quite confused on this.

Having to kill the process every time is kind of annoying

I do not have a windows machine to test Burrito on and we will have to rely on someone else to confirm this is working or not working.

There is a line in the Godot docs about mouse pass through that says that areas outside of the region specified for mouse pass-through do not get rendered on windows machines, but do get rendered on Linux and mac machines. If this is the case then the overlay will not render much at all.

Burrito Link should work out of the box.

Hey there!

Trying the new and promising Burrito!

I don't know if I'm doing something wrong here's what I did:

1. Follow the steps stated on the website
2. Run the script created for the Burrito link with the path: "
3. Run the awesome Burrito!
4. Load one of the .json files inside the converted markers (also tried the zip, and the .taco file from Tekkit)
5. Here's the max I could do, nothing appears and there goes what the terminal

Maybe I'm doing something wrong. I hope I can help in some way to provide more feedback in order to make it better!

Thank you for your efforts!

(I also include de burrito script)

https://gist.github.com/Nuxmin/b8e060acfdaa6c3cc31f759f7cee9c99

This can be used to generate a huge amount of gizmos with fun undefined behavior. A simple fix should be for the button to check to see if the gizmo editor window is open, and if it is open then more gizmos should not be created

I saw this video: https://www.reddit.com/r/Guildwars2/comments/ou7ebj/tekkits_workshop_markers_running_on_linux/, and I'm curious how you got that running.

The Burrito runs well (with the exception of windowed fullscreen, of course), but the markers failed to load. Loading the "converted_markers.zip" file gave this output:

Unicode error: no space left
Unicode error: invalid skip
ERROR: parse: Error parsing JSON at line 0: Expected 'true','false' or 'null', got 'PK'.
   At: core/bind/core_bind.cpp:3292.

The markers are downloaded from this site, by clicking the "Download Markers" button.

The video on Reddit, it seems to be working very well. Did you use the marker pack from the official website or from here? Which version of Burrito was that?

FYI, the "Burrito Link" works perfectly fine, it shows the output of the character name and more information.

This is a tracking list for all the tasks that are a part of adding proper XML parsing and category selection to Burrito for PR #56

• #65
• #66
• #68
• #69
• #70
• #67
• #71
• #72
• #73
• #74
• #75
• #76
• #77
• #78
• #151
• #80
• #81

Optionals

• [Marker Documentation] Allow Examples to be Defined in Marker Docs
• [Marker Documentation] Style Documentation Pages
• [Marker Documentation] Add More Complete Descriptions to Marker Docs
• [Marker Documentation] Compact "supported_by" Field When Rendering Web Documentation
• [Marker Documentation] CI Deployment of Web Docs to a Website
• #83
• #84
• #106
• #79
• #149
• #89
• #150

Reference Tasks

• #122
• #129

• Release Burrito "Beta"

After #39, dynamic resizing is setting the Burrito window size to 1x1.

Prior to #39, I could use wmctrl to resize the window to the appropriate resolution. However now this no longer works. A few seconds after launching Burrito, the window disappears. I can use wmctrl to resize it, but after a few seconds it's gone again.

After inspecting with xwininfo, the window size is being set to 1x1:

# xwininfo -name Burrito

xwininfo: Window id: 0x11e00003 "Burrito"

  Absolute upper-left X:  1440
  Absolute upper-left Y:  334
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1
  Height: 1
  Depth: 32
  Visual: 0x7e
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x11e00002 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1440+334  -3839+334  -3839-2225  +1440-2225
  -geometry 1x1+1440+334

Not sure what info is needed, but I'm running XFCE with 2 monitors, and GW2 on the right monitor (hence the +1440+334 offset in the above output).

Burrito cannot be closed from within the app currently. There should be a button inside the burrito menu that simply closes Burrito.

I attached a screenshot with #35 and was asked to create an issue regarding the black background in the screenshot. @AsherGlick pointed to a potential issue around the compositor. I found that "Allow applications to block compositing" must be unchecked in KDE. It would be good to note this in the getting started guide.

On Linux (Ubuntu 20.04) the overlay does not get rendered in the correct position on launch.
This has been observed on a 3-monitor setup where the overlay spawns on a different window entirely, and on a 2-monitor setup the overlay spawn on the correct monitor but offset by the top task bar.

This may be a difficult to solve issue but it is important to the overall "feel" of the program.

Currently this can be worked-around by pressing the Super key and click+dragging the window to the correct position. Once it is positioned correctly it will stay in place and function properly until its next launch.

Hey there!

I could make it work like you stated using ArcDPS, however, another issue I've seen. Even if the Burrito is checked as always on top and I have gw on windowed. Every time you focus on gw the Burrito stays in the background.

I find no way to make it stay on top so it's only possible to see the path alternating with Alt Tab.