Closed sskyNS closed 1 year ago
You can overwrite the version of any overlay by using hex-by-string
. Something like this.
hex-by-string <ovl_file_path> <version_to_replace> <version_replacement>
If you have any more questions just lmk.
hide_overlay_versions
and hide_package_versions
are now true or false options within /config/ultrahand/config.ini
. 😊
here! I would like to ask again, how to remove the separators in Tesla's other plug-ins, such as emuiibo or fpslocker, the separators between their options are a bit annoying to me
That needs to be done within libTesla during compilation for those overlays. Overlays would need to be built with libTesla with those modifications. So it's kind of up to devs or the creator of libTesla unfortunately.
Random thought... perhaps this specific color can be hexed directly into the .ovl? 🤔 im not 100% on how to find the offsets for this one though. They are stored in pieces which can make it harder.
Ok! So if you hex search 77F7
and change it to 0000
it will change the separators into transparent. I'll need to play with this in ultrahand.
Just tested it within FPSLocker. works.
Great. I also did a recompile test yesterday, which took effect. Thank you for providing more methods and ultrahand.
so i think that if we use hex by custom offset on with hex 7F4300
as our offset, it may allow us to find the correct location for 77F7
every time. trying to think through how this can be scaled in both directions. may need to rewrite a couple things, ill keep playing with it.
Through the hexadecimal change, I don't sure whether it can be applied to other ovl. Most of the ones compiled and generated by devpro can be changed. I haven't tried to use the hexadecimal system to change the ovl written with other compilation tools, such as emuiibo, because its tesla (extra). hpp seems to be different(dust)
Needs testing, but im sure that it can be found and replaced. FPSLocker for instance appears to keep 77 F7 20 stored right after that particular offset. Same for Ultrahand. But i will need to look more into those other overlays. At the end of the day, unless they modified the color themselves within libTesla, we should be able to find and replace it.
edit: actuallly i think i had that wrong potentially with regards to my 7F4300 search.. but there could be specific offsets we can search for, ill dig through the hex a bit
so it appears you can find it with 77 F7 20 F2
adding 20 F2
to the end, which means we have more to search it by. still scanning for potential offsets, however it appears to be a fairly unique hex identifier.
yes so changing to 77 F7 20 F2
77 00 20 F2
will keep it unique, but make it fully transparent. ill test on more overlays, appears to work.
It seems much more convenient to compile ovl directly in hexadecimal than modifying tesla (listitem). Based on Nintendo's original UI design, there are boundaries between teams, and the modification has become simpler and more unified. Waiting for me to turn on the computer next time, I will try some ovl. In fact, I often use the hexadecimal system to complete some editing.
im testing ovlEdizon.ovl, its not finding 77F7, but it is finding F777. ill modify and see if its just flipping from big to little endian for some reason.
no perhaps the value used to be different in older versions of libTesla. that didnt appear to work. i may have to look at some of these other overlays and their libtesla forks. this is specifically what i'd need to check
If the change is based on Tesla, modifying the color frame should be able to complete the modification. But we need to modify each plug-in (in order to correspond to the functions you added before, I think we have hidden the line of ovlmenu, and we should also need to do other hiding, such as the one discussed now). If the hexadecimal modification cannot complete the unified modification of the old version, then it can Recompile it with the new version of tesla.hpp?It seems that there is no need to do this.
so some overlays by Tesla creator did not even use libTesla and have color representations in rgba8888 (probably projects that lead him to build libTesla). This can still be replaced, should be unique. If someone did something weird and didnt use libTesla for their overlay, it may have problems yeah. But this could be controlled from the main menu via hex edit under the new settings page Im implementing. Or someone could run a single command and replace all overlays with specific colors. Should be doable, but it does depend on how they built their project. Most overlays just use libTesla.
If it doesnt find the hex it will just not modify anything, so you could run dual hex commands simultaneously without worrying if your identifiers are unique enough.
Another thing I could implement is storing the offset caching, where it stores the offsets of the unmodified version and calls upon them when needed. That way it wouldnt matter as much if it cant find the same position as easily. But it just something else to consider.
https://github.com/XorTroll/emuiibo 只需尝试修改emuiibo,看看它是否可以修改其十六进制行透明度。如果你有时间,你可以帮我测试一下。我认为他添加了很多原始修改,所以我找不到它的颜色代码。但我还没有尝试过十六进制修改。你能帮我测试一下吗? maybe Approximate location: teslaextra.hpp
Im looking through it, yeah he for some reason did not just cite the color universally by reference. he made a habit of constantly redefining it in many locations (at least from inspection of the hex.). let me look into it more.
https://github.com/search?q=repo%3AXorTroll%2Femuiibo%20ColorFrame&type=code Actually this is where he calls on ColorFrame.
My suspicions right now are that ColorFrame was modified in his compilation. i didnt try building it myself though
Yes, I'm not sure how to modify it, even if I know where his source code is. It doesn't look like the regular RGB color change code. Have you tried the hexadecimal system? Can you find and change it?
I tried replacing 77F7 everywhere but it doesnt change it. he might have changed the transparency value or something on his tesla fork
If there is nothing you can do, then I think I can give up changing it. Even this may drive people with obsessive-compulsive disorder crazy.
if you are building it you can try replacing this value. im not sure if it will change the color, but its worth trying. https://github.com/search?q=repo%3AXorTroll%2Femuiibo++0xF222&type=code
That specific value is being used in the same way ColorFrame would be used, but it is a bit harder to search for right now. Building it shoudnt be a problem (if thats all that needs changing).
overall, there is a way to modify libTesla's default colors. But how people choose to draw their frames and colors can vary. we can still cover a vast majority of projects with hexing though. i'd say an improvement to libTesla to load colors externally would be a better approach overall (which would still require people to update their projects...), but it is possible to get it to look the same way for all of your overlays if you put enough time into it and perhaps build the projects that are causing you issues.
renderer->drawRect(tsl::cfg::FramebufferWidth - 1, 0, 1, tsl::cfg::FramebufferHeight, a(0xF222));
I have modified the rest of the ovl.and only this emuiibo is left. I will try what you said later and change this code to test it.
what you may have to do is check each renderer->drawRec
and perhaps change ColorFrame in libTesla if thats not the correct one. but its the color called when drawing the rectangle in certain places that creates the separator line you see
I briefly checked his source code, and it involves not many color modifications (in teslaextra.hpp) and testing should not be troublesome. If the change is correct.
have you been able to maybe try a simple modification of ColorFrame in libTesla when building? it might just fix the issues. I am seeing in some places he called a(tsl::style::color::ColorText));
instead of ColorFrame which should be a white horizontal/vertical line
Sorry, I may be disappointing you. My major is not programming. I may need to consult professional people, such as the original builder werwolv, but this code has been released for a long time. user references have added their own language, so he may not want to compare and modify it.
i can maybe try building it myself. i never use emumiibo personally. all you would have to do is change the color value and rebuild to test. but so far emumiibo appears to be the only one with this issue that ive seen
Indeed, my purpose is to maintain unity. Just like the questions I submitted here for the first time.
If possible, I hope you can help me or make a modified tesla for emuiibo, or other, respect
im installing rust and cargo to build the overlay, ill just test it out really quuick.
Here you go emuiibo.ovl.zip
All i needed to do was indeed modify ColorFrame
.
ths!It's my meal time now. I'll test it later and express my heartfelt thanks again.
You should learn how to compile overlays, it will help if there are updates in the future. Its not too hard to figure out, but it does take a little familiarizing. That way you can guarantee that every overlay is customized to your likings. It would be cool if libTesla was itself a universal binary that everyone can call upon, but it was made in a way that every project needs its own fork so modifications need to happen at the source then be implemented into every single project.
But hopefully all other overlays dont have this issue. havent tested hexing on everything yet.
If it's just a simple compilation, I will. But if I need to change some source code, such as this emuiibo and other very planned changes, I think I may still have to go a long way.
a(tsl::style::color::ColorText));
For example, this is just a piece of text without standard RGB (0XFFFF), etc. This is the main reason for my difficulty.
all that needed to change was
constexpr Color ColorFrame = { 0x7, 0x7, 0x7, 0xF }; ///< Outer boarder color
to
constexpr Color ColorFrame = { 0x0, 0x0, 0x0, 0x0 }; ///< Outer boarder color
really to make it transparent. the last 0x0 is the transparency/alpha value, so first 3 shouldn't matter if you want full transparency.
btw, i can add a mode for "clean version" where it will only filter out the X.X.X from the version label and display it in that format no matter what the label version is. i was thinking of adding it to make cleaner version labels something users can choose if they wanted.
I think this idea, while slight, is worth having. In addition, I basically understand the meaning of the color code. I already knew it before, and I used the same method to change the other plug-ins. Before you tell me that I can change fpslocker using hexadecimal, I compiled it with tesla and finished
emuiibo.zip I guess the version may be different. It seems that he does not implement Tesla calls through ovl.
Because when opening this ovl in Tesla, the display is blank, so I guess it may be a version problem or something else.
Or based on my inference, some code may have been modified in the ovl you sent to make all the fonts disappear.
i didnt use it in-depth, but its possible he used ColorFrame to define colors for other things other than the color frame. however on mine all the text is there. Im not using Tesla though.
I made a new config.ini option clean_version_labels
that can be set to true
if you want to have all the versions displayed in a uniform format. I'll add it to the next release. almost done with v1.3.9
我没有深入使用它,但他可能使用 ColorFrame 来定义颜色框以外的其他事物的颜色。但是在我的身上,所有的文字都在那里。不过我没有使用特斯拉。 Can you upload a screenshot so I can see it, does emuiibo display text on your machine? Is it his latest release?
I made a new config.ini option that can be set to if you want to have all the versions displayed in a uniform format. I'll add it to the next release. almost done with v1.3.9
clean_version_labels``true
How does the current configuration differ from his? It seems that their version numbers can be hidden in config
Hello, how can I delete the version number of other ovl plug-ins of Tesla/Ultrahand overlay?