asherglick / burrito Goto Github PK
View Code? Open in Web Editor NEWAn overlay tool for Guild Wars 2 that works on linux
License: GNU General Public License v2.0
An overlay tool for Guild Wars 2 that works on linux
License: GNU General Public License v2.0
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.
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.
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
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.
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
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.
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.
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
Optionals
Reference Tasks
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.
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.
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.
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.
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?
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.
A first placeholder to be something fun in the future.
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.
Having to kill the process every time is kind of annoying
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.
We can update the status of attributes, and whether we want to explicitly ignore certain attributes or change how they behave (minSize/maxSize).
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.
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
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.
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.
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.
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
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).
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.
A new code generator should be added. It should be able to take the documentation pages from the marker documentation. And write the files
For the generator should populate all variables into the class, later tasks will add the parsing logic itself.
xml_converter/src/attribute/specialization_filter.hpp
needs the EOD elite specs added to its list to be able to parse them properly.
Hey there!
Trying the new and promising Burrito!
I don't know if I'm doing something wrong here's what I did:
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
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.
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.
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.
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.
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.
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.
A method of extracting all of the contributors from github and injecting them into a credits page in-app.
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.
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.
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
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
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
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.
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.
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 cannot be closed from within the app currently. There should be a button inside the burrito menu that simply closes Burrito.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.