NEO Scavenger Modding Documentation

117 posts / 0 new
Last post
NEO Scavenger Modding Documentation

The NEO Scavenger XML file is pretty daunting, so I've added some documentation here to explain the various fields.

Layarion (mod author behind Overhaul and Devkit), has also created a really comprehensive guide here!

How IDs Work

Spoiler: Highlight to view
Parts of an ID:


  • AA - The ID of the data set we're loading from
  • BB - The ID of the thing we want in that data set
  • CC - The optional subgroup ID of the thing we want (for items that have IDs like BB.CC)

Most data within NEO Scavenger is referred to by an ID. The condition for "Hungry" is condition ID 5, the "dogman" is creature ID 1, and the opening cryo encounter is encounter ID 2. There are even a few complex IDs, such as items. E.g. the "medium branch" item is ID 13.0, 13 for the group ID, and 0 for the subgroup ID.

Everything in the game uses these IDs when referring to other things. So if a dogman has "strong" as a starting condition, the creature data for the dogman specifies "60" as a starting condition.

However, these IDs can become a problem if other mods or the base game use the same ID for something different. For example, what if you have a mod that includes a car tire with ID "13.0"? The base game has "13.0" set to a medium branch, so if you mention "13.0" in your mod, the game needs to know which "13.0" you want. Base game version or the mod version?

That's where prefixes come in (the AA: above). You can specify which data set you mean before the ID by prefixing the ID with the data set's ID and a colon. If no prefix is specified, the game will assume you mean the version in the current mod you're editing. Otherwise, it will assume you mean the version in the mod you specify.

E.g. itemID=13.0 will reference this mod's copy of 13.0

If a mod wants to reference the base game data, it must specify mod "0".

E.g. itemID=0:13.0 will reference base data's copy of 13.0

And if a modder wants to reference another mod, just replace "0" with that mod's name.

E.g. itemID=DeFactoMod:13.0 will reference DeFactoMod's copy of 13.0

The benefit to a system like this is that modders can each use whatever IDs they want without worrying about whether another mod will conflict. The game will just sort everything out behind the scenes, as long as the AA: prefix is there when needed.


Spoiler: Highlight to view
Encounters are probably the most complex data type in the game, and much of that complexity comes from the way encounters flow from one to the other.

Conceptually, it's easiest to think of encounters as nodes connected by arrows. Like a flowchart. This is an example of what the encounter editor looks like:


Before anyone asks, the editor won't do you any good. It doesn't read XML files. Instead, it reads data from a mySQL database running on a local server. I just export the database into XML format because most modders don't have a database running on a server they can use.

Though, if tech-savvy modders are able to setup a database...

Anyway, as you can see above, encounters are gray "nodes" connected by colored arrows. In the XML file, an encounter consists of one of those gray boxes, and all outgoing arrows.

All encounters have the following fields (* are required):

  • id* - The unique ID for this encounter (easiest to just add 1 to the previous highest number)
  • strName* - Shows up as yellow text if the player has a choice of inputs. Invisible if not.
  • strDesc* - The main text. The longest text I've got in one encounter panel is about 130 words. Probably 150 is the limit that will fit on-screen in the game. Longer text needs to be split into subsequent panels (no-choice arrows), so it's better to break them up if they're getting long.
  • strImg - The image to display for the panel. Not specifying a picture defaults to a snapshot of the current hex (like battle).
  • nItemsID - The special encounter items available in this panel. This is stuff like the broken cryo window or control panel, which only exist in the context of the encounter. Regular items and skills in the player's possession are added automatically in-game based on the possible outcomes, and only if the player has them.
  • nTreasureID - Loot to give to the player in this panel. Used for quest items, rewards, etc. Indexes into the treasuretables.
  • nRemoveTreasureID - Items to remove from the player in this panel (usually turning in quest items, but could be lost/broken items, etc.). Indexes into the treasuretables.
  • aPreConditions - Player conditions that must be present for this encounter to be valid. If the player is missing the requisite condition, this panel will not appear. This is often used in conversations to separate initial conversations from follow-up conversations. It can also be used to hide/show certain panels based on skills or present items. E.g. player must have cholera to see this node, or player must not have visited DMC yet to see this node, etc. Comma-separated list of IDs of conditions. Putting a "-" before a condition ID means this condition must not be on the player to trigger.
  • aConditions - Player conditions this panel applies or removes when done. (E.g. injury, flags denoting a conversation was had, etc.) Comma-separated list of IDs of conditions. Putting a "-" before a condition ID means this condition will be removed.
  • fPrice - The amount of money deducted when reaching this node. If player does not have enough money, node is not shown.
  • nCreatureID - The ID of the creature spawn group this panel spawns. E.g. spawn dogman when exiting cryo. (Currently, these IDs are hidden in code. I need to break them out of code at some point.)
  • ptCreatureHex - The hex coordinates where the creature will appear, if applicable. E.g. "40,0" is (radius, direction), and spawns the creature 40 hex rows (radius) due north (direction). Direction is 0-based hexes clockwise from north in the destination hex ring. So hex ring radius 0 is the current hex, radius 1 is the 6 hexes around that, 2 is the 12 around that, etc.
  • ptTeleport - The hex coordinates (radius, direction) where the player will be teleported to. Specifying X-only will randomly teleport the player in a ring of radius X. Uses same radius/direction spec as ptCreatureHex, above.
  • aMinimapHexes - The coordinates (map x,y) of a hex to reveal, with optional text label for map. Used in the Hatter urn quest, and the glow reveal. E.g. "20x164=Gyges Cryo Facility" reveals hex (20,164) with label "Gyges Cryo Facility."
  • bRemoveCreatures - Whether this panel removes creatures from the current hex or not. Useful for guaranteeing current hex is empty. 0 = false, 1 = true.
  • bRemoveUsed - Removes from player whichever item was used to reach this node. Useful when generic item types are used to reach a node, rather than specific items (e.g. any light source) 0 = false, 1 = true.
  • nType - Whether this is a normal encounter or not. Encounter types include normal (0), scavenge (1), battle (2), and hacking (3).
  • fLootChance - The change in loot chance this panel creates, if chosen in a scavenge encounter. 0.0 = 0%, 1.0 = 100%.
  • fAccidentChance - The change in accident chance this panel creates, if chosen in a scavenge encounter. 0.0 = 0%, 1.0 = 100%.
  • fCreatureChance - The change in creature chance this panel creates, if chosen in a scavenge encounter. 0.0 = 0%, 1.0 = 100%.
  • vAccidents - A list of accidents to choose from if this scavenge encounter produces an accident. Comma-separated IDs for encounters.
  • vLoot - Additional loot added to regular scavenge loot if this option is chosen in a scavenge encounter. Comma-separated IDs which are indices for the treasuretables.
  • ptEditor - The in-editor coordinates of the node. Ignored by game.

aResponses warrant special mention, since they are pretty complicated and also important. These are basically the arrows seen in the image above, and control which encounters one can reach from here, and how.

The format is a series of formulae separated by commas. A formula looks like this:



  • AA - The nGroupID of the required item
  • BB - The nSubGroupID of the required item
  • CC - The number of AA.BB items required.
  • DD - The ID of the encounter this choice results in.
  • EE - The chance of this outcome happening. 1.0 = 100%, 0.0 = 0%. (Used in cases where more than one outcome is possible at the same time. The total chance of all valid outcomes for a set of input items must be 1.0.)
  • FF - The number of "per-use" charges consumed.
  • GG - The number of "per-hour" charges consumed.
  • HH - The number of "per-hex" charges consumed.

Some examples:

  • =1x1x0x0x0 - If no inputs are specified, go to encounter 1 (blank, which ends the encounter), 100% chance, 0 charges used.
  • =16x1x0x0x0,=3x1x0x0x0 - If no inputs are specified, go to encounter 16 or 3, depending on which one is valid. 100% chance and 0 charges used, either way.
  • 90.3x1=20x1x0x0x0,90.4x1=1320x1x0x0x0,=7x1x0x0x0 - If one item 90.3 is used, go to encounter 20. If one 90.4 is used, go to encounter 1320. If nothing is used, go to 7.
  • 86.0x5+46.0x1=1037x1x0x0x0 - If five 86.0s and one 46.0 are used, go to encounter 1037.
  • 49x1=930x1x0x1x0 - If you omit the ".BB" in the formula, the game will think you're asking for an ingredient rather than a specific item. In this case, #49 is "handheld lightsource," and will result in encounter 930 with 1 "per-hour" charge deducted.

There are lots of tricks that I've learned in this system, and too much for me to get into right now. But you can do things like =AAx1x0x0x0 where AA is the ID of the current encounter, and this will cause the encounter to point back to itself. This is useful for forcing the player to make a choice, as the encounter will end if no choice is valid.

Battle Moves

Spoiler: Highlight to view

BattleMoves are the data type that control what combatants can do during any given combat turn. They include not only attacking with the wielded weapon, but also movement, surrender, exiting battle, talking, and special moves. If it happens during battle, it needs a BattleMove.

  • id - unique ID
  • strID - item ID used to display this move (e.g. 90.33 = green crosshair icon)
  • strName - name of battle move
  • strNotes - unused in-game. notes to myself.
  • strSuccess - message displayed if succeeded. <us> gets auto-replaced with actor's name, <them> is recipient
  • strFail - message displayed if failed. <us> gets auto-replaced with actor's name, <them> is recipient
  • strPopUp - pop-up/tooltip text
  • vChanceType - type of random check (see below) to make when checking if the overall move succeeds
  • vUsConditions - list of conditions and random checks (see below) this applies to us if we succeed
  • vThemConditions - list of conditions and random checks (see below) this applies to them if we succeed
  • vPairConditions - list of conditions and random checks (see below) this applies to the pair if we succeed (e.g. range changes require a pair to operate on, as "us" is meaningless without someone to change range against)
  • vUsFailConditions - same as vUsConditions above, except this is for the fail case
  • vThemFailConditions - same as vThemFailConditions above, except this is for the fail case
  • vPairFailConditions - same as vPairFailConditions above, except this is for the fail case
  • vUsPreConditions - list of conditions we must have (or not have) for this move to be available
  • vThemPreConditions - list of conditions they must have (or not have) for this move to be available
  • nSeeThem - 0=can only do this if they are unseen, 1=seen, 2=doesn't matter
  • nSeeUs - 0=can only do this if we are unseen, 1=seen, 2=doesn't matter
  • bAllOutOfRange - 1=can only do this if all hostiles are beyond their attack ranges, 0=doesn't matter
  • bInAttackRange - 1=can only do this if we are in our attack range, 0=doesn't matter
  • nMinCharges - minimum # charges we must have for current attack mode (if any)
  • nMinRange - minimum range we can use this move
  • nMaxRange - maximum range we can use this move
  • nAttackModeType - 0=melee, 1=ranged, -1=any
  • vHexTypes - list of hex types in which this move is available. empty=all
  • fChance - chance of this move appearing if above conditions are met. 1.0 = 100%
  • fPriority - priority of this move compared to other moves. AI will prefer higher priorities over lower.
  • fDetect - chance of this move revealing us (multiplier against normal chance)
  • fOrder - order in which this move is executed in a turn. 0.0 happens sooner than 1.0
  • fFatigue - amount of fatigue this move costs
  • bApproach - used by AI to tell if this move will approach target. 0=no, 1=yes
  • bOffense - used by AI to tell if this move will attack target. 0=no, 1=yes
  • bFallBack - used by AI to tell if this move will fall back from target. 0=no, 1=yes
  • bRetreat - used by AI to tell if this move will retreat battle. 0=no, 1=yes
  • bPosition - used by AI to tell if this move will stay put/prepare. 0=no, 1=yes
  • bPassive - used by AI to tell if this move is passive/non-combat (e.g. talking). 0=no, 1=yes

Random Checks

A random check can be one of several types, but they all follow the same format:


or if the field supports a list of more than one type:



  • nCondition is the condition ID that gets applied if chance passes
  • nCheckType is the ID for the type of check to make (see below)
  • fChance is a parameter passed into the check type specified (usually a chance or chance modifier)

and the nCheckType IDs are:

  • =happens no matter what
  • =requires a melee attack roll to happen
  • =requires a ranged attack roll to happen
  • =requires a terrain trip roll to happen
  • =requires a terrain trip roll to happen (modified by next term, e.g. 2.0 is double chance)
  • =requires a morale check to happen
  • =requires a flat probability to happen (specified in next parameter)
  • =requires an escape check to happen

Item Group IDs

Spoiler: Highlight to view

An item's nGroupID can be important for some item types, but most can be anything. The nGroupIDs to watch out for are:

7, //headlines
8, //hardware
9, //recipe scrap
12, //camps
20, //crippled (e.g. blocks hands if arm crippled)
25, //terrain resource (e.g. forest, lake, power tap)
26, //camp fixture (e.g. HVAC, light)
36, //datafiles
90, //encounter item (e.g. cryo console, cryo window)
91, //skill
96, //trait
103 //scavenge location

weapons can be anything, as can clothes.

Item Slot Info - Complete list of slot IDs and properties. Also includes wound slot IDs and props. Covers things like aPossessConditions, aUseConditions, vEquipSlots, vUseSlots, and maybe some others. Especially wounds.

Condensed List of properties - Complete lists of ingredient, item property, container IDs, aFieldNames, and aEffects for reference.

Complete List of Item nGroupIDs - Complete list of nGroupIDs for items.

Item Field and Misc Info - Includes some creature field and attackmode talk.

Creature Fields - Details the complete list of creature fields and functions, for AI, player, and shared fields. As well as Condition effects.

Conditions Info

Spoiler: Highlight to view
Conditions can be assigned as a result of encounters, battlemoves, attackmodes (on attacker only), entering a hex (vCondIDs), and using/equipping/carrying items.

There are also a few fields there which can be used to control conditions on creatures. In particular:

SetPlayerCondition (for AI creatures.)
TriggerEncounter AI can have encounters trigger on them, too.)
SetImmunity (prevent certain conditions on a creature)

Condition durations/removal are controlled primarily by:
fDuration - duration in hours (if > 0 condition disappears when expired, if 0 condition remains until removed manually)
bResetTimer - condition duration reset if stacked
bRemoveAll - removing one from stack removes all
bRemovePostCombat - stripped when exiting battle
bStackable - controls whether effects increment when more than one copy applied. a condition's stack must reach 0 before disappearing from creature, unless timer or bRemoveAll say otherwise

bPermanent - this one's tricky, as it actually means the effects are permanent, not the condition. I.e. the condition's effects are applied, and then no record of the condition is maintained (so it can never be removed without applying an opposite effect later).

Understanding Hex Map Coordinates

Spoiler: Highlight to view
The x and y coordinates on the map can be a bit tricky to figure out, so I created this visual aid way back:

Note that the y values increase by 2 each full hex height, with each column having either odd or even y values, not both. And the x coordinate is shared by two staggered columns.

In game terms, the distance between two hexes is usually calculated as the number of moves to reach the new hex from the old one, not the x and y coordinate differences.

In the above image, a radius of 2 hexes from the player would include:
Outer ring:

  • 1,4
  • 1,3
  • 2,4
  • 2,5
  • 2,7
  • 2,9
  • 2,10
  • 1,11
  • 1,10
  • 0,9
  • 0,7
  • 0,5

...and all hexes within that.

Encounter Triggers

An important note to remember is that triggers are only added at the beginning of a game. If you add new encountertriggers to your mod, you will not see them in old save games!

More info soon!

Dan Fedor - Founder, Blue Bottle Games

Will this apply to the Mac OSX version of the game on steam?

I am that low life scum that hunts down a scavenger, laughs as he tries to surrender, beats him to death with my club, and eats his gummy bears before moving onto the next sucker.

This should technically apply to all versions: Win, Mac, and Linux. And is currently available on Steam and this site. If no problems are discovered before the next version is released, I'll be updating Humble Bundle's site and Desura with moddable versions, too.

Dan Fedor - Founder, Blue Bottle Games

I'm so glad ptEditor doesn't do anything to the game, you don't know how I've been worrying about that. I came up with these wild ideas that maybe it's some kinda pointer thing to memory addresses and I'm gonna garble up all sorts of funny variables or something. Love the tutorial man, that is gonna help this newb modder out plenty.


Can I ask how the scavenging works with fLootChance? So, the scavenging encounter refers to a treasure table (vloot), which has it's own probabilities. How does fLootChance modify what/how much the player receives from the treasure table?

I could be wrong, but I think if you have 0.5 fLootChance, you have a 50% chance that you get the additional loot listed in vLoot


fLootChance is one of two things:

1 - On a scavenge location, it represents the base loot chance for that location if nothing else happens.
2 - For a scavenge option (like using crowbars), it is the modifier to the base location chance.

E.g. if the ruined apartment had fLootChance=0.5, and it had an optional encounter for using crowbars with fLootChance=0.25, the base chance when scavenging that location would be 50%, and a crowbar would make it 75%.

Dan Fedor - Founder, Blue Bottle Games

Am I understanding this correctly?

In the encounter table I'm the aPreConditions, I use stuff like this alot -393,-591,606

does it mean if the player does NOT have the first 2 conditions (-393,-591) and DOES have the last condition (606)?

can I use it that way?


How do I make this attackmode table stun the enemy and not the player? lol using the condition 145 to stun, or is there a way to stun an enemy using a new condition?

Spoiler: Highlight to view
<table name="attackmodes"> <column name="id">62</column> <column name="strName">taser</column> <column name="nRange">1</column> <column name="fDamageCut">0.2</column> <column name="fDamageBlunt">0.2</column> <column name="strChargeProfiles">32</column> <column name="nPenetration">0</column> <column name="nType">0</column> <column name="strSnd">cueLaser</column> <column name="bTransfer">0</column> <column name="vAttackerConditions">211x1.0,145x1.0</column> <column name="strIMG">AModeTaser.png</column> <column name="fMorale">0.05</column> <column name="strWieldPhrase">ready to taser</column> <column name="vAttackPhrases">tasers</column> </table> <table name="conditions"> <column name="id">145</column> <column name="strName">Stunned</column> <column name="strDesc">&lt;us&gt; is stunned and unable to move for a moment.</column> <column name="aFieldNames">m_fMorale</column> <column name="aModifiers">-0.3</column> <column name="aEffects"></column> <column name="bFatal">0</column> <column name="vIDNext">0</column> <column name="fDuration">0.011</column> <column name="bPermanent">0</column> <column name="vChanceNext">0</column> <column name="bStackable">0</column> <column name="bDisplay">1</column> <column name="bDisplayOther">1</column> <column name="nColor">1</column> <column name="bResetTimer">1</column> <column name="bRemoveAll">1</column> <column name="bRemovePostCombat">1</column> </table>

Also if I could make a new condition with different fieldnames, is there also a field name that would have a small chance of making an enemy unconscious?


Here's the list of item vProperties in a more compressed list for quick reference easy viewing. You can already find them in the ((itemprops)) section though.

Spoiler: Highlight to view
01 - easily ignitable
02 - optical zoom
03 - igniter
04 - tannin source
05 - tool: philip's head screwdriver
06 - tool: flathead screwdriver
07 - water purifier
08 - container
09 - waterproof
10 - fireproof
11 - hot
12 - meat
13 - shaft
14 - nourishing
15 - small
16 - medium
17 - large
18 - sharp point
19 - thread
20 - furry
21 - sharp edge
22 - corpse
23 - skill: trapping
24 - biohazard
25 - radioactive
26 - poison
27 - liquid
28 - rigid
29 - hydrator
30 - .308 rifle
31 - mechanical parts
32 - monocular
33 - binocular
34 - skill: lockpicking
35 - ash
36 - sheet
37 - absorbant
38 - disinfectant
39 - infinite
40 - forest
41 - skill: mechanic
42 - hvac (unheated)
43 - electrical panel
44 - skill: electrician
45 - tool: lever grip/pliers
46 - fire fuel
47 - quality
48 - solid (not liquid/gas/idea)
49 - light source
50 - handheld
51 - skill: ranged
52 - crowbar
53 - caster wheel
54 - basket
55 - shopping cart frame
56 - water
57 - skill: botany
58 - brittle
59 - compound bow
60 - flexible/springy
61 - 12 - gauge shotgun
62 - dogman
63 - any combat skill
64 - night vision
65 - very large
66 - raw
67 - cured
68 - strapped
69 - iSlab
70 - human
71 - tool: water analyzer
72 - identified
73 - stuff Radiation Bob wants (big)
74 - stuff Radiation Bob wants (small)
75 - stuff Zom Zom's wants
76 - ignore in crafting screen
77 - AI never loots
78 - AI never loots when player present
79 - smartphone
80 - SBS4 rifle
81 - ignore in quick recipes
82 - degrades silently when used


Sorry for the delay. Didn't check forums this weekend!

Re: aPreConditions, the encounter will not appear if any of those conditions don't fit. E.g. if you have -393,-591,606 in the encounter, the player cannot have 393 nor 591, and must have 606 to trigger the encounter. If any of those don't match, no trigger.

As for attackmode stun, currently the only way attackmodes stun is via lots of damage in a single attack (like guns, ATN club, etc.). I don't have a way to make the a weapon deliver a condition to the target. I'd like to add this some day, though.

However, battlemoves can add conditions to the target. So if your weapon provides a special battlemove, that could work. It's a bit kludgy, but it's how things like kick can stun an opponent. Ideally, though, attackmodes would support conditions, and I have yet to fix that.

If you want to make someone unconscious in the game, the one way is to deliver a lot of pain to them. Below a certain threshold, the creature will go into shock (unconscious). Another way would be to do some combo of increasing sleep comfort and tiredness, and then applying the unconscious condition. The first two will help the creature stay down, otherwise it'll wake right back up again.

Adding a taser is something I've been postponing for a while, namely because of the roadblocks you're running into :)

Thanks for the vProperty summary, Bloc97!

Dan Fedor - Founder, Blue Bottle Games

aah sweet thanks :D mmm ! when you get a chance could you lemme know how the conditions in the battlemove table works?

Spoiler: Highlight to view
<column name="vChanceType">0,0,0</column> <column name="vUsConditions">[155,0,0],[339,0,0]</column> <column name="vThemConditions"></column> <column name="vPairConditions">[209,0,0],[159,4,0.5]</column> <column name="vUsFailConditions"></column> <column name="vThemFailConditions"></column> <column name="vPairFailConditions"></column> <column name="vUsPreConditions">137,151,-143,-144,-148,-145,-146,-192,-367,-390</column> <column name="vThemPreConditions"></column>


Ooh, that's a good question! I'll add that to the OP now.

Dan Fedor - Founder, Blue Bottle Games

w00! <3 thanks!


I've seen this used alot in treasuretables : 21.6x0.3x1-2|46.1x0.3x1-1

does | mean or? or and?

and can I use it here like so?
<column name="vUsPreConditions">-188,-158,-144,-148,-145,-146,[color=lightgreen]580|110[/color]</column>


Also, is there a vEquipSlots number for belts?


Yep! "|" is used for "or." Unfortunately, that only works in treasuretables. For lists of conditions, it's all or nothing. No "or" logic supported. I'd like to have that someday, but I've mainly worked around it in other ways (clever combos of +/- preconditions).

And yes, the "belt" slot is ID=12.

Dan Fedor - Founder, Blue Bottle Games

sweet thanks!


<column name="vImageUsage">0,0,0,0,0,0</column>

how does imageusage work?


That one's a bit tricky. It's a list of which images to use in which situations. The number is the 0-based index into the list of available images for that item.

So if you have this as your vImageList:

0 is the first image (ItmWorkBoot.png), and 1 is the next (ItmWorkBootStored.png)

The vImageUsage for this boot item is:

Which is saying to use the second image (1) in all cases except the middle two situations. Use the first image (0) in the middle two.

As for the list of situations, they are as follows (in order from left to right)


So the above boot example is using the "stored" version of the image in all cases except when the boot is equipped.

Dan Fedor - Founder, Blue Bottle Games

Awesome! thanks for clearing that up for me, I was really confused with that


I am interested in how the 'Laser Eye Surgery' works, how the coding related to the Myopia trait is related to the coding for the Surgery from the Double H. How do they go together, and what would need to be done to create coding to make a means to remove the Insomnia trait by having the trait become struck out. EmperorZA has created a way of removing Insomnia by adding a new skill, which works, but I was thinking that there would be a way to remove the trait directly, and that it might actually be slightly simpler to implement. Let me know.

Yeah, the game has a way of both adding and removing skills and traits. Condition ID 359 is a good place to start, if you're curious. "RemoveTrait" or any of the other add/remove methods each take a parameter corresponding to the nSubGroupID you want to affect.

E.g. to remove myopia, one would call RemoveTrait with parameter 0 (myopia is ID 96.0).

However, there's a trick in that most traits are also holding a valuable skill to the player. If someone takes myopia, it's usually because they want to fill it with a new skill. So taking myopia away will remove that skill, too.

Hence, eye surgery really just adds a new trait which removes myopia's effects. Namely, surgery is condition 356 and 357, the latter of which grants trait 96.6. Trait 96.6 has the same condition IDs as myopia, just negative, so it'll remove any conditions myopia added, and vice versa.

Dan Fedor - Founder, Blue Bottle Games

I see, same with nano-augmented eyes, the nano-augment negates myopia, allowing the added eagle eye to function normally. Makes sense.

Do you think it would be possible to code it to add a trait which was blank, called Myopia that is added as a trait, empty of associated skill, so that when removetrait for Myopia is called, the associate skill could move into the empty slot, thusly preserving the skill and simultaneously removing the trait, and adding an interesting skill slot, that shows Myopia has been removed.

I have a question out of curiosity, is it possible to have multiple images for the body in the equipment screen? and have a starting dialogue for choosing which body you want? like for example say (for arguements sake) I wanted to make a dragonball-Z mod where you start the game and choose either Vegeta, Goku or Picolo and then have that picture in the equipment screen?

(Or even a mod where you can choose your race/species)


@Aiden, that's something I wanted to do, but haven't had time to yet. Since the clunky way worked, I moved on to other things. I think it would be doable, though it may get more complex when skills and traits start to have different relative sizes/spaces.

E.g. the modder would need to make sure the newly-added trait had enough room for whatever was in the removed trait.

@EmperorZA, there isn't a way to do that at the moment. The game always loads the same paper doll images each game. They can be changed, of course, but it'll affect all characters. (E.g. a mod to play as a female, non-human, etc.)

In theory, it's possible to do what you're asking, but it'd take some development time to build.

I've added notes about both of these in the issue database.

Dan Fedor - Founder, Blue Bottle Games

@dcfedor, So it possible for you to make an update in the future that makes the player a different image than the rest, for modding sake?

*Raider sneaks up*
"No, stay the fuck away from my left shoe!"

I should probably make the player just another creature in the creatures table. That way, modders could change the sprite, starting conditions, and other stats. It could be a while before I'm able to do that, though.

In the meantime, however, you could probably do this by changing all the human NPCs to use a new sprite, and copy the current sprite image to the new filename. That way, when you edit the old sprite, it will only affect the player.

Dan Fedor - Founder, Blue Bottle Games

heya ;D in conditions I found an aEffects value like this... :

<column name="aEffects">AddItemGround=151,0,0,0;</column>

is there a modifier or effect that will add the item directly to the equipment slot? (mmm I know I'm probably sounding like a broken record, but I'm just hoping hehe


Sorry for the late reply! And unfortunately, no way to add directly to slots yet. The AddTrait and AddSkill versions work for their respective slot types, but the rest is stuck on the ground.

Dan Fedor - Founder, Blue Bottle Games

Hey, I'm trying to add my own creature to the game, I figured out how the factions and conditions work on it, I just need to know on how I can add them to the map like a looter or dogman. I saw something with 150x100 in the map files and they only have faction numbers in them, is this how you add things to the map? If not how can I?

Edit: Nvm, I figured it out.

*Raider sneaks up*
"No, stay the fuck away from my left shoe!"

There's actually a flaw in this system right now. Random creature spawns are controlled by a list that's hard-coded, so it's not possible to create a new spawn group via modding. I want to change that, though.

In the meantime, you should be able to replace existing creatures until I fix the system.

Dan Fedor - Founder, Blue Bottle Games

Well what I did was go into the EXE and into Datahandler, and implant my own. I figured out the syntax for it all and all I need to do is add things in a way so that it wont add another line

*Raider sneaks up*
"No, stay the fuck away from my left shoe!"

waht waht! 8q how do you do that? what program you use?


I used FFDEC, it's annoying as hell to use but it does the job.

*Raider sneaks up*
"No, stay the fuck away from my left shoe!"

can you use the same program to make a patch that does the exe modifying with FFDEC?


Yeah but you gotta grab some file so you can edit it directly in the EXE.

*Raider sneaks up*
"No, stay the fuck away from my left shoe!"

Is there a way to check on which line of the neogame.xml file the game stops loading?

I'm have an annoying error, I know its just a misplaced comma or something but I can't seem to find it :<

Edit: Question no.2 ;d

I made a new camp type ID 10 for "Resources" I wanted to make its contents *only* containertype 40 and make the resources format 40...
but when I try to craft resources it says there's no space to craft. However when I use containertype 16 (camp fixture) it works... however not to the desired effect because I can still move the crafted item between camp sites :/

Why does 16 work and the new containertype 40 not work?

Edit: here's the code I'm talking about, but its currently using containertype 16 to work

Spoiler: Highlight to view
<table name="camptypes"> <column name="id">10</column> <column name="strDesc">Location Resources</column> <column name="vImageList">ItmScavengeResources.png</column> <column name="aCapacities">30x30</column> <column name="nTreasureID">3</column> <column name="m_fAlertness">0</column> <column name="m_fVisibility">-0.05</column> <column name="WetTempAdjustMod">0</column> <column name="m_fHealPerHourMod">0</column> <column name="fSleepQuality">-0.26</column> </table> <table name="containertypes"> <column name="id">40</column> <column name="strName">resources</column> </table> <table name="itemtypes"> <column name="id">643</column> <column name="nGroupID">12</column> <column name="nSubgroupID">10</column> <column name="strName">camp site</column> <column name="strDesc">EmperorZA Location Resources</column> <column name="strDescAlt"></column> <column name="nCondID">1</column> <column name="vImageList">ItmScavengeResources.png</column> <column name="vSpriteList"></column> <column name="vImageUsage">0,0,0,0,0,0</column> <column name="fWeight">0</column> <column name="fMonetaryValue">0</column> <column name="fMonetaryValueAlt">0</column> <column name="fDurability">1</column> <column name="fDegradePerHour">0</column> <column name="fEquipDegradePerHour">0</column> <column name="fDegradePerUse">0</column> <column name="vDegradeTreasureIDs">3,3</column> <column name="aEquipConditions"></column> <column name="aPossessConditions"></column> <column name="aUseConditions"></column> <column name="aCapacities">30x30</column> <column name="vEquipSlots">208</column> <column name="vUseSlots"></column> <column name="bSocketLocked">1</column> <column name="vProperties"></column> <column name="aContentIDs">16</column> <column name="nFormatID">6</column> <column name="nTreasureID">0</column> <column name="nComponentID">3</column> <column name="bMirrored">0</column> <column name="nSlotDepth">0</column> <column name="strChargeProfiles"></column> <column name="aAttackModes"></column> <column name="nStackLimit">1</column> <column name="aSwitchIDs"></column> </table> <table name="itemtypes"> <column name="id">644</column> <column name="nGroupID">106</column> <column name="nSubgroupID">0</column> <column name="strName">EmperorZA Resource</column> <column name="strDesc">large branch from a tree</column> <column name="strDescAlt"></column> <column name="nCondID">1</column> <column name="vImageList">ItmRsrcWoodLBranchs.png</column> <column name="vSpriteList"></column> <column name="vImageUsage">0,0,0,0,0,0</column> <column name="fWeight">1.15</column> <column name="fMonetaryValue">0</column> <column name="fMonetaryValueAlt">0</column> <column name="fDurability">1</column> <column name="fDegradePerHour">0</column> <column name="fEquipDegradePerHour">0</column> <column name="fDegradePerUse">0</column> <column name="vDegradeTreasureIDs">3,3</column> <column name="aEquipConditions"></column> <column name="aPossessConditions"></column> <column name="aUseConditions"></column> <column name="aCapacities"></column> <column name="vEquipSlots"></column> <column name="vUseSlots"></column> <column name="bSocketLocked">0</column> <column name="vProperties">13,17,28,46,48,50,60</column> <column name="aContentIDs">703</column> <column name="nFormatID">16</column> <column name="nTreasureID">0</column> <column name="nComponentID">3</column> <column name="bMirrored">0</column> <column name="nSlotDepth">0</column> <column name="strChargeProfiles"></column> <column name="aAttackModes"></column> <column name="nStackLimit">999</column> <column name="aSwitchIDs"></column> </table> <table name="recipes"> <column name="nID">145</column> <column name="strName">Add to stockpile</column> <column name="strSecretName"></column> <column name="strTools"></column> <column name="strConsumed">1x101</column> <column name="strDestroyed"></column> <column name="nTreasureID">702</column> <column name="fHours">0</column> <column name="nReverse">1</column> <column name="nHiddenID">0</column> <column name="bIdentify">0</column> <column name="bTransferComponents">0</column> <column name="vAlsoTry"></column> <column name="nTempTreasureID">3</column> </table> <table name="treasuretable"> <column name="id">702</column> <column name="strName">Resource : Large Branch</column> <column name="aTreasures">106.0x1.0x1-1</column> <column name="bNested">0</column> <column name="bSuppress">0</column> <column name="bIdentify">0</column> </table> <table name="treasuretable"> <column name="id">703</column> <column name="strName">Large Branch</column> <column name="aTreasures">13.1x1.0x1-1</column> <column name="bNested">0</column> <column name="bSuppress">0</column> <column name="bIdentify">0</column> </table>

Question 3 : In itemtypes, if I set fDegradeperhour to -5 or something, will it go over 100% condition or stop at 100%?

Question 4 : That tent symbol that appears on a hex on the map is that hardcoded? or something I can change with a condition modifier or something?

Also, no rush for answers and sorry for all the questions! I get a little carried away


@EmperorZA, I don't think it's possible to see the line number. When I load the data, the game has no concept of line numbers by the time it gets to parsing. Rather, it tells you which dataset it's reading (e.g. parsing camptypes, etc.). I could print the name of the object it's loading for each object, but that might slow down loading substantially (rendering text is slow).

I'll look into it, to see if there's some other way to show more helpful info.

One thing you can try in the meantime is to see which section is causing problems (e.g. conditions, itemtypes), and pull out the first half of the data from it to see if it finishes that step. E.g. if there are 100 conditions and you remove the first 50, and it finishes them and moves on, you know the problem was in the first 50. Otherwise, remove the last 50 and check.

Once you figure out which half of the data is broken, you can then split that half into halves again, and repeat. This is called a binary search, and is one of the faster and more organized ways of finding data in a large set.

Re: question 2, I think this is because all camptypes are based on the same root object, 12.1. As such, all camps can support the same ContentIDs, which are listed in 12.1's aContentIDs. I don't think there's a way to make one camp fit different items than the rest, for this reason.

Re: question 3, a high degrade rate might cause the durability of an object to dip below 0% briefly before it's destroyed and replaced by the degraded components. It's safe to do this, if that's what you're asking. There shouldn't be any side effects.

Re: question 4, the tent symbol is hard-coded to show up when the player makes changes to the campsites in-game.

Hope this helps!

Dan Fedor - Founder, Blue Bottle Games

Hey thanks Dan!

Uhm I'm a bit confused about the camptypes and their itemtypes still

like the itemtype 151, with nGroupID 12, nSubgroupID 1, strDesc any old spot on the ground.

is it using the same group ID and subgroup ID as the camptypes with the id 1?

And is it possible to add new camptypes? I've tried but it does strange things or gives me a bunch of parsing errors when I try "craft" a new camp site (like a metal shack)


Camps are a special type of item, like newspapers, recipes, and datafiles, which have one "template" object and a series of data objects that define copies of that template.

When the game is loading item data, I sees 12.1 as the template for all campsites. Later, when it loads camps from the camptypes table, it makes a copy of 12.1, adjusts the nSubgroupID to match the camptype ID, and swaps in the camptype data to replace the template data.

So if you were trying to make a new camptype, you would add a new entry to the camptypes table, but no changes to the itemtypes table.

Or so the theory goes, anyway. It's possible I designed the system in such a way that it only accidentally works right now, and any change breaks it! (But I think it should work as I describe.)

Dan Fedor - Founder, Blue Bottle Games

aah sweet thanks!


Is the game hard-coded to only look at the first 16 skill slots when determining status. I ask because, despite there being 20 slots for skills visually, it seems that when I mod the game to give more than 16 skills (the 16 basic ones, plus Night Vision, for example), the 17th skill shows up in the character screen, but it has no game effect (regardless of which one is in that slot).

EDIT: It's a bit more subtle than that, actually; the skill in the 17th slot is acknowledged for some purposes, such as actions available. But it's not acknowledged for things like the Night Vision status, or increased range with thrown weapons. For another example, if Mechanic is in the 17th slot, then you do not have the option to fix the vent in the Cryo Facility, though you do if it is in any of the first 16 slots.

EDIT: Might be better to see the Bug Report on this issue, which extends beyond modding

Not sure if bug or I'm doing something wrong so will post here for now.

I have moded in my own weapon with custom atack and charge profile.

Spoiler: Highlight to view
<table name="chargeprofiles"> <column name="nID">1</column> <column name="strName">powered blade</column> <column name="strItemID">0:10.3</column> <column name="nPerUse">10</column> <column name="nPerHour">0</column> <column name="nPerHourEquipped">0</column> <column name="nPerHex">0</column> </table> <table name="attackmodes"> <column name="id">2</column> <column name="strName">powered blade</column> <column name="nRange">2</column> <column name="fDamageCut">6</column> <column name="fDamageBlunt">0.0</column> <column name="strChargeProfiles">1</column> <column name="nPenetration">5</column> <column name="nType">0</column> <column name="strSnd">cueBlade</column> <column name="bTransfer">0</column> <column name="vAttackerConditions"></column> <column name="strIMG">0:AModeCrowbar.png</column> <column name="fMorale">0.6</column> <column name="strWieldPhrase"></column> <column name="vAttackPhrases"></column> </table>

Attack shows up and works correctly.
It also counts up the number of possible hits correctly(1 for every 10 units of energy) but instead of subtracting 10 units of energy per attack it subtracts only 1.
Am I doing something wrong or is it a bug?

One more question. Are x2 images ever used?

Can't really help with charges, as I never got to play with them too much. One idea I have - try using ChargeProfile 6 from vanilla game - it is technically the same, 10 charges per use. If this one will work but yours do not, there might be a bug there.

About x2 pictures - all of the game in "Big UI" resolution setting is constructed from those and game will not work right if they are not present.

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

Nope, I also tried using original 6 ChargeProfile and it does not work either. Any more ideas?

Try changing your profile to use 9 instead of 10 charges. If it is broken it should not remove charges at all, but since it takes 1 instead of 10, maybe it somehow skips the singular numbers and treats tens as ones. It is a long shot but maybe will help to track what is wrong there.

<--Mighty (mini)Mod of Doom-->
DeviantArt Gallery of MoD Sprites

Still uses only 1 charge. Strange thing is it counts up the number of possible uses correctly. :|

I ran into a similar issue when I was testing the laser rifle's high setting (10 charges). I haven't had a chance to fix that yet.

As a work-around, I think you could make the attack mode trigger condition ID=156 (discharge weapon) as many times as you want. It's clunky, but it might work until I get fix the bug.

Dan Fedor - Founder, Blue Bottle Games

Can't get it to work so I guess I will wait for a fix :(

Few other questions:

1. Since it is impossible to force equip an item, how would one go about despawning item if it is not equipped?

2. Is it possible to detect a trait without a skill and put one there?

And since I'm here, it seams that in v.0.9921b new recipes are loaded (or at least displayed) twice.

1. Encounters can remove items by ID as well as items used to reach them. E.g. Hatter taking away the urn (removal by urn's ID) or Zom Zom's removing the admission fee (removing item player chose to get there).

2. Unfortunately, no. You can add a new trait with no penalties that has the desired new skill already inside it (similar to how eye augmentations work). E.g. add a new trait "DnaJur's Trait" that has default treasure ID corresponding to the skill you want to grant, and use the condition effect "AddTrait" to add that new trait to the player.

As for the duplicate recipes in 0.9221b, that seems to be a bug that shows up when using mods, but not the vanilla game. I've fixed it locally, but I may not upload a new build just for that fix until I have a few more things added as well.

Hope this helps!

Dan Fedor - Founder, Blue Bottle Games