![](https://forum.skylords.eu/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
Omega1001
Member-
Posts
8 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
Omega1001's Achievements
![Rank: Watcher (1/34) Watcher](https://forum.skylords.eu/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_rank.png)
Watcher (1/34)
4
Reputation
-
Mynoduesp liked a post in a topic: Rework some irritating things "Behind Enemy Lines"
-
Eirias liked a post in a topic: Rework some irritating things "Behind Enemy Lines"
-
There a two major things that always grinds me up on "Behind Enemy Lines" First: If i try to destroy the spawn-building in the northern Camp (The Center one) with Nomads, one of 3 always wanders behind the building. While this isn't directly a Problem, it attracts the Twilight-Dragon from the Top-Left camp, which completely wipes me, which is uncool. Could you please prevent that from happening? Maybe let him spawn a little more to the left, or make that Montan Range in between unable to fly over pls? Second: The Wall in the top left Camp (the one with the Dragon) is crud! Why does it span all the way around? (BTW, i realize, that it was EA who placed it like this, so not blaming you or anything here) Could you make it smaller, so it just protects the entry? Or maybe add an effect that wrack the whole thing, if the energy well gets taken by the player? Thanks
-
Omega1001 liked a post in a topic: Remove requirement for Administration Rights on Launcher
-
Xamos liked a post in a topic: Introduce "Formation" to reduce micromanagement while moving units with different speed types
-
@Kubik Ok, honest mistake here. I thought I had read somewhere that the client was in C# and I thought you had at least some control over the Code be it from EA or thru reverse engineering... In that case, I agree with you, that this change cannot be implemented, as the Borderless Flag has to be set when registering the window and can not be set afterwards. Thanks for clearing that up.
-
Omega1001 liked a post in a topic: Add Fullscreen/Window Mode
-
Hi, trying to poke this topic with a more technical view: Thing like Window Mode / Fullscreen and Borderless Fullscreen are not being implemented by the dev Team (eg. SR) but by the window management system, which in this case is Windows. As dev, you just Tell the window Manager how your Window should be displayed. A quick google on the subject revealed, that in C# this can be don by setting two Fields on a Object that are also modified when using normal Fullscreen. See StackOverflow Reference here Thus implementing this should be rather simple ... I'm personally looking very much forward to this Feature as I use multiple Screens. So normal Fullscreen is just a pain.
-
Omega1001 liked a post in a topic: Remove requirement for Administration Rights on Launcher
-
Remove requirement for Administration Rights on Launcher
Omega1001 replied to Omega1001's topic in Implemented
If it's really just "Need Read/Write access to files inside Gamedir", then it would suffice to do the C# equivalent of Unix Shell command "chmod -R u+rw <path/to/gamedir>" once. The updater could do that after every update, so the User doesn't need to do anything. People that installed the game in a non System dir, like on a different drive, don't even need to do anything. At least, Admin Rights schuld not be a hard dependency like now, so that people can switch it off if they don't need it or switch it on if it is actually necessary. That is part of the Problem: Because the launcher has admin rights, that unknown Server can copy and or download whatever it wants from anywhere in the System. Without admin right, it can only do damage to files of the User, but the System stays off limits. SR staff can only vouch for there code, and as we are all humans that make errors, not even that is completely foolproof, no matter how skilled the staff is. They know little to nothing about the underlaying libraries, that could be vulnerable just as much. C# core libraries itself are not safe, because statistically they couldn't possibly be (because nobody is perfect). Nobody can guaranty security, be we can make sure, that it's not that easy to use these weakpoints. -
Remove requirement for Administration Rights on Launcher
Omega1001 replied to Omega1001's topic in Implemented
Shure, that way I can enshure that there are no bad stuff in there NOW, but you'd basically would have to do that every time an update comes in anew, As I'm a Tech, i know for a fact, that there a no restrictions to read/Write FIles on Types. Actually, the extension is only an indicator what this may be, but you don't actually know. For instance a .jar file is actually a .zip file with different extension so the OP treats it different, but the content reamains the same. Admin Rights may be required to Write (probably not Read) Files if these are stored somewhere in a System dir (like C:/Progam Files) But you can fix that by using admin rights once to set these Access Right properly, and never need them again. There are countless Programs for Windows out there that do similar things as the launcher, and they only need admin right at setup, or request them if they make an Update. If they can do it, why shoudn't Skylords too? That is putting it a little to simple. You don't just trust the Skylords Team to not put bad stuff in there, you must also trust that there are no weakpoints that an Attacker could attach to without altering the code. Processes that run under admin rights are always a Risk even if they come from Microsoft themselves. The preferred way to deal with that is to run as few Processes as possible under admin rights. In the end, it remains a massive Security Issue that is indeed avoidable. And it should be too. -
Since the revival, the launcher requires admin rights in order to run. This is a major security issue, as it opens the way for malware into the system, along with other issues. As I'm sure that this decision was made to ease Development in the beginning, it is probably high time to remove that requirement.
-
As a basic Idea, you could use a existing Slow effect that is applied on move and cleared on arrival, new command or combat. The Game already has those, so applying and clearing it at certain point shouldn't be to big a change. Regardless, a full Server Side Implementation would offer more comfort if that was possible ... Of course, I don't know nothing about your codebase, so this is pure speculation.
-
Metagross31 liked a post in a topic: Introduce "Formation" to reduce micromanagement while moving units with different speed types
-
Motivation: When moving units with different speed types, for example Nomad and Thugs, keeping them together can be painfull. It usually requires a lot of micromanagement to prevent the Nomads from running ahead, and nearly dying once they encounter enemies before the thugs even arrive. Proposed Solution: Introduce a new Toggle Switch "Keep Formation" to Combat UI. When Switch is switched on, all Units receiving a move command will move in "closed formation". When in closed Formation, units will walk with reduced movement speed equal to the movement speed of the slows unit within the Squad, effectively making everyone move at the same pace. This behavior breaks, if: - Units reach the goal of the movement - Units receive a new movement Command without Keep Formation - Units receive a Attack Command - Units engage in Combat (e.g. because of Attack on sight) Optional Extension When Units are moved in closed Formation and not all Units are in place, slow all Units that are already in place to allow the rest to catch up. Also, if a Unit is not jet in place, don't apply slow effect to allow it to catch up faster.