How to Use the FoE Calculator as a GB Owner

If you own the Great Building, start with the GB Planner mode. Open the GB level in Forge of Empires and enter the total FP needed to finish the level. If you have already added FP yourself or another contributor has already paid into the GB, enter the current FP already on the building. Then enter the base FP rewards for each position that you plan to advertise. If you only plan to list P1 and P2, leave the lower positions as zero or ignore their results.

Next, enter the thread rate as an Arc bonus percentage. For a standard 1.9 thread, use \(90\). For a 1.92 thread, use \(92\). For a 1.95 thread, use \(95\). The calculator converts that percentage into the multiplier used for patron deposits. If you are using a custom thread rate such as \(1.85\), enter \(85\) because \(1+\frac{85}{100}=1.85\).

Read the results in two stages. First, look at the calculated donor deposits. These are the FP amounts patrons are expected to add for each position at the selected rate. Second, look at owner cost and lock guidance. A low owner cost is useful only if the positions are safe. If a position is not locked, add the required preload before you advertise it. Posting a position before it is secure shifts risk onto the donor and can damage trust in the thread.

The calculator is not a substitute for checking the live GB screen. Always confirm the level, total FP, current FP, and visible contributions in-game before posting. The tool can process the arithmetic, but the player is responsible for entering the correct values from the current level.

How to Use the Calculator as a Donor or Sniper

If you are the contributor, use Arc Reward mode when you simply need to know how much a position pays with your Arc. Enter the base reward shown by the GB and your Arc bonus percentage. The calculator displays the boosted reward, the planned donation, and the net FP result. This is useful when a thread post gives a position number and you want to verify whether the posted number matches the agreed thread rate.

Donors should not focus only on direct FP profit. In a strict 1.9 thread, a level 80 Arc donor usually breaks even in FP and gains blueprints or medals. Players with an Arc above level 80 may make a small FP profit on standard 1.9 payments because their actual reward multiplier is higher than the posted thread rate. For example, a donor with a \(92\%\) Arc who pays a 1.9 rate receives \(1.92\) times the base reward while paying about \(1.90\) times the base reward.

For a potential snipe, use Secure Spot mode. Enter the total FP to level, the FP already on the GB before your planned donation, the base reward for the target position, your Arc bonus, and any strongest lower rival contribution. If the tool says the spot is not safe, the issue is not necessarily that the position is bad; it may simply mean that more FP must be added by the owner before your donation is protected.

Worked Example: Standard 1.9 Reward Calculation

Suppose a Great Building shows a P1 base reward of \(200\) FP. In a standard 1.9 thread, the Arc bonus is \(90\%\), so the multiplier is:

The donor deposit at the thread rate is:

A level 80 Arc donor receives \(380\) FP back when the GB levels, so the direct FP profit is:

The donor breaks even in FP and gains the position rewards. The owner benefits because the donor added \(380\) FP toward the level. If the total level cost is \(1000\) FP and no FP has been added yet, the owner cannot safely post this P1 immediately. The target donor would add \(380\), leaving \(620\) FP remaining. A rival starting at zero would need \(381\) FP to pass the P1 contribution, and there is enough room left for that rival to do so. The owner should preload at least:

Once \(240\) FP are already on the GB, the P1 donor can add \(380\), leaving \(380\) FP to finish the level. A rival with zero FP would need \(381\) FP to overtake, but only \(380\) FP can still be added before the level completes. The position is locked.

Arc Bonus Multipliers and Thread Rates

In FoE discussions, players often speak in multipliers rather than percentages. A \(90\%\) Arc bonus is called \(1.9\), a \(92\%\) bonus is called \(1.92\), and a \(95\%\) bonus is called \(1.95\). The calculator accepts the percentage because that is the easiest way to enter the actual Arc boost shown by the game.

Rounding matters because FoE works with whole Forge Points. If a base reward multiplied by a thread rate gives a decimal, guilds may have different rules. Many players round down for the posted donation because the in-game reward cannot pay a fraction of an FP. Some guilds round up as a safety convention. The calculator uses floor rounding for boosted reward display and lock deposit estimates, then shows whether the resulting number is safe. If your guild has a specific rounding rule, follow the rule consistently and communicate it clearly.

Secure Spot Math Explained

A secure spot calculation is about available room. After a target donor pays \(D\), the GB has only a limited number of FP remaining before the level completes. A rival must add enough FP to pass the donor's contribution. If the rival cannot physically add that many FP before the level finishes, the donor's position is locked.

The simplest case assumes the rival has \(0\) FP on the GB. If the target donor pays \(D\), the rival needs \(D+1\) FP to pass. Because only whole FP can be added, a remaining capacity of \(D\) or less is safe. That is why the common preload formula uses twice the target donor deposit:

If a lower rival already has \(R\) FP on the GB, the rival needs only \(D-R+1\) more FP to pass. The higher the rival's current contribution, the more careful the owner must be. The adjusted preload formula is:

This is why a GB may be safe in an empty-thread situation but unsafe after random donations appear below the target spot. Before posting a position, check the live contribution table. A small lower contribution can change the lock threshold, especially on high-value P1 and P2 rewards.

Owner Cost, Patron Value, and ROI

Owner cost is the amount the GB owner still needs to pay after all expected patron deposits are counted. A level that costs \(1000\) FP and receives \(900\) FP from patrons leaves \(100\) FP for the owner. In percentage terms, patrons paid \(90\%\) of the level and the owner paid \(10\%\). When you compare different GB levels, this percentage is often more meaningful than the raw FP amount because a \(100\) FP owner cost is excellent on one level but poor on another.

Donor ROI compares the direct FP result with the FP invested:

In a strict 1.9 thread, a level 80 Arc donor has about \(0\%\) direct FP ROI because reward and donation match. Higher Arc levels can create positive direct FP ROI on lower posted thread rates. For example, a \(95\%\) Arc donor taking a position posted at \(1.9\) receives \(1.95\) times the base reward but pays \(1.90\) times the base reward. On a \(200\) FP base reward, the donor pays \(380\) FP and receives \(390\) FP, giving \(10\) FP direct profit before considering blueprints and medals.

This is where general math tools can help outside the game context. The FoE calculator gives the in-game numbers, while a broader Math Calculator or Scientific Calculator can help with unrelated arithmetic, ratios, or multi-step calculations that do not depend on GB mechanics.

Using the Calculator for The Arc, Alcatraz, Chateau, Cape and Other GBs

The formulas apply to any Great Building because the calculator uses the base FP reward and total FP cost shown by the game. The Arc is often the most discussed GB because its contribution reward boost changes the economics of every other building. Alcatraz is frequently leveled through active threads because military-unit production is valuable to many players. Chateau Frontenac, Cape Canaveral, Zeus, Cathedral of Aachen, Castel del Monte, Himeji Castle, and other GBs can be planned with the same arithmetic.

The calculator does not need to know the building name to compute the FP result. It needs the current level's total FP requirement and the base reward values for the positions being advertised. That design is intentional because game data may change and players may be working on different eras, events, or server states. Entering values from the live GB screen keeps the calculation tied to the real level you are about to post.

For buildings with high P1 or P2 rewards, lock timing is especially important. The larger the reward, the larger the donor deposit, and the more attractive the position may be to players outside your intended thread. A carefully prepared P1 can be posted smoothly and filled quickly. A poorly prepared P1 can start a dispute, trigger compensation, or cause a donor to lose FP.

When Not to Use an All-Buildings-at-Once Approach

Some players search for a single tool that handles every Great Building in their city at once. That sounds convenient, but it can be less reliable for active thread play. Each GB level has its own total FP requirement, current FP state, base rewards, open positions, and contribution table. A position that is safe at the start of a planning session may become unsafe after a neighbor adds FP, a guildmate makes an off-thread donation, or the owner adds FP to a different level.

One-building-at-a-time planning is slower, but it is safer. It forces the owner to check the live state of the GB immediately before posting. It also creates cleaner communication in the thread: "Arc P1 ready 380" is easier to verify than a long multi-building plan that may be outdated by the time members respond. For guild leaders, a simple repeated workflow usually beats a complex spreadsheet that only one player understands.

If you maintain a private spreadsheet, use this calculator to validate individual levels before posting them. A spreadsheet is useful for long-term planning, but the final public thread number should always be checked against the live GB screen and current thread rate.

Guild Workflow for Clean 1.9 Thread Posts

A clean 1.9 workflow begins before the post appears. The GB owner checks the level, enters the numbers, confirms the target positions are locked, and then posts only the positions that are actually ready. The post should be short and unambiguous. A common format is the GB name followed by the ready positions and FP amounts. For example: "Arc P1 380 ready" or "CdM P2 190 ready."

Donors should claim the position in the thread before paying if that is the guild rule. They should then pay the exact amount, not a rough approximation. If they accidentally overpay, the position may still be safe but the donor loses efficiency. If they underpay, the owner may need to correct the post or another donor may be asked to take the spot. The calculator helps by giving a number that can be copied into the post, but the guild still needs clear communication standards.

Guild leaders can reduce disputes by publishing the accepted multiplier, rounding rule, lock requirement, and compensation policy. A good policy answers four questions: who may post, what counts as ready, how donors claim, and what happens if a posted spot was not actually locked. Once those rules are clear, the calculator becomes a shared reference rather than a source of argument.

Common FoE Calculator Mistakes to Avoid

• Using the wrong reward value: Enter the base FP reward from the GB position, not the Arc-boosted reward you expect to receive.
• Confusing bonus and multiplier: Enter \(90\) for a 1.9 thread, not \(1.9\), in fields that ask for the Arc bonus percentage.
• Posting before the lock is ready: A position can have a correct donation amount and still be unsafe if the owner has not preloaded enough FP.
• Ignoring lower contributions: A rival already sitting below the target spot changes the lock threshold.
• Mixing thread rates: Do not combine \(1.9\), \(1.92\), and \(1.95\) claims in the same thread unless the guild has a clear rule.
• Using old screenshots: A screenshot can become outdated as soon as another player adds FP. Use the live GB screen.
• Rounding inconsistently: Decide whether the guild floors or rounds up fractional results and apply the rule consistently.
• Forgetting non-FP rewards: A break-even FP position can still be useful because of blueprints, medals, or progress toward recurring tasks.

Advanced Strategy: Moving from Break-Even to Profit

Early 1.9 participation is often about stable leveling and blueprint access. Advanced players eventually evaluate opportunity cost. If your Arc is above the thread rate, each claimed position may produce direct FP profit. If your Arc is below the thread rate, you may take a direct FP loss but still gain blueprints that help you level your Arc or another important GB. The correct choice depends on your city stage and goals.

Higher-Arc players often prefer high-volume threads because small profits add up. A \(5\) FP profit looks minor, but \(20\) such positions produce \(100\) FP while also generating blueprints and medals. Owners with high-demand GBs can use the same logic in reverse: fast, accurate posts attract reliable donors, and reliable donors reduce the owner's cost over time.

The most efficient strategy is not always the one with the largest visible reward. A P1 may tie up many FP for longer, while several smaller P3 or P4 positions may rotate faster. Use the calculator to compare direct profit, required donation, lock status, and expected time until leveling. Liquidity matters in FoE because Forge Points sitting in a slow GB cannot be used elsewhere.

Rounding, Safety Margins, and Guild Rules

Rounding is one of the easiest places to make a preventable mistake. If \(75\times1.9=142.5\), a guild might post \(142\) or \(143\) depending on its convention. A floor rule is common because the game pays whole FP and many players avoid overpaying. A ceiling rule can be used as a safety margin, especially when the group wants to avoid disputes from half values.

Safety margins should be explicit. Adding \(1\) extra FP to a donation may make a donor feel safer, but it can also change the lock math for lower positions and alter owner cost. On high-value positions, a tiny difference may not matter much. On low-value positions, one extra FP can be a meaningful percentage of the reward. A guild rule such as "floor all rewards, owner must lock before posting, no optional overpay unless agreed" is easier to manage than case-by-case negotiation.

The calculator displays whole-number results and lock guidance, but it cannot know your guild's social rule. Treat the output as the mathematical baseline. Then apply the guild's posted convention consistently.

Reading Calculator Results Without Overreacting

A negative or unsafe result does not always mean a bad opportunity. It may mean the owner has not added enough FP yet, a rival contribution is already present, or the planned donation is based on the wrong multiplier. Before rejecting a position, check whether the input values match the current GB screen. Many "bad" results are input problems.

Likewise, a profitable-looking result does not guarantee a good play. A profitable snipe might tie up too many FP for too long. A position might be profitable in direct FP but poor for your blueprint needs. A low owner cost might come at the expense of posting positions too early. The calculator answers the arithmetic question; the player still decides whether the move fits the city plan.

Use the result as a checklist. Ask: Is the total FP correct? Is the base reward correct? Is the selected Arc bonus correct? Are current contributions included? Is the position locked? Is the time to level acceptable? If all answers are yes, the number is ready to use.

Position-by-Position Planning for P1 to P5

P1 usually carries the largest FP reward, so it attracts the most attention and requires the most careful lock planning. A P1 donation at \(1.9\) can be large enough to cover a major portion of the level, but it can also create the largest snipe target if the owner posts too early. When preparing P1, calculate the expected donor deposit, then check the minimum FP already required on the GB before the donor pays. If the current FP is below that threshold, add the difference first. Do not assume that P1 is safe just because it is expensive.

P2 is often the second most important spot for owner cost reduction. It can be easier to lock than P1 after P1 has been filled, because the P1 donation itself raises the current FP on the building. In practice, many owners prepare P1 first, wait for it to be claimed, and then calculate whether P2 is ready. The calculator can help with both approaches. If you want to list P1 and P2 at the same time, check that P2 will be safe after P1 is filled, not only at the current moment.

P3, P4, and P5 are smaller positions, but they can still matter. Lower positions are useful for players seeking blueprints at a lower FP commitment. They are also useful for newer Arc owners who cannot comfortably tie up hundreds of FP at once. However, small positions can be awkward when rounding creates half-point values or when many players claim quickly. A \(25\) FP base reward at \(1.9\) gives \(47.5\), so a guild must decide whether the listed amount is \(47\) or \(48\). The lower the position value, the more visible a one-FP rounding difference becomes.

Owners should avoid posting all five positions automatically. Sometimes P4 and P5 are better handled by guildmates who need blueprints, sometimes they are better left for swap activity, and sometimes the owner may finish the level directly. The best choice depends on how fast the thread fills, whether the owner needs the building leveled immediately, and whether the guild has enough active contributors. The calculator gives the numbers; the owner still decides which positions are worth advertising.

Detailed Owner Example: Posting P1, Then P2, Then P3

Consider a GB level that needs \(2000\) FP. The current FP is \(300\). The base rewards are \(300\) FP for P1, \(150\) FP for P2, and \(75\) FP for P3. In a \(1.9\) thread, the expected donor deposits are:

If the guild floors fractional donations, P3 would be posted at \(142\) FP. If the guild rounds up, P3 would be \(143\) FP. Before posting P1, the owner checks the empty-rival preload requirement:

The GB currently has only \(300\) FP, so P1 is not ready. The owner must add at least \(560\) FP, bringing the current FP to \(860\). After the P1 donor pays \(570\), the GB has \(1430\) FP on it and \(570\) FP remaining. A rival starting from zero would need \(571\) FP to pass P1, so P1 is locked.

Now check P2 after P1 is filled. The current FP is \(1430\). The P2 donor pays \(285\). After P2 pays, the GB has \(1715\) FP and \(285\) FP remaining. A new lower rival would need \(286\) FP to pass P2, so P2 is locked. No additional owner preload is needed for P2 in this simplified empty-rival case.

P3 can then be checked in the same way. If P3 pays \(142\), the remaining FP after the donation is \(143\). A rival would need \(143\) FP to pass a \(142\) contribution. Because the remaining capacity equals \(143\), the rival could add enough to overtake by one FP. If the guild rounds P3 up to \(143\), the remaining after donation becomes \(142\), and a rival would need \(144\) to pass. That is safe. This example shows why lower-position rounding can change lock status even when the difference is only one FP.

Low-Arc, Level-80 Arc, and High-Arc Player Decisions

Players below a level 80 Arc often experience 1.9 threads differently from high-Arc players. If your actual Arc multiplier is lower than the posted thread rate, paying the full posted amount may create a direct FP loss. That loss may still be acceptable if the position gives blueprints needed for an important Great Building, but it should be understood before contributing. Use the Arc Reward mode with your actual bonus, then compare the expected reward with the required thread donation.

A level 80 Arc player is the standard break-even participant in a 1.9 thread. This player pays \(1.9\) times the base reward and receives \(1.9\) times the base reward back. The direct FP result is approximately zero, but the player gains blueprints and medals. Because the player does not lose FP directly, the main constraints are liquidity and speed. If your FP bank is low, even a break-even position can be inconvenient while you wait for the GB to level.

A high-Arc player has more flexibility. If your actual reward multiplier is above the posted rate, you can gain direct FP profit from positions that are merely break-even for level 80 Arc players. This is why advanced contributors often watch high-value P1 and P2 positions carefully. A small percentage difference becomes meaningful on large base rewards. For example, a \(2\%\) advantage on a \(500\) FP base reward is \(10\) FP, and repeated positions can add up quickly.

The correct decision is not always "take every profitable spot." High-Arc players still need to consider time to level, blueprint value, opportunity cost, and thread etiquette. Taking a spot that stays locked for days can be worse than taking several smaller spots that level quickly. Taking a position outside the agreed thread process may create unnecessary conflict. The calculator shows the direct arithmetic; experienced players also weigh reliability, speed, and guild relationships.

Troubleshooting When the Calculator and Game Screen Do Not Match

If your calculator result differs from a guildmate's number, first confirm whether both of you used the same base reward. Many mistakes happen because one player enters the boosted reward instead of the base reward. The base reward is the value before the Arc bonus is applied. The boosted reward is the value after multiplying by the Arc rate. Entering a boosted reward into the base reward field effectively applies the Arc bonus twice.

Next, confirm the multiplier. A post labeled "1.9" means \(90\%\) bonus in this calculator's percentage field. A post labeled "1.92" means \(92\%\). If someone enters \(1.9\) into a percentage field instead of \(90\), the multiplier becomes \(1.019\), which is completely different. If someone enters \(190\), the multiplier becomes \(2.9\), which is also wrong. When in doubt, use the formula \(1+\frac{\text{bonus}}{100}\) to check the conversion.

Then check current FP. The secure-spot calculation depends on how many FP are already on the GB before the target donor pays. If a guildmate adds FP while you are calculating, your result may become outdated. If a neighbor adds FP below the target position, the strongest lower rival contribution changes. The lock threshold can move even though the total FP and base reward are unchanged.

Finally, check rounding. If one person floors \(142.5\) to \(142\) and another rounds it to \(143\), both may believe they are following a reasonable rule. The guild should decide which convention applies. The calculator gives a consistent baseline, but the final posted amount should match the guild's convention so donors know what to expect.

Practical Posting Checklist Before You Use a Thread

1. Open the current Great Building level in the game and confirm the total FP needed to level.
2. Write down the base FP rewards for the positions you plan to advertise.
3. Check how many FP are already on the GB before any new donor pays.
4. Look at the lower positions for existing rival contributions that affect lock status.
5. Enter the agreed thread rate as an Arc bonus percentage, such as \(90\) for a \(1.9\) thread.
6. Calculate the donor deposits and owner cost.
7. Check whether each position is locked before posting it as ready.
8. Apply the guild's rounding rule consistently.
9. Post only the positions that are actually ready, using a clear format.
10. After a donor claims, re-check the next position before advertising it.

This checklist may seem slow at first, but it becomes quick with repetition. The aim is not to turn a game into paperwork. The aim is to avoid avoidable FP losses, especially on high-value GB levels where one incorrect post can cost more than several days of collection.

Using the Calculator During Fast Thread Activity

Fast 1.9 threads can move quickly, especially when several owners post popular Great Buildings at the same time. In that situation, the best workflow is to calculate before posting rather than while people are already claiming spots. Owners should prepare the next ready position, confirm it is locked, and then post a clean message. Donors should avoid claiming a spot if the posted amount is unclear, if the GB link does not match the stated building, or if the position appears to have changed since the post was made.

On mobile, double-check numeric fields before pressing calculate. A missing zero can turn \(1000\) FP into \(100\) FP, and a decimal in the wrong place can turn a \(90\%\) Arc bonus into \(9\%\). If the result looks surprisingly good or surprisingly bad, pause and re-enter the values from the game screen. In fast thread play, a thirty-second verification is usually cheaper than correcting an incorrect contribution after the level is already finished.

Official and Community Resources

Forge of Empires is maintained by InnoGames, and live game screens should be treated as the final source for current GB costs and rewards. The official Forge of Empires website is useful for game news, updates, forum links, and support. Community documentation such as the Forge of Empires Wiki page for The Arc and the 1.9 Guild Thread guide can help explain the contribution boost and thread conventions.

This calculator is an independent mathematical tool. It is not affiliated with, endorsed by, or operated by InnoGames. It does not log in to your account, read your city, or change any game state. Always verify live values inside Forge of Empires before making an investment.

Quick Reference Tables

FoE Calculator FAQ