Cookies Disclaimer

I agree Our site saves small pieces of text information (cookies) on your device in order to authenticate logins, deliver better content and provide statistical analysis. You can adjust your browser settings to prevent our site from using cookies, but doing so will prevent some aspects of the site from functioning properly.

All posts created by Azure_Zero

Azure_Zero
"You are a Troll" and a few others mentioned things about Hex security within this past week so I think it is time to really discuss the Pro and Cons of each player available security settings and WHAT the costs and consequences should be for each setting,
I also should note that all hexes should have their security set by the week like with the rest of the settlement's security and PVP settings to avoid being abused especially by the Monster and Holding Sec relationship system mentioned below in Consequences.

Now Looking First at the Pros and Cons of each security setting
High Sec:
Pro: No PVP outside of Fueds, No work needed for Player protection or watching for attacks.
Can Ring Monster hexes for Protected transport out of hex.

Cons: Can't stop a spy in your high sec turf.

Med Sec:
Pro: Can kill enemy spies, Rep Hits for non-fued PVP for PVP targets.

Con: Need to be watchful for hostile players, gatherers could need player protection.
Rep Hits for non-fued PVP for PVP Attackers.

Low Sec:
Pro: Can kill enemy spies, No Rep Hits for non-fued PVP attackers.

Con: Need to be extra watchful for hostile players, gatherers would more likely need player protection.
No Rep Hits for non-fued PVP for PVP targets.

If we look at it from a protection scale of 0 (no protect) to 1(no worries level of protection)
Low sec is 0.25f, Med is 0.5f and High is straight up 1.0f

In terms of work needed to protect your stuff using a scale of again 0(No work) to 1(You need to be active)
Low Sec is about 0.7f, Med Sec is 0.45f, High sec is 0.0f

Conclusion:
So from the Look of it High Sec is for players who Don't need to do ANY work to defend their Stuff and have everything easy.
While Low sec hexes see No benefit for being more PVP open and require more work in keeping it secure.



So Now let's get down to Costs and Consequences to balance them

A High Sec hex should require that the payment of the Holding be an extra 30% of the required bulk cost of the holding since there is No work needed in protecting players in the hex from the hex's owner.
But this extra cost comes with a perk, a few(2-3) small or medium guard camps (same rating as holding) in the hex to weaken the monsters in the hex itself for the gatherers and won't do anything for a fued.

A Low Sec hex requires a bit more work and a more watchful player in protecting that group's players in that hex, so they should have a bulk cost reduction of 20% for the holding.
This would make even the worst hexes somewhat better for getting resources when all the good hexes are gone, but have the increased risk of PVP for that hexes gathering resources for the area.
Now moving on the possible consequences for ringing a monster (and home) hexes with player holdings of the same or nearly the same security setting as Hinted near the top.
Note This system does a good job of balancing risk and reward for a very good reasonable part, and should use a value of metric of 0 to 1 or -1.0f to +1.0f for decision on what spawns in the hex.

If a monster or home hex is surrounded by Low Sec holdings chance of Teir 1 and lower escalations decrease by 25% with Higher T2 and higher escalations increasing by 25%.
While if a monster or home hex is surrounded by High Sec holdings chance of Teir 1 or lower escalations increase by 25% with Higher T2 and higher escalations decreasing by 25%.
Surrounding the hex with Medium holdings does near nothing on influencing the hex in either direction.

And this is a bit more logical in game, in that Higher sec guard will prioritise stopping stronger monsters from setting up shop in the monster/home hex, and in the process miss some of the weaker mobs setting up shop.
While the lower sec ones with no real guards would have stronger escalations setting up shop since no one is there to really stop them.

The Monster/Home hex will count it's Neighbouring hexes with Holdings and read their Security Value (i.e -1,0,+1), and then do an average to see what direction the holdings have influenced the hex's spawning system.

Now for Home hexes this would mean that Elite, Normal, and weakened versions of Home escalations would be needed.

Note this system could be used in a useful in other ways, in that if you want an easier time with the monster raids, just set all the holdings around it to High sec and you'll likely get weaker, easier to fight off escalations for the holdings during the PVP raid window.
While if you Like or Love fighting off hard escalations attacking your holdings, set the holdings around the monster or home hex to Low security.

Now this system could also be helpful for new player groups starting with their own settlement in that they can influence their nearby monster hexes for either; getting better loot and a challenge, or getting escalations they can handle and have fun with.
Azure_Zero
—-
Azure_Zero
If I recall T2 gear is SUPPOSE to be the PVP gear of choice since it is; cheap, easy to make, and still powerful.
Azure_Zero
Bob
Azure_Zero
Bob
DirectX vs. OpenGL is something we could experiment with further at some point. Sadly, there usually turn out to be various forgotten dependencies in large projects like ours that result in unforeseen complications, though it's usually possible to work around those eventually.

The only thing I could think of that would cause an issue is having HLSL shaders rather then GLSL shaders.
But given you have a Mac version PFO, I REALLY doubt Goblinworks will have any issues switching the rendering Core from Direct X to OpenGL.

Most likely such a change would go pretty smoothly, though we don't really even have the option right now with the current version of Unity we're on. For that version, all we can do is use a command line parameter to force the game to run in OpenGL, we can't really change how the base game is built until we upgrade at least a little. When we get to that point, we could try it out (assuming we can easily make the change throughout our build pipeline) and see if it results in any performance/compatibility issues for various subsets of players.

If you need a tester I don't mind being one.
I just need a FPS counter in the game to see performance and manually note problems for compatibility.
Azure_Zero
Believe Me I would of Liked it if Unity Offered a Vulkan rendering core option.
Vulkan would be offering speed, features and Multi-OS support, though given Apple's current isolationist ideas on APIs, Macs would be stuck with OpenGL 3.2 since Apple doesn't want Vulkan, but their Metal API to be used.
Azure_Zero
Bob
DirectX vs. OpenGL is something we could experiment with further at some point. Sadly, there usually turn out to be various forgotten dependencies in large projects like ours that result in unforeseen complications, though it's usually possible to work around those eventually.

The only thing I could think of that would cause an issue is having HLSL shaders rather then GLSL shaders.
But given you have a Mac version PFO, I Really doubt Goblinworks will have any issues switching the rendering Core from Direct X to OpenGL.
Azure_Zero
One part is an easy reason why groups would not want to take another settlement.
The Cost of Taking another settlement and then Maintaining it when you already have even a single +4 or better settlement would be enough of a pain and burden that groups would not want to put the effort in taking another.
In that would be even more taxing to the point that folks would likely rather leave your settlement or group then help with the need to take and maintain another settlement.
Even if you did take the other settlement and lessened the burden of maintenance as much as possible you'd likely keep it rather low which makes for much easier sieging then a mid or higher level settlement.
Azure_Zero
Bringslite
Edam
Bringslite
I don't see any real solid reason for it right now.

I thought the reason for it was obvious.

There are player groups in the game who have randomly kept grabbing more and more settlements. Vastly more than they need or can use. When new players eventually come into the game the only way they have a hope of getting a settlement is to grovel and beg to the groups with excess settlement in the hopes they can make a deal and get one for themselves.

Out of the thirty odd landrush settlements none are currently available to just take they are all tied up. Sure you can negotiate with someone and buy or otherwise acquire one but that is beside the point.

What the game actually needs is someway that unused settlements if they are not maintained turn back into NPC settlements (not just become available for some large group to grab) so that eventually they can be made available for new groups to compete for when the game picks up.
Well that's not exactly true. The Commonwealth has already given, freely and without restrictions/requirements, a settlement to a guild from outside this game. We did this because the real goal here is to have the game GROW by making it be less onerous to get started. We will probably do so again for groups that show honest interest in playing the game. Would be nice if more "Groups" with more than one "castle" might follow that example. Another reason, is of course, that The Commonwealth simply doesn't need as much land or control at this really down time in the game situation. We are working on reducing the burden's of support, hoping that the game will get less "chore-full" than it is now, for now.

Also remember that these multi settlement groups formed organically because others were doing the same thing and it is human nature to want to "win". Most around today basically started as One Settlement groups and created Alliances <- a natural result in any Territorial MMO I have ever seen.

Edit: But I do agree that more land should somehow be freed up before OE. If not simply so that new players coming in, feel like there is hope of having their own castle. Who said anything about limiting the ability to take over settlements anyway? Even if shut down they still have to be sieged…

I agree that the game actually needs is someway that unused settlements if they are not maintained turn back into NPC settlements (not just become available for some large group to grab) so that eventually they can be made available for new groups to compete for when the game picks up.

I would like it that IF a settlement has and or is shutdown for over 6 months ALL buildings (sans Keeps) start degrading -1 every month after the 6 months, so +5 becomes +4 etc. When a Building is +0 and time to degrade comes it goes puff and is gone. When all the Builds sans the Keep is gone, the Keep starts degrading every month, when it goes puff and is gone the settlement is Now NPC with all the companies being kick out.
This gives A LOT of time for the group owning the settlement and it's banner companies to get back in gear and keep the settlement though with some losses if they decided NOT to keep an eye on it.
This means a Complete +5 settlement has 17 Months before it becomes NPC, while any +0 settlements will have 8 to 9 months before becoming NPC.
The degrading effect would force the issue of Maintenance even for dead settlements and make the taking of them easier for new groups with No strings attached and never have the appearance (public or hidden) of strings attached when settlements are given away.
Furthermore this approach gives the new groups an idea of WHAT IS REALLY NEEDED in running a settlement, as I think being given a settlement tells the new group it'll be easy running one. But when they get to it, they find out it is harder then they thought and might leave.
Azure_Zero
I also don't mind the re-use of art assets so new classes come out quicker.
Also don't mind if some class features/feats are missing as well.
Azure_Zero
Some of those items would work great with the Settlement roles I mentioned in another thread.