Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Coolthulhu

Pages: [1] 2 3 4
Many mods use
Code: [Select]
"type": "region_settings" structure.
This json is pretty huge and redefines a lot of things. It sometimes just needs to be changed. Because of the old code it uses, lack of examples (other than core), sheer size, and some weird practices, maintaining backwards compatibility of this structure isn't always as straightforward as it looks.
This means high chances of things breaking if you redefine it.

Instead, if possible, use
Code: [Select]
"type": "region_overlay", like in DinoMod. Redefine only things that you need redefined.
While this won't always warn you that things aren't working, they will still get default values instead of kicking you back to main menu.

Changing "region_settings" in the core necessary if we want to have reasonable cities, biomes, weather etc. so expect it to be disturbed once in a while. Not without warning, but the warning will usually be a PR on github, not a message on forums (like this one).

The primary reason for was that I wanted to make json labs possible.
That PR isn't enough, as it does not account for lab piece connections: two lab pieces need to have doors between them, while lab adjacent to rock should not have doors to nowhere.

I see two ways of connecting lab pieces:
  • Crude: change lab tile type from "lab"/"ice_lab", to one that explicitly mentions connections, then enumerate all possibilities. For example, "lab_NSE" means "lab tile that connects to north, south, and east"
  • Conditional mapgen nesting: add a nested mapgen piece on a condition

The first option is easy, but tedious, menial, can't be easily verified without going through all options.

The latter option, while very flexible, could be a bit complex to use: you'd have to define the condition somehow, then apply it to something. That something would most likely be a nested mapgen entry.
This means that I'd probably need to write a "mapgen condition structure", which would look roughly like one of those (not sure which is the best):
Code: [Select]
Option 1:
"place_nested": [
  { "entries": [ [ "lab_door_horiz", 100 ] ], "x": 12, "y": 0, "conditions": [ { "condition_type": "neighbor_type", "dir": "north", "allowed_ids": [ "lab", "lab_ice" ] } ] }
  { "entries": [ [ "lab_door_horiz", 100 ] ], "x": 12, "y": 23, "conditions": [ { "condition_type": "neighbor_type", "dir": "south", "allowed_ids": [ "lab", "lab_ice" ] } ] }

Option 2:
"place_nested": [
  { "entries": [ [ "lab_door_horiz", 100 ] ], "x": 12, "y": 0, "neighbors": [ [ "lab", "lab_ice" ], "any", "any", "any" ] },
  { "entries": [ [ "lab_door_horiz", 100 ] ], "x": 12, "y": 23, "neighbors": [ "any", [ "lab", "lab_ice" ], "any", "any" ] },

Option 3:
"conditionals": [
    "conditions": [ { "condition_type": "neighbor_type", "dir": "north", "allowed_ids": [ "lab", "lab_ice" ] } ]
    "place_nested": [
      { "entries": [ [ "lab_door_horiz", 100 ] ], "x": 12, "y": 0 }
    "conditions": [ { "condition_type": "neighbor_type", "dir": "south", "allowed_ids": [ "lab", "lab_ice" ] } ]
    "place_nested": [
      { "entries": [ [ "lab_door_horiz", 100 ] ], "x": 12, "y": 23 }

Option 4:
"conditionals": [
    "conditions": [ { "condition_type": "neighbor_type", "dir": "north", "allowed_ids": [ "lab", "lab_ice" ] } ]
    "place_terrain": [
      { "ter": "t_metal_door", "x": 12, "y": 0 },
      { "ter": "t_metal_door", "x": 13, "y": 0 }
    "conditions": [ { "condition_type": "neighbor_type", "dir": "south", "allowed_ids": [ "lab", "lab_ice" ] } ]
    "place_terrain": [
      { "ter": "t_metal_door", "x": 12, "y": 23 },
      { "ter": "t_metal_door", "x": 13, "y": 23 }

Option 3/4 (those are basically one thing, just expressed differently) is interesting because it would allow defining entire conditional mapgen entries without nesting. That is, you could use this syntax to overwrite a palette based on conditions.
Option 2 is the least flexible, only useful for nesting based on neighbors. But it is also the simplest and least likely to lead to problems when some modder implements a complex mapgen entity on hacks and errors in implementation.
Option 1 is a compromise: only useful for nesting, but probably much easier to implement than 3/4.

Any other options? Is this good enough to be useful for anything other than lab mapgen?

There is a problem with armor piercing: to pierce armor well, you need a lot of one damage type, as each damage type is applied separately.

For example, a nodachi - with its huge (50) cutting damage, it pierces armor well. Against a plate armor (16/16 armor), it deals 34 damage - 62% of its 50(cut)+5(bash) damage.
Meanwhile a war hammer - weapon specifically intended for armor piercing - deals 20 bashing and 20 piercing damage. Against same plate armor, it deals meager 10 damage - 25%. That +2 comes from piercing being very slightly better against armors than cutting.

Instead of dealing the attack essentially as two separate hits, it may be possible to deal it as one, spread across the armors.
Using the example above, a plate armor would have a protection value of 16, with multiplier of 100%/100% for both bashing and cutting. A nodachi has 50 cut and 5 bash, meaning it would count as 9% bashing, 91% cutting weapon. Since for plate armor the values are identical, it would just tank 16 damage - 55-16 = 39. Thus dropping damage to 71% of its initial value.
For war hammer, it would be a bit more complex: plate armor has multipliers of 100%/80% against bashing/piercing. Since war hammer is 20/20, this would mean the average protection multiplier is 90%. Thus the armor would offer protection value of 14.4. 40-14.4 = 25. 63% of initial value.

But then there are critical hits and those have their own armor multipliers:
Bashing ignores 50% armor on crit
Cutting ignores 5 armor AND THEN 25% armor on crit
Piercing ignores 34% armor on crit

In current version, this means that:
A nodachi against plate armor deals (before damage modifiers from crit): 0 bashing (5 - 8 < 0), 42 cutting (50-(11*0.75)=50-8). 76%
A war hammer against same plate: 12 bashing (20-8), 11 piercing (20 - (16*0.8*0.66)) = 23 total. 58%
In the "one hit" version:
Nodachi: bashing multiplier 50%, cutting multiplier: (16-5)/16*75%=52%. Nodachi ignores ~50% armor, deals 55-8=47, which is 85% of initial damage.
War hammer: Bashing at multiplier 50%, piercing at 53%. War hammer ignores ~50% armor, deals 40-8=32, which is 80% of initial damage.

From the change:
Nodachi would gain +9% damage against plate on regular hits, +9% damage on crits
War hammer would gain +38% damage against plate on regular hits, +22% on crits

While nodachi still ends up more powerful here, it gains less than the war hammer. Later we could adjust all armors to the new power levels. Then nodachi would become less good at armor piercing than dedicated armor piercing weapons.

tl;dr Deal whole attack as one against armor, instead of splitting it up into two and applying armor against each

The characters can wear underpants over pants, Superman style. For underpants this is no big deal, but then there are hoodies, backpacks, holsters etc.
There is no penalty for this behavior. You can acquire a gun through pants (regular holster, not some holdout variant), sneak a whole full duffel bag (two, no FOUR duffel bags!) inside a hazmat suit, wear a t-shirt over plate armor.

The problem, apart from the obvious muh realism stuff, is that it is optimal to shuffle around gear to keep stuff from getting damaged. This can get tedious early on, before you craft a whole set of indestructible armor.

Currently we have the following ranged skills:
  • Marksmanship
  • Pistol
  • SMG
  • Rifle
  • Shotgun
  • Launchers
  • Archery
  • Throwing (not exactly a ranged weapon skill, but shares a role)

8 ranged skills is way too many.
This results in the following problems:

  • Pigeonholing, like with the crossbows or miniguns, is more jarring than if the categories weren't so strict.
  • Total separation of most firearm learning. Is hunting rifle all that different from a shotgun loaded with slugs? I'm certain shotgun is more similar to rifle than rifle to minigun.
  • Arbitrarily solved edge cases. Like that rivtech shotgun which is a pistol due to small size.
  • Weapon balance suffers. Some of the weapon types have only limited uses and simply can't compete for XP with the better ones.
  • Weapon skill gain for some types is cheap (laser rifles/pistols, pneumatic rifle), while others are permanently kept low due to expensive ammo (shotguns).
  • Heavily modded weapons retain their categories, even after the addition of stock and burst fire turns a pistol into SMG except by name and type.

The heavily specific categories are necessarily arbitrary at the edges, as not every gun fits neatly into exactly one of the categories. On a side note, the same problem exists in real life, with legislature.

Some ideas of fixing those problems without introducing worse ones:
  • Rifle and shotgun merged. This is pretty much a no-brainer, the only reason not to do that would be doing a different skill merge.
  • SMG merged into either rifle or pistol. Merging into pistol would be better for balance, but rifle would probably be more muh realism, considering SMG is classified as a long arm.
  • Caliber based: pistols and SMGs merged into small guns, rest of firearms into big guns, launchers merged with archery into misc guns. Sci-fi guns possibly as a new category.
  • Drop all skills and keep just marksmanship.
  • Total rework of ranged skills. Instead of weapon type, different skills cover: accuracy at perfect aim, starting accuracy before aiming, aiming speed, and recoil control.

The Lab - Contributions and Mods / Coolthulhu's patches
« on: July 22, 2017, 07:34:50 PM »
Newest versions always available at:

Changes from current master:

Most important changes:
  • Normal distribution ranged accuracy math - compared to current master, it makes sniping requirements much more sane and prevents reaching insane levels of accuracy
  • Getting hit in a mending limb for 0 damage won't reset the mending process
  • Allows using jacks stored in non-adjacent vehicle trunks
  • Includes BrettDong's "NO_CBM_PAINKILLERS" mod -
  • Buff UPS charger (drop the 10x cost multiplier to 2x), allow setting multiplier in json
  • Add stripped-down version of tungn's No Silly Items mod. Unlike the full version, it doesn't blacklist any guns, as most of those are covered by No Fictional Weapons mod

In this post I'll call old batteries, the ones that can be divided and merged freely, "pool batteries" (as in, "battery pool"), and the discrete batteries that have a charge (for example, vehicle batteries) "magazine batteries".

The vehicle battery compartment mod is supposed to be a step on the eventual migration of all tools to batteries.
The migration could possibly even happen now, as it isn't really a new feature, just a json tweak.

We probably don't want it right now. Mostly because of the stable version being stabilized, but also because of the issues it would cause even if executed with no bugs:
  • Existing battery migration - loaded tools could just get a battery for free, but there might be edge cases, harder to solve. Piles of pool batteries would need to be converted into piles of magazine batteries in some unspecified way (randomly, based on pool size or something else).
  • Lost granularity - each tool would need to allow only batteries of specific sizes, meaning we'd need "heavy duty batteries" for welders and those batteries would not fit in smaller tools.
  • More keypresses for each reload - you couldn't just reload with any battery, you'd need to pick one
  • Double battery capacity toolmod gone - would need to be replaced by oversized battery compartment mod
  • Mod compatibility
  • NPC AI would need some fixes
  • Some battery-using recipes would need to be reworked

Which ones are MUST FIX before the migration?
Do we want it fast or do we want it well done? Or maybe not at all?

The hidden health stat is supposed to represent immune system function, toxicity of diet, ability of the body to deal with hardships and so on.
It is the difference between eating salads from fresh vegetables, and eating deep fried lard, chasing it with coke and popping a multivitamin to meet the daily requirements.

The problem is, it is mostly random, barely affected by diet. A lucky meth addict can feasibly end up healthier than an unlucky health nut who somehow manages to find fresh fruit all year long.
A stack of apples a day won't keep the doctor away, unless you're really good at throwing them.
Related issue: - tl;dr the randomness is so strong that it looked like there is a bug that caused health from food to have an effect opposite to the intended one.
Trying to work around this requires gorging on the fruit past satiety, accelerated metabolism or some sort of bulimia.

To fix this, we'd need some sample diets and expected health ranges for them.
Simple ones would work best. For example, diet of potato chips and energy drinks (nothing else) resulting in health in range of [-20, -50] after 14 days, and diet of cranberries and mineral water giving range of [50, 100] after a month.
Alternatively, someone to crunch the math and provide a bunch of plots for how could it look.

Health is in range [-200, 200], but values below -150 and above 150 should probably be reserved to hardcore abuse (advanced alcoholism, faulty bionic) and strict health fanaticism respectively.

Food morale stacking is an old problem. A single food item means nothing (+5 morale is nothing), a whole stack of those is like +15 which is less than music, but you can drink 10 different alcohols for +300 morale.
The stacking needs to be weaker. Bonus points if we also get non-stacked food morale to matter.

One thing that is NOT a solution is making the character bored of food for a long time (longer than one day). This would do nothing against stacking and only prevent the more natural bonus from "I ate a good meal today" effect.

I'm thinking something like penalizing multiple morale effects of the same sign:
Highest morale effect applied with no penalty, second one at 75% effect, third 50%, fourth 25% and the rest would be dropped. Or some other stepdown (square root? linear division?).
That way good meal, good drink and music would stack, but nibbling on 10 types of junk food wouldn't.

Possible additions (not solutions on their own):
  • Could apply only to same morale categories: food would not stack well with food, books would not stack with books, but food+books would stack without penalties
  • Dropping alcohol fun and turning most of it into fun from being drunk (rather than fun of drinking alcohol). Nice wines would still give the taste bonus, but washing down cheap fruit wine with moonshine wouldn't help.
  • Same as above for other drugs. In the category stacking system, all drugs would have a "chemical" category, so that heroin+alcohol wouldn't stack perfectly

I compiled a list of easy tasks that need doing:

Mostly json stuff, no compilation required.


Supporting that Lua interface takes far more work than porting all the known Lua scripts to C++ and supporting that.

How many mods actually make use of that Lua interface? How extensively?

Adding something for zombies to say could be a lot of flavor for relatively little work. And it would be easy to contribute more - just json text.
The only problems from the code side would be making zombies not aggro at each others' sounds (except calls for help) and not spam the message box with zombie conversations about brains while player is trying to read the important combat messages. I know relatively good solutions to both, so let's just keep this thread about theming.

Do we want the zombies to talk?
Having zombies occasionally say human stuff while not seeing player around would betray their position in a more flavorful way than having them stumble around loudly all the time.
Typical idle zombie stuff could be just muffled phrases people say to no one in particular ("where did I put...", "what was I doing?", "cold here", "when we eatin'?"), dialogue with people who don't exist ("of course, you see...", "can you turn up the heat?"), mixed with some less normal themes ("lost my eye", "need to murder neighbor").
Aggroed zombies would say different things: sound angry ("I'll fuck you up!", "get out now!"), scared ("mommy help!", "what did I do to you?", "he has a gun!") even while attacking relentlessly, accuse player of being a zombie ("it's one of THEM!", "she just bit me!"), or even sound more friendly than hostile ("excuse me, what's the time?", "hey there sexy", "yo, hold up!")
No actual conversations because that's too hard to implement.
Probably without any simulated muffling. After all, NPCs can speak perfectly clear through gas masks and mi-go parroting likewise can be understood at great range, in the middle of gunfight, by a semi-deaf gunner. It would not make much sense to have zombies say "brainsh" when an illiterate, drugged up mutant with mouth tentacles and a gas mask speaks perfectly clear English. Cutting start/end would be better than muffling.

But talking zombies would be rather weird. We could just have them make sounds: moan, groan, bang their chests (hulks need to do that), gurgle and scream.
Screaming zombies that occasionally say something would also work.

Then there is the third option: zombies as "death from the stars". Just alien entities, no human behaviors left, more machines than animals. Those would only shriek if their role is shrieking.

Our current melee system is pretty simple: when you attack, you attack with currently wielded weapon. Then you get bonus attacks due to mutations (if you have them).

How about this:
  • When attacking, game enumerates all possible attacks
  • Some of them are pretty weak most of the time: headbutts, elbow strikes, pistol whips
  • The attacks get some random permutation to accuracy/expected damage every time
  • The effectiveness of attacks is evaluated based on enemy (for example, armor is subtracted from damage)
  • Attacks are weighted somehow: usually just by DPS, but sometimes by being finishing strikes (dropping monster to 0 hp or less) or special effects
  • Best one is picked and executed

The advantages are:
  • Natural execution of ideas like kicks, weird martial art tricks and so on
  • Sensible dual wielding: not double damage at extra move cost or anything, just more opportunities for attacks
  • When wielding an unwieldy item (tank full of water), you no longer become very vulnerable - you can now kick and maybe even bite
  • Mutations don't need to grant extra attacks, just modify existing ones (beak is just mutant bite, horn headbutt is just mutant headbutt, claw strike is just human scratch turned not-useless)
  • Naturally extends to multiple attacks per weapon, such as haft strikes and halberd chop/thrust/hook
  • One-handed weapons have the advantage of keeping a hand free for off-hand strikes

Disadvantages are:
  • Complexity in implementation
  • Complexity in understanding without a good UI showing all the chances

DF has something relatively similar.

Worth the effort?
Of course this is a post-0.D idea, there is no way it is going to be in this stable.

The current mutation system: is grindy, is only really accessible in the "endgame" (except for genetic chaos mutants), breaks the balance of traits vs stats (not THAT important in multi-pool, but still), and ignores the whole set of point values already written for mutations.

My idea of a fix is:
Mutation choice being affected by how good you are already.

Rough idea of algorithm:

First, we want to find the "intended mutation score":
  • Sum point values of traits and mutations player has
  • Add stats to that
  • Add mutagen quality to that
  • Subtract some value representing average character (sum of stats + sum of traits you can get in a typical start)

  • Generate some mutation sets by copying the current mutation list and adding and removing random (available) mutations to it
  • Rate the mutation sets in similar way to the rating for player
  • Randomly pick one set, preferring those rated closest to "preferred mutation score"
  • Mutate towards this set

As a result:
  • Mutagen quality becomes an easy to understand setting, allowing adding cheap mutagens (that mostly suck) and rare designer mutant ones that grinders grind towards
  • Can add targeted mutagens without upsetting the balance, by simply having them require a mutation set with specific mutation in it
  • Mutants become as balanced as mutation point scores allow. This of course would mean buffing (or giving huge negative scores to) shit mutations before it goes fully live.
  • Getting a bad mutation stops being an "ah shit, purify time" moment, since the point score means it is just a high-risk-high-reward thing (rather than high-chance-to-drink-purifier one)
  • Starts become more balanced against each other. Could need some defense mechanism against pure skill starts, which would become pretty great under this mechanic

Point score isn't the most realistic thing out there, but neither are perfect creatures immune to disease, damage, pain, poison and so on.
IRL everything is about tradeoffs: if you're strong you need to eat more (bears sleep through winter, elephants eat all day), if you move fast you either eat a lot or are very light, if you resist poison your metabolism is impaired in some way to allow going around that poison. The requirement system for mutations (need herbivore for grazer etc.) is too specific to catch such tradeoffs, so a gamey point system will most likely do a better job at also being realistic.

I'm thinking:
  • Grafts - NPC doc action only. Not sure about effects.
  • Mutagen sci-fi magic - acquire mutations (weighted slightly towards negative) but also unbreak limbs. Good for early game characters who don't mind mutating but need to unbreak limbs, while bad for late game designer mutants.
  • Install specific CBM on limb - instantly heals limb to full, but takes slots until removed and sets HP back to 0 on removal. Could have more effects - some desirable, some not
  • Advanced medkit (nanobots or other sci-fi) - rare and uncraftable, but unbreaks (one? all?) limbs
  • Power armor/exoskeleton - doesn't unbreak the limb, but for as long as it is working, allows treated all limbs as unbroken (with some penalty)

Pages: [1] 2 3 4