POB Change Suggestions

[Champ]

Player Operated Base Change Suggestion Thread

How about that! Another POB thread. From me, of all people. This time, it's going to be a certain way, though, because I want a catalogue of propositions that is legible, clear, and rational. We're going to use templates to outline succinct change suggestions, and similar templates to provide reasoned critique of others' suggestions. +1s are not necessary because we are dealing with the logic, not the popularity, of ideas (here). Read other posts first and do not post a suggestion that has already been made and isn't unique. Try to steer clear of exact numbers, because those can and will be argued later - give approximate ranges for numerical values instead. Here's the same thing and more in a list.

• Read the thread before posting suggestions, at least the title, specifics and example sections
  
• Read the entirety of a suggestion and any existing critiques of it before posting critiques
  
• No +1s
  
• No duplicates
  
• Avoid exact numbers in suggestions
  
• Critique concepts, not specific numbers (unless they're negatives where they should be positives)
  
• Do not critique obvious typos
  
• You may put multiple suggestions in the same post, but maybe not more than like, four?
  
• Separate changes into individual suggestions rather than bundling them, unless it's the same concept
  
• Link, don't quote
  
• Stick to the templates

The premise is that these suggestions will be considered, eliminated and adjusted, and the specifics will be negotiated and decided thereafter. The goal is to improve the player operated base plugin. See the second post for examples of use and genuine ideas I had. If you know someone else had an idea and support them, encourage them to post here rather than trying to paraphrase their thoughts. Don't want any changes? I've included a poll above to help you contextualise this thread, but the poll is a poll, not a vote.

Simplicity, brevity and clarity are key.

Templates

Suggestion Template

Code:

[hrc]#FFFFFF[/hrc][size=14][color=#FFFFFF]Suggestion[/color][/size]
[color=#FFFFFF]Type:[/color] Use one or more of the following phrases to identify which are the domains of the specific change you're proposing: Rules / POB Plugin / Economy / Other
[color=#FFFFFF]Title:[/color] Here, in less than a sentence, what would change?

[color=#FFFFFF]Specifics[/color][list]
[*]In dot points no longer than a sentence, what must be done to make the change?
[/list]
[color=#FFFFFF]Potential Problems[/color][list]
[*]What are the potential flaws or exploits or shortcomings of this suggestion that you can identify, but not resolve?
[/list]
[color=#FFFFFF]Example of Effect[/color]
Provide one or two brief examples of how the change would affect gameplay.

[color=#FFFFFF]Further Discussion[/color]
Why this change? Here you may include further rambling, or links to other places where you have already completed that rambling. Don't forget that the more you write, the less likely people are to read it. If you make a real wall of text, consider throwing it in [spoiler] tags so the thread is still easy to navigate.

Critique Template

Code:

[hrc]#FFFFFF[/hrc][size=14][color=#FFFFFF]Critique[/color][/size]
[color=#FFFFFF]Suggestion Addressed:[/color] Include a link here to the precise post that you're addressing. You can get a post's link by clicking on the #number on the top right of the post. Use the title of the suggestion to provide text for the link, rather than posting the raw link, because there might be multiple suggestions in the same post.

[color=#FFFFFF]Problem Summary[/color][list]
[*]In dot points no longer than a sentence, what is each problem with the suggestion? You can't write "I don't like it", you have to write the reason, so others understand why.
[/list]
[color=#FFFFFF]Amendment[/color][list]
[*]In dot points no longer than a sentence, can things about the suggestion be amended to avoid the problems?
[/list]
[color=#FFFFFF]Further Discussion[/color]
Why not this change? Here you discuss or ramble about the problems in detail. You might want to provide a more detailed example than above of a negative outcome that the suggested change, as is, would result in. You can provide links to other posts in which you've discussed flaws with the suggestion. If you make a real wall of text, consider throwing it in [spoiler] tags so the thread is still easy to navigate.

P.S. I'm sorry if you're on the light theme but it's what you deserve and you know it

Updates:

• Reply to critiques in your suggestion - integrate critiques into problems, edit and clarify your suggestion if there's a misunderstanding, or reply calmly and rationally in the discussion. Don't create critiques of critiques.
  

---

[Champ]

---

Suggestion

Type: Rules
Title: Increased base attack declaration lead time

Specifics

• Change the time required for a base attack declaration prior to attack in the server rules to 24-72 hours.
  

Potential Problems

• Base owners may be more prepared for an attack having the notice. May be countered by heavier automatic penalties for neglected bases.
  
• Attackers have to wait a little while longer.
  

Example of Effect
Players are required to provide more notice for attack declarations. This prevents attacks being declared and commenced inside of a work or sleep cycle, and allows more time to notice the attack, organise, and maybe have a little time to prepare the base.

Further Discussion
It is unfair to use the OORP unawareness of players to gain an advantage, when inRP base staff would absolutely be aware of an attack, and when players, even groups, are not available every day of the week, let alone every hour of the day. This suggestion doesn't change how many players are likely to defend the base, meaning that if the attackers were going to win before, they're probably still going to win anyway, as they ought to in such a case.
Link for further rambling (this one's in a secret forum)

---

Suggestion
Type: POB Plugin
Title: New low-efficiency high-speed repair commodity

Specifics

• Create a new repair commodity sold on "lawful capitals" and "unlawful capitals"
  
• Bases consume this repair commodity at a much lower efficiency, but have a much greater repair speed
  

Potential Problems

• Not sure if the base plugin can have individual repair commodities count for different amounts / speeds of repair.
  
• Sufficient trading would overpower military attacks on the base, which doesn't necessarily make total sense iRP, but it doesn't have to; this is OORP balance.
  
• Attackers have the advantage of the first move. But this isn't really a problem; it makes sense that you have to suffer damage before you can fix it.
  
• Speed-runs during attacks. Docking must be disabled for every tick that a base is under attack, shield or not.
  
• Practicality of this strategy is highly linked to distance from a lawful or unlawful "capital". More isolated bases are more vulnerable, but bases at a capital are just about invulnerable. The cap to usefulness is determined by base storage limit. This commodity should be so space-ineffective that leaving it there for repairs over time shouldn't at all be practical. Precision of the balance would be essential.
  

Example of Effect
Ten battleships attack a base for 2 hours, for a total of 20 hours game time. Later, in their own timezone, 10 defenders log transports, deliver this space-ineffective high-speed repair commodity for 2 hours for a total of 20 hours game time, and repair up to or a percentage of the damage caused by the attackers in the same timeframe. Whoever plays more wins. Groups are still able to intercept / blockade each other, so numbers do matter, but individual attackers / defenders still have a chance to deal some damage or supply some.

Further Discussion
Timezones are a pain! Bases have to be militarily defended when they're being attacked, but what if no defenders are available or awake? Currently there is no way for people to defend a base between the attackers actually being online. But what if there was? Imagine you have 10 battleships sieging a base for two hours. They log off. Hours later, defenders wake up, but there's nothing to defend against. So what if they could compensate for the damage dealt in a non-automatic way that doesn't cheat attackers of the damage they've achieved? Introducing, high-speed low-efficiency repairs. Defenders log transports, go to the nearest friendly "capital" where this fixed-price commodity is sold. It is far, far less space effective than normal repair commodities, but it is way faster. So, if 10 defenders fly 5K transports for two hours each, they can make up for the damage incurred in the same amount of game time. This means that bases right on top of inRP well defended locations are even safer than they already are with NPC patrols, and bases in isolated and dangerous locations far from civilisation are less safe.
NB: Lawful and unlawful "capitals" are literally house capitals and the unlawful equivalents and the further respective factions stray from each, the more dangerous the base is. This assumes unlawfuls can access each others' bases, which will have to be considered when selecting these locations.
Link for further rambling (also in a secret forum)
Reply to critique by darkwind: The commodity is for if the defenders are online, but the attackers are not. If the attackers are actively sieging the base, the best thing for the defenders to do is log a bomber or battleship and destroy the attackers. Indeed, as covered in the suggestion, docking during sieges must be blocked to prevent nonsensical blockade running to the base under siege.
Reply to critique by Anton Okunev: This is indeed a suggestion aimed at rectifying the problem of attackers and defenders being online at different times, but the point of this thread is to develop concepts as solutions for problems. I don't understand how your critique applies to the suggestion aside from that it is apparently similar to EVE which I don't play and Thyrzul's post which I didn't read in detail.

---

Critique
Suggestion Addressed: Delete the POB plugin

Problem Summary

• Deletion would greatly affect existing established POBs and their surrounding RP and activity. It is likely to disenfranchise many players.
  
• A replacement model would need to be sought for cloaks and special equipment.
  
• The function of POBs as a motivator and money sink would leave a gap in the economy requiring rebalancing and redesign, including the creation of new models for money sinking.
  

Amendment

• Instead of deleting the plugin, changes should be made to it that would make it easier, simpler, more pleasant, etc.
  

Further Discussion
The changes in detail are: what Champ says, because he is righteous and just the best, really. I would write more, but is it necessary to further flesh out why that's correct? Well, this is an example, so no. But if this were a real critique, it's quite probable.

---

[Grumblesaur]

---

Suggestion
Type: POB Plugin
Title: Placement Constraints

Specifics

• Plugin code would be changed to detect distances from certain objects in system.
  
• A minimum distance constraint from mining zones, dockable solars, and lootable wrecks will be introduced into base placement.
  
• Placement of a base will fail unless the constraints are met.
  
• Failed placement will not consume resources, and will notify the player of the nearest object whose constraint they are violating in a chat message.
  

Potential Problems

• Building in systems with many NPC bases may require base construction off-plane or off the map, which may introduce some navigational difficulties for first-time base visitors.
  
• Scanning all objects in a system, filtering them by the relevant properties, and calculating distances may be non-trivial, and CPU time-intensive; however, POB placement is not a frequent operation.
  
• POBs which predate this change will need to either be grandfathered in (and thus potentially have an advantage from proximity to other bases, NPC or player-owned), or manually relocated by a GM (which takes time away from other duties).
  

Example of Effect
By programmatically constraining the placement of POBs, less GM time will be devoted to moving bases which foul trade lane junctions, obstruct jump holes, or merely sit in illogical or impossible places.

Additionally, it prevents POBs from deforming the intended designs of systems by the development team. NPC bases, dockable objects, mining zones, and loot caches are all placed with certain intentions of creating player interaction, respecting the lore, producing aesthetics, and progressing the story. POBs can be used to subvert these designs, by shrinking the gap between a resource (wreck or mining field) and a safe haven. Nefariously-placed POBs can also create choke points or induce area denial (particularly through their weapon platforms) not intended by the systems developers. Sometimes they're simply ugly and unbefitting of their location.

With POBs constrained to a minimum distance from interactive objects in space, they are less likely to form redundancies and hazards, and more likely to populate frontier regions of systems.

Further Discussion
This would have a further effect of preventing the construction of "planetary defense grids", where POBs are constructed around a major solar in a system, with weapon platforms strategically arranged to create a protective bubble. As POBs are themselves dockable objects, the construction of adjacent POBs would not be possible.

During sieges, attacking players would find themselves at a disadvantage, as the enforced remoteness of the target will make changing ships or resupplying consumables difficult or time-consuming. For defenders, this would not change much, except for perhaps adding a few extra minutes to the cruise time toward the base.

Note that while it's possible to build a base in a remote location at present, many bases are simply built adjacent to NPC bases or other notable areas on or near the system's central plane. Requiring a certain amount of effort to place bases may enhance their security. The off-plane or off-map volumes of space are ultimately much larger than the plane plus-or-minus 10K volume that most systems' objects lie within.

---

Pseudocode describing the constraint-checking procedure:

Spoiler

Code:

# POB Placement Constraint Pseudocode

# Trivial, well-known function listed for completeness of this example.
function distance3D(position1, position2):
  return square_root(
      squared(position2.x - position1.x)
    + squared(position2.y - position1.y)
    + squared(position2.z - position1.z)
  );


# When a player attempts to create a base, before the plugin checks that the
# player has the appropriate goods in their hold, this check occurs. The return
# value is a pair (or tuple) of values, where the first is a boolean indicating
# success or failure, and the second is a string, which will be the name of the
# first object which raises a conflict if the procedure fails, but an empty
# string on success.

function is_valid_location(player, system, minimum_distance):
  foreach object in get_objects_in(system):
    let is_constraining = is_mining_zone_marker(object)
                       or is_lootable(object)
                       or is_dockable(object);
    
    if not is_constraining:
      continue;
    else:
      if distance3D(player.position, object.position) < minimum_distance:
        return pair(false, object.name);
  return pair(true, "");

# What the procedures is_mining_zone_marker(), is_lootable(), is_dockable(),
# and get_objects_in() look like is dependent on the structure of objects in
# FLHook, which I am not familiar with.

---

A way a lone a last a loved a long the riverrun, past Eve and Adam's, from swerve of shore to bend of bay,
brings us by a commodius vicus of recirculation back to Howth Castle and Environs.

[LaWey]

---

Suggestion
Type: POB Plugin / Economy
Title: POB economy rework.

Specifics

• Finally study how indeed POB interact with economy.
  
• Change recipes for POB deployment and modules building with small amount of very high cost commodities.
• Separate maintenance commodities from production ones.
• Rebalance the production's economy.
• If it possible, limit the POB deployment in 30-60k zone around a mining field plugin-wise (cross with Grumblesaur "Placement Constraints").

Potential Problems

• The head of the economical development.
• Math skills.
• Dirty hacks needed to solve the mining POB problems.

Further Discussion
The general idea - POB should be money sink and right now they don't. POB interact with the economy, but it was ignored since implementation. POB should waste money and not time. Conventional money farm, incrusted in general game design, instead of unneeded, disconnected from other mechanics grind.

repost of examples elaborating thought behind it

NUMBERS TOOK OUT OF ASS WITH INTENTION TO DEMONSTRATE THE CONCEPT (lower than needed, and I not joking, disco inflation that bad).

1) POBs should be made as temporary as they called. Conception should be based around fast to deploy - fast to kill.

To achieve this i propose drop out in window recipes with 1000500 of garbage to deploy base and build base's module, Instead, implement "base construction kits" commodities with certain characteristics:

• Very high price - so you invest your credits, and its actual money sinks from the economy.
• Big volume - player forced to haul it on transport. This is just organisational moment to spice risks and RP behind building (i.e. you can't just deliver all modules on LF, which nobody can intercept.)

Example:

• "Modular Base Core" - 700 volume, 250-500+ millions. (this is starting module for BCP deployment)
• "Modular Base Storage" - 1000-1500 volume, 100-300 millions.
• "Modular Base Shield Generator" - 1000-1500 volume, 500 millions.
• "Modular Base Core Extension" - 1000-1500 volume, 1 billion.
• And etc..

To balance risks, or to create chances for cargo piracy, or to allow place PoB somewhere in uncharted asshole, or to set bigger price without breaking freelancer money limits, it obviously can be divided on like 5-10 of 1000-1500 volume commodities required to build a module. Like, make shield generator constructed from 10 parts with 1000 volume, cost 50 million every. Or like, core extension from 20 parts with cost 100 mils every.

That just shouldn't go further than 1-2 5kers per module. Players should waste their time farming that money on conventional trade routes or on missions to benefit healthy interactions.

2) POBs-related mining and ore distribution should be studied, considered and regulated.

The best way here, make plugin check if player inside some dummy area and prevent BCP deploy inside it, implement those spherical areas in every volume, where we don't want to see PoBs. For example, placing POB ~60k out of the field can naturally solve economic and piracy issues. That way, miners groups who use excavator-dump truck gameplay won't be harmed, solo relog mode - discouraged.

3) POB maintenance should be separated from POB production.

Nuff said, separate "Modular Base Maintenance Kits" commodity, with a high price. Selling locations of them along with base factories materials should be considered to favor POBs along main roads, preferably industrial. POB should be startup business project/or Tamagotchi for wealthy boys. Money consuming, not time.

*No production recipes balances here, cos this one require more math justification behind certain numbers and sellpoints placement.

---

Critique
Suggestion Addressed: New low-efficiency high-speed repair commodity
Problem Summary

• This is just further patchwork approach to problem of implemeting "vulnerability time and reinforcement" mechanic.
• Just a subpart of more complex mechanic, cannot be considered in separation from it.

Amendment

• Develope new siege mechanic concept.

Further Discussion
In short, this idea just further downgrade of Thyrzul proposal for "siege mode repair rate", which already was the downgrade of EVE "vulnerability window/reinforces" mechanics. Both of those proposals, in fact, trying to achieve EVE's multi-stage nature of siege through the distinction of in-siege and in-still modes. This is not bad idea itself, I just pointing out, that its all just different ways of how certain conception (relatively short, but multiple and intense fights determinating siege) can be executed. For proper discussion, we should first set a clear vision of siege conception, and only after this consider possible solutions for it achieving. That how we won't miss the problem's core.

[Sava]

---

Suggestion
Type:Rules / POB Plugin
Title: Vulnerability time windows for POBs (tweaking of siege rules and/or mechanic)

Specifics

• POBs can take damage only during a pre-set hours (vulnerability windows)
  
• 2 vulnerability windows (about 1-2 hours each), one set by the owner, another by the attackers to minimize the impact of different time zones
  
• The owner can specify his POB vulnerability window once the base is built. He can change it whenever he wants, unless there is an active siege declaration(can't change during the siege). Owner's base vulnerability window is made PUBLIC.
  
• If owner's vulnerability window isn't specified, attackers can choose both windows for their convenience. Attackers' choice is made public in the POB attack declaration.
  
• Since suggested windows are relatively short (no longer than 2 hours each), if owner and attackers time preferences are similar, attackers just have to put their window right before/after the owner's, I see no problem here. They can not overlap.
  
• Maximal damage the base can take during the time window chosen by attackers equals to the amount of HP it can heal per 24 hours. Damage it can take during the owner's phase is unlimited.
  
• Attack declaration expires in X days. However, If attackers manage to damage the POB below Y% of it's original HP, the siege continues until the POB is destroyed, or it reaches 100% of it's HP, and a cooldown period starts until next declaration can be issued.
  
• Cooldown period is Z days (weeks)
  
• POB shield efficiency, repair rate and max HP may require tweaking to make this work properly.
  
• Can be done (almost) entirely by tweaking the siege rules, no coding required
  

Potential Problems

• requires testing and proper balancing

Example of Effect
The fighting concentrates around 3-4 hours a day, much less exhausting and toxic for the players. To achieve their goal, each team has to succeed in the preferred time window of their counterparts. To overcome the repair rate, damage the base to Y% threshold, and subsequently kill it, attackers have to siege during the owner's vulnerability window (supposedly high-pop time). To let their base fully repair and claim victory, defenders need to brake siege during attackers' time window (supposedly night/morning time) in addition to supplying it.


Further Discussion
The attackers' phase damage cap is intended to, on one hand, make it impossible to kill a base when everyone but siegers is asleep, on the other give them a leverage big enough that, if not countered, will make defense impossible either, and the base can be gradually worn down by attacks (even relatively small) during defenders' time window. It has to be capped somewhere close the repair rate, otherwise it enables the much-hated 3 AM AFK krieg and almost complete absence of normal PvP, and I think everyone agrees that's not what we want.

---

XTF wiki ☼ XTF forum

[darkwind]

---

Suggestion
Type: Rules
Title: Roleplayed for sieges Doomsdaydevice PoBs, siege PoB vs PoB

Specifics

• People who want to siege some PoB should make a roleplayed doomsday device, which is essentially built by the same PoB rules another PoB to destroy PoBs from Core 3+ level.
  
• Doomsday device would require in the same way month of roleplay and waiting a month to reach Core 3 for destroying Core 3 base, an additional month for Core 4 to destroy Core 4 base, and Core 5 to destroy unique Core 5 bases. (Basically same rules as building PoB)
  
• Doomsday device is used once to destroy one PoB and it has HP, so it can be destroyed during the siege by defenders.
  
• Event would come to, who destroys equal Core level PoB, attackers to attack their target PoB, or defenders to destroy doomsday device PoB
  

Potential Problems

• attackers would be always in favor as they have siege weapons and multiple battleships prepared, while defenders would be needing the same and they would not be able to use bombers to siege doomsday device, except as using their bombers to disrupt attackers attacks. It should not be a problem if defending party has an allied party with a fleet of caps + bombers at its side in bigger number. But they would be needed orienting for siege equipment too for effect similar to attackers.
  

Example of Effect
Some PoB in Dublin has Core 4. Unlawful builds in whatever place in the same system doomsday device PoB. Once it's ready and roleplayed to Core 4 as the attacked PoB, they make attack declaration, pointing there attacked PoB and where the existing doomsday device.
Attackers successfully kill the PoB and it would disappear with a doomsday device
or Defenders kill doomsday devices and it would disappear.

Further Discussion
It feels nice that attackers would have to do equal work as Pob owner did for the base construction. And during the siege, it would be literally PoB against PoB, totally equal ground as both can destroy PoB.

Attackers would be favored due to having siege guns and better battleships, but their doomsday device would always disappear in both outcomes. So they did enough effort in transport hauling, attacks and roleplay to destroy other people's roleplay, efforts in transport hauling and defense to protect it.

It requires basically no PoB plugin tweaks. Everything can be done at the rule level.

Every time for every destroyed roleplayed PoB, attackers always pay with their destroyed doomsday device PoB also. Both losses are equal.
Defenders and attackers both transport hauled
Defenders and attackers both equally roleplayed and waited to build their things
Defenders and attackers both could siege opponent targets for a win.
Defenders and attackers both could use bombers to disrupt attacks.

---

---

Critique
Suggestion Addressed: To New low-efficiency high-speed repair commodity method
About balancing attackers with defenders by amount of battleships to transports.

Problem Summary

• Ten amount of enemies against ten amount of transports would be not equal due to transports needing ten more escorts to clear their ground for supplying. So it would be 10 enemies vs 10 transports + 10 escorts to make equal ground.
  
• Explaining the point above. Attackers need only fighting skills, defenders need fighting skills to clear the road for transports + a lot of transport hauling in addition.
  
• Further upsetting the balance, battleships have siege guns making them counted for two. Or they just take rented multiple siege guns.
  
• So 5 battleships working as siegers could make damage for 10 transports, and kill all transports as snubs, as escort can't even protect transports unless by scouting.
  
• Low efficiency of escorts makes a separate point
  

Amendment

• Choosing a different method of balance or making odds favoring transports.
  

Further Discussion
I mostly explained that in different points of problem summary. The point stands for attacking having only attacking skills, and defenders need to have fighting skills and transporting skills at the same time.

---

Interstellar	Dev Feedback	Dev Anouncements	Encryptor	Discovery At Linux
Dark Tools	Autogit	DarkBot	DarkLint	DarkStat

[SwiftWing]

---

Critique
Suggestion Addressed: Grumblesaur - Placement Constraints

Problem Summary

• Prevents intentional placement in proximity to another base
  

Amendment

• On and off setting
  

Further Discussion
I only see one Major Problem with a Auto Deny Feature. If your a Member of a House faction and you want to put one close to another base, this would prevent that, when the System Government allows this. so maybe something like the Autobuy Plugin, on and off maybe, If it could be done.

[SwiftWing]

---

Suggestion
Type: POB Plugin & Base Weapon Replacement
Title: Give a Base a fair chance of fighting back!

Specifics

• 1. Plugin could be used to Activate on and off the Base mounted Weapons.
  
• 2. Code change to allow Hardpoints on Base to accept Base made Cap Buster.
  
• 3. Plugin, Separate Base Red List By Damage
  

Potential Problems

• Coding to allow base to make a Cap Buster and maybe a Mid Ranged Fighter Bomber Killer Weapon on the base. And the Base Hardpoints to accept either weapon. Plugin, Separate Base Red List By Damage
  

Example of Effect

• 1. As it is BS's Set outside the firing Zone and Kill the base the base has No real way to defend itself, and is really Just a sitting DUCK!. this would at least give a base a fighting chance. the weapons are not Rapid Fire weapons. but are fast enough to catch most players. Remember enemy ships can spawn and come back a Base Can't run or evade.

• 2. Will Deter some attackers from taking on bases. Make them have to learn a new strategy other than falling asleep Firing in place. Each Core level could have Harder Hitting Missiles. But the Missiles would be Hard to shoot down.

Further Discussion

Spoiler

Why this change?
1. a base is so underpowered to defend itself it is time for a major base upgrade. why should dit only be the base that dies in a PvB Battle. in real life a base would have options to defend itself against such attacks, and everyone is so tired of POB Owners Getting on the bandWagon Gripping about there base being killed. Well the reason is because the base doesn't have a chance. If you want a challenge why not go try to kill a Ingame base at least it can fight back and have a chance. That's all POB Owners are asking for is a chance for there bases.

2. New Plugin
(Base Red List) for Base Heavy Hitters, for Cap Buster Missiles Launching Approval. Separate from Base enemy (Blacklist) - Fires standard Weapon Platforms, By Damage done to the base, So little players shooting at NPC's and hit the base by Mistake never get on that list because they raised the shields. we don't want any Deaths due to activating the shields! Also allow the Plugin to Remove players as well from Red List.

3 - Plugin:
Give Base weapons Multiple options for Defense Modes.

• 3.1. Set Cap Busters to Stay locked onto target if still in MAX range Option.
  
• 3.2. Always attack Closest target.
  
• 3.3. Auto change target if Target it not hit within Set amount of time.
  
• 3.4. Always attack Closest enemy.
  
• 3.5. Attack Farthest to Nearest Targets
  
• 3.6. Attack Nearest to Farthest Targets
  
• 3.7. Attack targets doing the most damage
  
• 3.8. Option to set Weapon 1 to one setting and weapon 2 to different options.
  
• 3.9. Maybe other Options.
  

4 - Battleships Don't fear a POB
Why don't they, simple Bases are not dangerous to CAP ships at range. Since a Battleship doesn't fear a POB, why not allow a POB Owner to replace the Base Guns themselves, with CAP Busters.
And here is the thing, The Ammunition has to be specially made for it to fire. Now the Ammunition are Fast Attack Long Range Missiles up to 12-15k away. since BS's can fire Missile from 10k away. Nightmare 10k, or Hurricanes 5.5k away.
The Ammunition Could be made, and Stored, Even Sold on POB's and maybe on House Permanent Base (maybe).
(Reason) for such Long range of 12-15k and maybe Longer Ranges and the speed. is because BS's can fire and go to cruise and get out of range before the missiles even got near the base.
So maybe even range up to 20k or something. If they want to kill a base make them work at it not go to sleep firing lol

5 - Missile abilities
now here is the thing, You have to do X amount of Damage to a Base to activate the Missiles. Once the Activation has happened a Warning Message would Automatically Post to System Chat Warning the Base Defense Missiles have been armed, and 20-30 seconds later anything that fires on the base is fired upon. so the Next Hit Fires the Missiles. Basic Shield Activation will not Ever activate the Missiles, it would take at least 1-2 Heavy Mortar Hits or something equal that in x Amount of time to activate the Missiles, Unless it is during the 1 hour Siege Defence Mode. and a cool down for 1 hour. but during that 1 hour anything that shoots at that base heavier than Accidental Firing will be Destroyed. Anything Smaller than a BS would be destroyed in a Single firing of the 2 Missiles. (any Hit during that 1 Hour to the Hull, Or shield Resets the clock)

6 - The Missiles always fire in Pairs, and the Damage is enough to take down a BS's Shields Instantly with the First Missile, and Hull with 4.0 Armor, Down by 50% with Second Missile. and the missiles are fast enough to Hit a BS in Cruise at least 15k away.

7 -The point
The point is to make a base where it can hold its own for a while and fight back. and make a BS owner Respect a base, not fall asleep while he is firing at it.
Right now the big thing is a Base Does not even have a chance, from Venilla Freelancer Yeah it is strong, But we are WAY past that!.

8 - Base Major Upgrade Needed
So bases are in Need of a Major Upgrade to keep up with times! the point is give a Base a Chance. Look at all the work a Base owner would have to do to have a chance at surviving, what does a BS have to do? Nothing Just respawn if they die, so nothing lost. as opposed to month and months or Years gone in just a few hours. NOTE Remember that as it is a Base can't really Kill anything, take out a couple turrets and then everyone Mostly sets outside of range and fires. they bring 10 BS's and at least the Base could kill a couple hear and there. I would set it where to destroy a base the base Cap Busters should be able to maybe kill at least 5 BS's in an Hour that don't leave and repair.

9 - Rule Change:
Base Attacker Death Cooldown should count for a base same as for a Player killing the Ship. and if a BS leaves the Combat Area it is same as fleeing a battle.

10 - Coding:
Note: this would not be a weapons platform, But base Gun Replacement, and would not take up any slots on base. 2 Weapon replacements, each firing 2 missiles.

Thoughts and Discussion Please..

[Grumblesaur]

---

Critique
Suggestion Addressed: Sava's limited siege window idea

Problem Summary

• The intended behavior during a siege whose attackers and defenders have aligning schedules is not discussed; is this feature supposed to apply for all sieges, or only for the ones that have a temporal disparity between the attacking and defending parties?
  
• If this feature must be used in all scenarios, and the attack and defense phases overlap either partially or exactly, does the damage cap take precedence, or does the unlimited damage rule take precedence?
  
• If this feature is only used during scenarios where the time disparity is significant, it actively disadvantages players whose play times are off-peak.
  
• Damage cap on defender's phase diminishes the need of defenders to actually defend their base during their chosen phase.
  
• Assumes that only one siege on a base can be waged at once; that is, there is no consideration for separate, concurrent sieges against the same base.
  

Amendment

• Eliminate the damage cap rule.
  
• Describe rules for handling separate, but concurrently-declared sieges against a single base.
  

Further Discussion, regarding risk

Spoiler

If the defenders can repel the attackers during the attackers' phase, and the defenders can supply the base during the downtime phase(s) between the attack and defense phases, the base will net no damage, even if the attackers brought a larger force during the defense phase than during the attack phase. If the defenders and attackers choose the exact same time window for their phases, and the damage cap rule takes precedence, the base is nearly invincible due to the downtime period permitting repair materials to be supplied in an amount sufficient to regenerate all or nearly all of the damage sustained during the overlapped attack-defense phase.

Having a damage cap also means that large factions with lots of players effectively lose the advantage they earned by recruiting and outfitting additional members, while bases maintained by small groups get to enjoy the effective benefits of greater manpower and coordination without actually having to organize additional players. Base owners should be motivated to organize players for defense, either through recruitment, or by forging contracts/alliances with other groups; allowing off-hours POB supply traders to replace defense-phase combat ships subverts the intrinsic fleet-style PVP qualities of a siege.

Note: off-hours POB supply traders will naturally receive the benefits of the rules which prevent transports from being treated as combat targets without a demand, unless an additional rule is specified which permits the attacking party of a siege to destroy supply ships bound for the besieged installation. In this, and in the time windows themselves, the very idea of a siege (being a military operation to starve out a city, base, or other fortified target of interest) is eliminated. Supply lines cannot be cut off when downtime is always guaranteed to be allocated to them.

While I think eliminating the damage cap during the defense phase of the base would improve this idea, I think it weighs too heavily in favor of the defenders regardless. Siege is a PVP engagement, and defenders should still need to muster forces for that engagement, even if these limited-time phases are utilized.

---

Further Discussion, regarding time

Spoiler

Temporal disparity was a major discussion point in other threads, and was usually assumed to be malicious scheduling on the part of the attackers. I think it does a severe disservice to the community at large to assume that people deliberately choose inconvenient times to siege; it is impossible for users to know every other user's personal routines and country of residence. Attackers are more likely to choose a time to siege based on its convenience for them, not its inconvenience for their adversary.

There is no misunderstanding here about the function of Sava's original suggestion, deliberate or otherwise; but it leaves questions unanswered about whether policy, programming, or both will determine the times of siege, and what should happen if the attacking players and defending players have schedules near enough to overlap.

What's 3AM for some players is 6PM for others, and it could hypothetically be any time assuming we have Discovery players in every populated time zone. Furthermore, there seems to be an underlying assumption that every POB encounter will be between attackers and defenders of disparate, incompatible schedules, which in practice is demonstrably not true, because we know that players in opposing factions exist in the same time zone. Likewise, we know that one faction can have members from multiple time zones.

Hence the concern regarding overlapping attack and defense phases. Sometimes there will not be a temporal disparity. Is this change optional in those cases, or should it be used in a special way? This is unclear.

Additionally, should ever two separate factions declare siege on a single base, without specifically forming an alliance to do so, would they be given simultaneous attack phases, or separate attack phases? Would the defenders have to pick two defense phases, or keep only one? The current, organic system of POB siege does not need to make this consideration because that kind of complexity is not currently necessary to account for.

---

Final thoughts
The siege time window suggestion does not solve a balance problem intrinsic to POBs, but tries to solve a problem of incompatible time zones that applies in the general case to all online activity in only the domain of POBs. Lastly, it narrows the availability of interaction with a base considerably, such that for the many hours not alloted as part of the siege schedule, the base has a far longer OoRP protection than normal combat rules offer.

---

A way a lone a last a loved a long the riverrun, past Eve and Adam's, from swerve of shore to bend of bay,
brings us by a commodius vicus of recirculation back to Howth Castle and Environs.

[Sava]

---

Suggestion
Type: POB Plugin / Economy
Title: Make POBs eat credits instead of cargo

Specifics

• Pretty simple - make base consume credits instead of FOW, RA, RH, HS. Straight from the POB bank.
  
• Re-direct traders from POB supply to regular cargo routes.
  
• Wear and tear damage repair - 2 mil * core level per day
  
• Normal repair - MODE 1: 1 mil per 1 million of HP; MODE 2: 3 mil per 1 million of HP, twice the repair speed
  
• Numbers can be adjusted
  
• this change only affects repair and maintenance, production and module construction still has to require cargo.
  

Potential Problems

• Deprives POB sieging party of the ability to block essential supply routes (though it's not really a time-efficient activity for siegers and doesn't seriously affect the gameplay atm IMO)
  

Example of Effect
Trader.Joe now carries ores between Bretonia and Rheinland instead of following a 1-jump route 10 times in a row.
Wealthy players can sink their reserves.
Easier to consider costs and benefits of maintaining a base.
Maintenance difficulty will not depend on the base location, but POBs in remote and hard to reach areas would still sink credits and their usefulness would be questionable.

Further Discussion
-----

---

XTF wiki ☼ XTF forum