(11-15-2024, 03:30 PM)Busy Miner Wrote: Bloody hell, just tried mining in Dublin again. That you could crack open these asteroids with Flaks and surgically remove the gold with Basic Battlecruiser turrets was the only redeeming quality of this type of mining. This has been removed now, or nerfed (looking at you, not-accurate, slow but formerly precise and quick Basic Battlecruiser turret), Sunwreath doesn't help much either. Can't you just add special mining weapons with area of effect? Or why not inventing some sort of mining beam, like in other sci fi games, that slowly but steadily sucks the ore out of these asteroids (would last as long as the asteroid mining now, but less tedious)? Scripting shouldn't be more complicated than the mining laser now, that magically puts ore into the hold.
Flaks were never intended to be used, and quite honestly actually are just flat not needed. Mining support ships using daisychains can do this easily, but really it isn't needed.
All you need are two tachyons, and you're set. Mining is still just as fast as it was, GF's miners do an average of 18min per cycle with the Hegemon. Quite honestly, you're just doing it wrong and you need to adapt. Saying that the mining system doesn't work is just not true, maybe it isn't for you but there are still legacy mining fields around.
We can't keep two fields up at the same location with two different economies going. A lot of people do like this, and gold has delivered quite literally millions of units of Gold to the server economy since its rework. You just need to learn it and give it a chance, and if it really doesn't ever work for you then fine - we still do old mining elsewhere.
But the new mining is enjoyed and it does work well. Don't make me do another video.
do you guys plan to expand this new mining system to other places? this looks like it is not very good. for miners with other kind of mining ships, like transports ... mainly a dunlin! asking for a friend
(11-12-2024, 08:32 PM)Redcroft Wrote: If you use win 7 it wont work..
Is there any chance of working around it for win7? at all?
Dont know.. I also use win 7 and update uses win 10 so.
But you can work around it,if you cant buy the ship that is on another page you ask a friend to buy it and transfer character.
Given that this answer received when specifically asked online, there should be some path to a work-around?
(The dx update completes without error, the stated files are present in the listed directory and whitelisted in anti-virus)
It's hard to imagine why 15 year old update wouldn't work with an OS that was current and supported at that time.
Is the bottom paragraph possibly pertinent to the processes being used here which need addressing?
(11-16-2024, 09:17 PM)Redline.Inc Wrote: Is there any chance of working around it for win7? at all?
The reason for the failure is that the FLUF.UI module that this depends upon is linking against windows api features that were introduced inside Windows 10 (specifically for calculating the DPI of the current Window for UI scaling). DirectX is a dependency that was added as a byproduct of the RML ui mode that is not currently being used by Discovery, but the libraries are required nonetheless in order for the library to run. While the DX9 runtime is required and does work on Windows 7, the aforementioned DPI method is not present so it does not matter. The only scenario where this would start working was if I was to split up the UI module into various sub-modules for the different UI modes. Suffice to say that is work I will not be doing to support an EOL operating system.
Explanation aside, you should not be using Windows 7 anymore unless you know what you are doing; it's a security risk to do so. While I cannot speak for the Discovery developers, no code I write will be aimed for compatibility with Windows 7, and wont be tested for it either. This means if the code I write is being leveraged, you're going to have these issues.
(11-16-2024, 09:17 PM)Redline.Inc Wrote: Is there any chance of working around it for win7? at all?
The reason for the failure is that the FLUF.UI module that this depends upon is linking against windows api features that were introduced inside Windows 10 (specifically for calculating the DPI of the current Window for UI scaling). DirectX is a dependency that was added as a byproduct of the RML ui mode that is not currently being used by Discovery, but the libraries are required nonetheless in order for the library to run. While the DX9 runtime is required and does work on Windows 7, the aforementioned DPI method is not present so it does not matter. The only scenario where this would start working was if I was to split up the UI module into various sub-modules for the different UI modes. Suffice to say that is work I will not be doing to support an EOL operating system.
Explanation aside, you should not be using Windows 7 anymore unless you know what you are doing; it's a security risk to do so. While I cannot speak for the Discovery developers, no code I write will be aimed for compatibility with Windows 7, and wont be tested for it either. This means if the code I write is being leveraged, you're going to have these issues.
So, which dx component specifically needs to be addressed?
However, if you are on Windows 7, the loaded module will not work will not work.. For the DLL to be loaded properly with out issues you need the aforementioned runtime, vcredist2022, and you must be running Windows 10, version 1607 or later
However, if you are on Windows 7, the loaded module will not work will not work.. For the DLL to be loaded properly with out issues you need the aforementioned runtime, vcredist2022, and you must be running Windows 10, version 1607 or later
Ah well, I've been meaning to build a new computer anyway.
Guess that I just need to stop stalling.
![[Image: RrJ0WDv.jpeg]](https://i.imgur.com/RrJ0WDv.jpeg)
![[Image: 4PBhcF8.jpg]](https://i.imgur.com/4PBhcF8.jpg)
![[Image: Lythrilux.gif]](https://sig.grumpybumpers.com/host/Lythrilux.gif)
