Browse docs
Quality, Consumption, and Risk
What quality means for players
Products with the same item name can differ in quality. A batch is a group of goods with its own condition and history.
Better production and storage can improve value. Poor condition or contamination can make a buyer refuse the goods.
The main values are:
| Value | Simple meaning |
|---|---|
| Quality | Overall production result |
| Purity | A product score some buyers care about |
| Freshness | How well the goods have kept |
| Potency | Strength of the in-game effects |
| Stability | How well the product resists deterioration |
| Contamination | An unwanted quality and risk factor |
Packaging also affects storage and price. A premium container does not automatically turn poor goods into a premium product.
What you should configure
Start with the supplied settings and check whether your first recipe meets your first buyer's requirements.
When changing recipes, compare their output with buyer requirements and prices. Keep the basic route viable.
Use these paths in /drugcreator, then select the entry you want to change:
| What you want to change | Section and editor tab |
|---|---|
| A drug's starting quality values | Foundation → Drugs → Quality |
| How a recipe changes the product | Foundation → Processes → Recipe and result, then Process Steps |
| Field harvest quality | Cultivation & Gathering → Drug Fields → Quality and plant traits |
| What a buyer accepts | Market → Buyers → Demand profile |
Save and produce a new batch for your test. Compare its result with the buyer's requirements before raising the quality thresholds.
You can provide testing_kit so players can inspect goods. A test consumes the kit by default and returns estimates. For a batch stored in a lab, testing near a working testing station improves accuracy.
Detailed item information, called metadata, keeps batches distinguishable in compatible inventories. Processing outputs use it by default; collection outputs do not. See Inventory Items if items merge unexpectedly or lose their details.
Product use and effects
Players can use prepared products through their inventory. Raw harvest is not automatically ready for consumption.
In /drugcreator, use Foundation → Drugs → Consumption Effects for the product's effects. Check Foundation → Strains → Consumption Overrides for changes specific to a strain. Confirm that the finished item is usable and its packaging is allowed.
The system includes effect duration, cooldowns, repeated-use consequences, tolerance, addiction, and withdrawal. These are fictional gameplay settings; choose values that suit your server's roleplay.
Test one finished item with a normal player. Confirm that using it removes the intended stock, starts the expected effects, and lets those effects end normally. Test your actual inventory's Use action.
Heat and police attention
Heat means how much attention an activity attracts. It can build around players, labs, vehicles, dealers, routes, and areas.
Repeated sales, larger operations, risky production, and poor upkeep can increase exposure. Security and quieter operation can help manage it.
Observe a normal operation with the supplied values before changing risk settings.
For street sales, use Market → Street Sales → Heat and police risk. For deliveries, use Market → Sale Routes → Payout and risk. Change the settings for the activity you are testing.
Not every risky action causes an immediate report. Some events are random or delayed.
Make alerts reach the right jobs
Check the internal framework job names. The usual police defaults are police and sheriff; the medical default is ambulance.
Keep drug dispatch enabled if you want the shared Sky Jobs Base dispatch flow. If you use a custom dispatch integration, connect the drug alerts to that integration.
If your ambulance job has a different name, select it for both drug-related medical alerts and consumption emergencies. The configuration guide explains where to change the settings.
Test with a police or EMS player on duty. Trigger the relevant gameplay event and verify that the correct player receives it.
Laboratory threats and player attacks
There are two kinds of trouble:
- Automatic threats caused by the operation's risk, such as raids or sabotage.
- Attacks started by players, with entry tools, security, looting, and possible takeover.
Review them separately in /jobconfig → Crime System: Raids & Sabotage covers automatic threats, while Laboratory Takeovers contains the player-assault rules.
For player attacks, check faction requirements, permitted times, defender availability, cooldowns, and tools. The supplied laboratory assault settings require two defenders online and on duty.
Also make recovery possible. Players need a practical way to pay for repairs, replace supplies, and restore their operation.
Test the consequences
Use a test laboratory with disposable stock. Complete the intended attack and recovery flow.
Check who receives alerts, what is lost or damaged, and who can access the lab afterward. This gives you a useful basis for adjusting security costs and rewards.
For everyday operation, continue with Laboratories and Production or Selling and Distribution.