• 4 Posts
  • 76 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2023

help-circle



  • Get a construct head, maybe at least 4x beam emitters and then finally batteries. You can also optionally attach the construct head on top of stake to keep your platform away from Lynel.

    So basically, you first spawn the construct head (the direction where it hit enemy is where the eyes are), stack some beam emitters, all facing toward enemy (unicorn to enemy) and stack the batteries behind the beam emitters and that’s it. A simple cheesing turret, and you can optionally put it on atop of Stake so that it’ll stay upright and can be positioned anywhere. Once you built it once, just make that a favorite in your autobuild and test it.

    When you’re ready, the strategy is simple, you find a lynel, just stun it by shooting arrow in the head, use this stun time to spawn the turret and start it up and watch Lynel melt. :)

    Make sure it’s a bit further away from Lynel and try to lead it a bit away from the turret so it doesn’t use the whirlwind roar to delete your turret.



  • When Blood Moon approaches, I get to the campfire with cooking pot and cook up some boosting meals, they get bonus about 15 minutes before and after blood moon (11:45 to 12:15.)

    After a blood moon, I immediately head to the Floating Coliseum to get 2 Silver Lynel Sabers and replenish on some useful weapons like spike ball fused swords (anti-armor weapon, perfect for fury rush) and lynel 3x bows and 3x Lynel Guts. After the floating coliseum, I head to the west above the Gerudo Desert in the snowy mountain to find another Silver Lynel and kill it there and then the last silver lynel at the bottom of Hyrule castle. That sum up my to-do list every time Blood Moon rolls around until I have 10+ Lynel Sabers and weapons. I also sometime replenish the base-weapons by heading into the Hyrule Castle Sanctum where bow, royal great sword, regular royal sword, and spear could be found there. (Zelda room have another royal bow and royal great sword.)

    Once you have established some pretty good arsenals, you should mark the map of every single Rock Octos spawn in Death Mountain and use it for replenishing the durability of your fused weapons.


  • That basically why I stock up on damage boosting meals and carry some Lynel Saber weapons that net you like 70+ damage after a fuse and potentially 120+ if you have a fusion boosting weapon. You can endlessly repair those sort of weapons by heading to death mountain to find a few rock octos. Combined with Tarry Town for breaking Lynel Saber off your broken weapon, once you have 10+ Silver Lynel Sabers, you are pretty much golden and you can reuse it however many times you want.

    I always find myself using heavier weapon so I can just spin attack on silver enemy, they die fast after taking a few round.

    I also have a laser turret to cheese the army of silver enemies if I needed to though those can be expensive, like 100+ zionites depending on batteries.


  • You pretty much nail it, there were an unconfirmed report of Wagner approaching a warehouse that holds tactical nukes (I really hope that remains a simple speculation.) If Wagner claimed the tactical nukes, that would’ve very nearly guaranteed a successful coup, because they could simply waltz right into Moscow and hold tactical nukes to keep the rest of Russian army at bay and other factions in Russia would realize the same thing, “Oh wait, so if they can do it… then…”

    Cue the Western Governments poker face at the enactment of the movie, The Dark Knight Rises, where terrorists/fascists gain access to nukes and Russia balkanize by competing warlords holding at each others throat with tactical nukes.








  • You probably got your answer from system administrator perspectives, but I’ll put mine in as a developer perspective who also developed some niche admin tools like SELinux Editor.

    TL;DR: It require reinventing GUI on Linux and no, I’m not joking. I’m working on it as it is leveraging Vulkan by default.

    @[email protected] did a good job laying out on some of the issues that arise from GUI Toolkit that we currently have on GTK and QT which are the two mainstay GUI on Linux. One of the problem is the lack of automatability in GUI, but it can be solved by establishing an Interprocess Communication Protocol. With an agreed upon convention, you can subscribe events or issue commands such as clicking on button or whatnot and that allows for each GUI Toolkit to also interacts with one another as well. Think of Wayland, but for between GUI.

    Some challenges are impossible in CLI, but possible in GUI, and those can be SELinux, Firewall, or other administrative tasks that require as many widgets, visualizer, debugger, or whatever available to aid you. So I think people here need to realize that there are significant merit to GUI workflow for administrative tasks.

    So with the current GUI Toolkits that are available on Linux, most developers aren’t very inclined to use limited features offered by GTK and a difficult to use C++ GUI and so, some of them consider developing web application, but it comes with it’s own baggage too. This is kind of a no-win situation for those who are looking to make a GUI for Linux. This is one of my pet-peeves with Linux and why I am working on it.

    If you are interested to learn more on GUI Toolkit situation which I am working on at this time.

    On Linux, I’ll summarize the issues for GUI Toolkits:

    1. GTK Toolkit is written in C language with GObject that emulates Object Oriented Programming, but it is far from intuitive for average developers and the documentation can be incomplete. For most of you, it can be seen as something like a huge bloat.
    2. QT Toolkit is written in C++ language and have limited binding options for Python, it have other option like QML for GUI, but it’s limited in flexibility. This limits a lot of choices for your average developer, because most of them don’t want to touch C++ with a 10 foot pole. I certainly don’t want to either.

    Why do I want to make my own GUI Toolkit?

    1. Foreign Function Interface as a first class - Whatever programming language you want, PHP, Bash, Brainfk, whatever, it should be able to interacts with my GUI Toolkit, period. Binding for your language can be done by reading FFI-JSON and generating the binding. FFI-Json is just a JSON file that describe all of the interfaces and datatypes in GUI Toolkit library for your programming language to bind to.
    2. More memory efficiency - Uses 1/3 as much RAM as QT and 1/6 as much on GTK, utilizes Vulkan Graphic API and you can switch to CPU mode if you want to avoid using GPU. (Swiftshader for those wondering.)
    3. Everything is designed for 64 bits sized data, like if you want to open a 100 GB text file on a random text editor in my GUI, no problem, the text editor is designed to be buffer-based.
    4. Actual documentation with examples. This should be pretty obvious, but I am still surprised to this day that most GUI Toolkit documentation are rather poor even with corporate funding.
    5. Solve the chicken and the egg problem when attempting to fork off X11 (This is something I am seriously considering.)
    6. Written in C with Object Oriented Programming Paradigm (Similar to GTK, but without GObject)
    7. Familiarity - The API is inspired from System.Windows.Forms coming from C#, if you know what it is, then this GUI Toolkit would be second nature to you. That the idea I’m going for. API similar to WPF would come after that.

    Before you suggest that I should fork off GTK, that would means I would have to comply with GTK’s licensing, which is GPL 2 and my project will be licensed differently. Also the whole project is redesigned from ground up, so it wouldn’t make sense for me to overhaul GTK which would be twice the work I have to do.