Topics

16

Work In Progress / [EXE] Geoscape Generator

« on: January 22, 2018, 04:01:44 am »

Hi Everyone! I've been working on a new coding project that would allow for the generation of a completely new geoscape with just a few clicks!  It's in an alpha state right now, so it only can generate a new look for the globe, not also a corresponding set of regions, countries, cities, etc. - those things will come with time.

The globe is generated in a method similar to the fractal world generator at http://donjon.bin.sh/, creating a series of polygons and giving them a texture according to their altitude; the generated globe ruleset file is saved in user/xcom1/geoscapeGeneratorOutput.yml, and can be used directly in a mod if renamed to .rul.  If you'd like to try out the code, the source is available at my GitHub page, or I've attached a .zip file with a self-contained installation of the executable for Windows or Ubuntu 16.04.  To install from the archive attached here, unzip it somewhere on your computer, copy the files from the original X-Com into the UFO folder, and then run the executable that applies for your OS.

I'm also looking for some help with this project, as there are a couple issues that I only have half-formed ideas how to solve:

• Some of the polygons around the 0/360 longitude line do not have their vertices ordered properly on output, so they look like a series of triangular lakes.
• Having enough polygons to make a decent looking globe often causes to game to slow down; I'm looking for a way to optimize the number of polygons by combining those that share a texture in contiguous areas without sacrificing the detail along borders between textures.
• I need tectonic and climate models to flesh our how textures are assigned - right now they're assigned by altitude and proximity to poles, but this doesn't work well for making deserts, mountain ranges, archipelagos, fertile regions, etc.
• Defining continents, countries, and cities, with proper borders - I have a few plans for how to do this, but it will take some time.
• Interfaces and designing an editor for globe rulesets. More of a stretch goal, but I think it'd be really cool if it was possible to edit the globe in-game, either just tweaking Earth or doing more complicated things with a generated world.

And now for some examples of globes I've generated using this code!

17

Work In Progress / [TOTAL CONVERSION][OXCE+] Survivorz

« on: December 31, 2017, 07:51:59 pm »

== Survivorz 0.5.2 ==

After having this stewing on the back burner for about a year, I've decided it's high time to release an alpha version of my total conversion mod, Survivorz!  Everything is extremely work-in-progress, but there are enough assets that should be shared for the community.  The completed mod will contain the story of a colony ship's AI (you!) fighting to keep the ship's crew alive after it crashes on an alien planet.  As of right now, only some basic weapons and a draft of the maps for the crashed ship are completed along with some placeholder missions, but I'll keep updating as more content is ready.

In order to install, you'll need a copy of Meridian's OXCE+ executable and have run it once.  Extract this mod either from the version attached to this post or from my GitHub page for the mod into your mods folder.  The latest version will always be available on GitHub, along with the changelog.

Known Issues (Please don't report these to me as bugs, I'm still working on the conversion part of this total conversion):

• The globe looks terrible.  I'm working on code to make a globe generator to make the world more interesting and replayable, but it's more WIP than this mod.
• The game has no ending.  Yes, I haven't created enough mission- and story-related content yet.
• Using New Battle causes crashes and strange maps.  Not all combinations of deployments/missions will work, so use this feature at your own risk.

For those of you not scared off by reading that list, here are some glamour shots:

18

The X-Com Files / [MOD/HWP] HWPs as AI Soldier Types

« on: October 27, 2017, 04:15:06 pm »

This mod is now included in X-Com Files! Please do not use it anymore if you have version 0.8.5 or later!

Based on the AI soldier types mod I made for UFO and with the help of Solarius Scorch (and sprites from Dioxine), I've developed a similar mod for X-Com Files!  Standard HWPs are replaced with AI Units that 'wear' tank chassis as armor, meaning you can name your tanks and track how many kills they make.  An advanced version of the AI unit even improves its stats just like your agents!  Furthermore, you can salvage your damaged tanks to recover the chassis at half the cost of a new one, but you'll have to buy a new AI unit to replace the destroyed one.

The purpose of this mod is to test the viability in X-Com Files of switching over HWPs to a soldier type instead of just items sitting in your stores - if it works out, it will likely become a part of XCF. Please report any bugs or feedback about these HWPs here.

When enabling this mod, do not load a game saved during the battlescape that was made without the mod, especially if you have HWPs on the mission! It will likely crash or cause strange things to happen.  You should not need to remove HWPs already in your stores, but do remove them from any craft inventories before enabling the mod, as the mod uses them as base-stores-only items for the armors of the AI soldier types.  Also, HWP ammo will be increased in size in your stores, so you may need to sell some off if you are near capacity.

Disclaimers and Known Issues:

• AI Unit built-in weapons sometimes don't save their loaded/unloaded states when arming at base. Make sure you load your tanks when they reach the battlefield!

This mod is now included in X-Com Files! Please do not use it anymore if you have version 0.8.5 or later!

[Spoiler]

19

OXCE Suggestions DONE / [Documentation] Scout/Sniper AI

« on: August 28, 2017, 03:44:59 pm »

Scout/Sniper AI is my latest OXCE+ project, adding squadsight capabilities for the aliens; now they can camp in smoke just like you!  The code adds two new unit parameters that control this behavior:

• spotter: -1 - When a unit has a nonzero scout value, it sets a flag on any units it spots that allows sniper-enabled enemy units to "know" about the spotted target.  The value placed here determines the number of turns the knowledge of the spotted target is available, -1 sets the value to the unit's intelligence score and 0 disables this behavior.
• sniper: 75 - This determines the percent probability that the AI unit will act on knowledge of targets spotted by scouts.  When active, the sniper AI will pick from a list of the spotted targets and attempt to attack them whether or not the sniper can 'see' the target.

The choice of attack type depends on the sniper's weapons, accuracy, intelligence, and aggression.  The AI calculates a score for each firing mode available on the weapon as well as considering throwing a grenade, and then picks the attack based on which mode it thinks will be the most efficient.  The exact formula is:

Spoiler:

score = number of shots * accuracy / percent TU cost of the attack, where accuracy will be modified by the UFO extender formula if that option is turned on (recommended).
The score is then modified by intelligence: score = score * RNG::(100 - int_coeff * (10 - intelligence), 100 + int_coeff * (10 - intelligence)), and is further modified by aggression for auto shot:
 score = score * (100 + aggro_coeff * (aggression - 1))

The coefficients are explained below.

How this score is affected by intelligence and aggression is determined by these global parameters:

• fireChoiceIntelCoeff: 5 - This parameter is a measure of how much a unit's intelligence matters when determining what the most efficient firing mode is; lower intelligence means more randomness in the choice, while 10 intelligence means the unit will always pick the most efficient mode.  Defaults to 5, which leads to a 50%-150% RNG roll modifier to score for 0 intelligence, reducing linearly to 100%-100% at 10 intelligence.
• fireChoiceAggroCoeff: 5 - This parameter measures how much a unit's aggression bumps up the chances of using auto shot - aggression above 1 will be an increasing multiplier to the efficiency score for auto shot, while aggression of 0 will be a decrease.  Default value is 5.

The ruleset for using these values will look like this:

Code: [Select]

units:
  - type: STR_SECTOID_SOLDIER
    sniper: 75 # Sectoid soldiers have a 75% chance of taking a sniper action when the AI has determined it will attack
  - type: STR_SECTOID_NAGIVATOR
    spotter: -1 # Sectoid navigators will spot for the soldiers, giving them as many turns to act on your soldiers as the navigator's intelligence

ai:
  fireChoiceIntelCoeff: 10 # Make the choice of attack more RNG dependent
  fireChoiceAggroCoeff: 1 # Aggression doesn't matter as much

The source code is available on my GitHub page.

Edit 171110: This is an official part of OXCE+, so the links for my repository above are deprecated.  This post will remain for documentation.

20

Released Mods / [UFO] HWP AI Units

« on: August 14, 2017, 10:20:29 pm »

== HWP AI Units v1.1.10 ==

Inspired to finish this idea thanks to Drages and his fantastic mod, I present HWP AI units as a type of soldier!  Able to gain firing and reactions experience as well as increase TUs over time, these versions of the vanilla HWPs should be a bit less useless junk as your campaign progresses.  Most of the HWP weapons have gained the ability to fire two aimed shots per turn or have an added automatic firing mode to further differentiate from the man-portable counterparts, and a new incendiary cannon will allow you to roast large terror units with minimal collateral damage.

Features:

• AI Unit soldier type that wears HWP chassis as armor and gains experience
• Napalm Cannon HWP
• Hover MLRS HWP
• Lightly rebalanced vanilla HWPs
• Recovering and repairing damaged HWPs
• Beautiful HWP inventory images by Bloax taken shamelessly from Piratez

Intended to be used with Meridian's OXCE+, this mod will still run on the nightly OXC versions, but some features will not work.  For installation instructions of OXCE+, see here.

Note:  This mod is meant to be more or less a vanilla UFO Defense rebalance of HWPs using the features of OXCE+, if you're looking for something a bit more expansive, see Drages' mod linked at the top of the post.

== Changelog ==
1.1.10

• Changed MLRS Napalm Rockets to use 50-150% damage roll.
• Added custom armor preview sprites.
• Added float and stand height to hover armors to match vanilla values.
• Gave tanks some thermal vision and made their weapons more accurate if no-LOS penalty is on.

1.1.9

• HWP soldiers no longer have to recover from wounds.
• Removed 'system damage' resistance type that reduced all damage done to HWPs
• Returned HWP soldiers' HP to vanilla values since we no longer need to worry about wound time.

1.1.8

• Disallowed kneeling and sprinting on all HWP armors.
• Set psi strength to 0 for AI Units, since the AI doesn't target 2x2 units with psi attacks.

1.1.7

• Set training caps to 0 for AI Units so that they can't be trained in a gym added by another mod.
• Removed "no rank" string since it's part of OXCE+ data files now.
• Fixed HWP Laser Cannon pedia article showing when laser cannon was not researched.
• Reduced Hover MLRS susceptibility to incendiary to match napalm tank.

1.1.6

• Changed some strings from wound recovery to recovery time.
• Doubled the number of rockets the Hovertank MRLS holds, since it doesn't do much to small units.

1.1.5

• Added Hovertank MLRS as a new HWP armor.
• Added weights to HWP corpse items to make sure the floor sprite is on top of the stack when killed.
• Tank/Cannon armor now no longer requires an item in stores, changed Repair Tank/Cannon to give back some ammo instead.
• Fixed damaged AI unit recovery giving the wrong stores item, which made repairing impossible.

1.0.1

• Added back research requirements for HWP repair that were removed for earlier testing.

1.0.0

• Initial release

21

OXCE Suggestions DONE / [Documentation] Close Quarters Combat (CQC)

« on: April 20, 2017, 10:59:40 pm »

Hey everyone, I finished coding a feature requested by Dioxine for Piratez, but it could also be useful for those looking for a bit more challenge from the game!  This code adds an extra check when firing a ranged weapon when an enemy is within one of the 8 tiles surrounding the unit firing; if the check fails, the firing unit will be turned up to 90 degrees from the direction they're facing before shooting, to simulate the enemy doing more than just standing there and taking an autoshot with the gun's muzzle buried into their skin.  Don't worry, this check is enabled for aliens attacking your units too, so it's more feasible to block a door with your soldiers!

Under the hood, the weapon firing has a close quarters accuracy, which is multiplied by certain stats of your units.  The melee dodge of the enemy is subtracted from this score, and a 0-100 dice roll is made.  If the roll is greater than your score, the unit has a equal chance of firing straight up, straight down, 45 degrees to the left or right of the unit's current facing, or 90 degrees to the left or right of the unit's current facing.  The parameters open to ruleset are as follows:

Code: [Select]

enableCloseQuartersCombat: 1 # default is 0 to disable this new code, 1 enables it
closeQuartersAccuracyGlobal: 100 # default 100, this sets the default weapon close quarters combat accuracy - bump it up to make your soldiers less crappy at 1 tile!

items:
  - type: STR_RIFLE
    accuracyCloseQuarters: 125 # this overrides the global default, so you can make weapons better and worse at close range
    closeQuartersMultiplier: # determines which stats get used for the close quarters combat score, defaults to (melee+reactions) / 2 if not defined on an item
      melee: 0.5
      reactions: 0.5

extraStrings:
  - type: en-US
    strings:
      STR_FAILED_CQB_CHECK: "Failed Close Quarters Combat Check!"

See the source code commit in my repository here.

Thanks to the new upload size, I've also attached a Windows .exe for those brave enough to try it out!  The zip file contains the new executable and the above ruleset file to put in a mod for testing.

Edit 171110: This is an official part of OXCE+, so the links for my repository above are deprecated.  This post will remain for documentation.

22

OXCE Suggestions DONE / [Documentation] Getting High on Vertical Terrain

« on: February 20, 2017, 06:26:01 pm »

Hi Everybody!  Based on my previous experiments with loading alternate terrains in the map generator, I've come up with some new code for placing map blocks on top of each other, similar to how the addUFO and addCraft commands work, but now with arbitrary map blocks!  This code is all accessible through a tag in the mapscripts ruleset called verticalLevels:

Code: [Select]

alienDeployments:
  - type: STR_MEDIUM_SCOUT
    height: 8
mapScripts:
  - type: DEFAULT # forest, mountain
    commands:
    - type: addUFO
    - type: addCraft
    - type: addBlock
      size: [1, 1, 8]
      verticalLevels:
      - type: ground
        size: [1, 1, 2]
        terrain: XBASE
        blocks: 20
      - type: middle
        size: [1, 1, 4]
    - type: addBlock
      size: 2
      executions: 2
    - type: fillArea

The snippet above produces the first result image I've attached below, where a forest map block sits atop the dirt fill from the base defense maps.  Speaking of base defense maps, this new code will also work for those too - I've included some examples of a base in the desert at night, generated by the ruleset attached.

The verticalLevels tag can be defined for the mapscript commands addBlock, addCraft, addUfo, and fillArea.  These definitions will supersede the blocks, groups, etc. definitions in the regular map script command in favor of their own.  Each vertical level supports definitions of the following:

• type: ground - This defines the behavior of the level and how it's handled.  "ground" is only used once and is placed at z = 0, "ceiling" is also only used once and is placed at the top if defined, "middle" is used to create filler levels in between the first two, "empty" allows for a filler level to contain no map block, "decoration" acts like middle but sets its vertical size to zero, causing the next map to be loaded directly over it, and "craft" is a marker for placing the craft/UFO in the addCraft/addUFO commands.
• groups: [6, 7, 8] - Works just like groups in regular commands, defining which groups of blocks are used in this particular level.
• blocks: 20 - Again, just like blocks in regular commands, it also overrides the groups tag.
• size: [1, 1, 4] - Perhaps the most important definition in a vertical level besides the type, this is how the engine recognizes the vertical extent of a particular level, since it is not specifically defined for most map blocks.  The size is read in as [x, y, z], with z being the important bit here. Defaults to [1, 1, 1].
• maxRepeats: 1 - For the filler levels "middle", "empty", and "decoration", defines how many times they can be used in a given map chunk.  Negative numbers remove any limit on the number of repeats.  Defaults to -1.
• terrain: XBASE - Defines which terrain this particular level will use, see the documentation for the alternate terrain commands for more info.  Defaults to the terrain from the deployment or mission.

Algorithm:
------------
Once the levels are defined in a particular command, the code populates a list of levels based on either the height of the map or the size in z defined in the command itself.  The "ground" and "ceiling" levels are added to the list first to reserve space for them.  Next, the remaining levels are looped over in the order defined by the ruleset, adding them in between the ground and ceiling to fill out the chosen size for the command, stopping when either the maxRepeats are reached for each level and there are none left, or when no more levels can be added without going over the size of the map/command.  Finally, the "ceiling" level is given an offset to place it directly on top of the last filler level chosen.  This method of filling the space in the vertical direction is why defining the specific sizes for each level is important - the code relies on those definitions to determine how high above the previous level the next should be placed.  With a size in z of 0, the next level will be placed at the same offset as the previous, often running into interesting terrain collision issues, but this can be and is leveraged by the "decoration" level to allow for say a building to be placed on various kinds of terrain based on where in the geoscape the mission occurs.  Other use examples might be adding "empty" levels to addCraft/addUFO to make them hover over the terrain, or making your base have both above and below ground portions.

Base facilities:
------------
Speaking of the base terrain, the verticalLevels tag can be placed directly on a facility definition to override the given map name and generate that particular facility's map as if it were an addBlock command.  If used for a 2x2 facility though, it will require a 20x20 map block, not the four 10x10 blocks usually defined as in the hangar.

Edit 171110: This is an official part of OXCE, so the links for my repository are deprecated.  This post will remain for documentation.

23

OXCE Suggestions DONE / [Documentation] Craft Tractor Beams

« on: February 06, 2017, 09:02:46 pm »

New feature for dogfights: Tractor beams for your craft!  They allow you to effectively decrease the maximum speed of a UFO during interception, preventing their escape.  If you have powerful enough beams targeting the UFO, you can even cause it to land or splash down in the water!

The new ruleset parameters are:

• tractorBeamPower: 0 - Set this parameter on a craft weapon to determine how much it slows down the max speed of a UFO when it's in range and the weapon is active.  Defaults to 0.
• ufoTractorBeamSizeModifiers: A global set of mod values to determine how much each size of UFO is affected by a tractor beam.  The default is 4x for very small, 2x for small, 1x for medium, 1/2x for large, 1/4x for very large.

If the UFO's max speed minus the sum of all the active tractor beams multiplied by the size modifier is less than your craft's speed, the UFO cannot escape.  If that sum multiplied by the size modifier is zero, the UFO either lands for between 30 and 120 minutes, or is destroyed when over water (except in TFTD, where water = landing), granting you points as if you crashed it.

See here for the commit on GitHub.

Sample ruleset and strings:

Code: [Select]

craftWeapons:
  - type: STR_TRACTOR_BEAM_UC
    sprite: 0
    range: 65
    launcher: STR_TRACTOR_BEAM
    tractorBeamPower: 1000

ufoTractorBeamSizeModifier:
  - 400 # very small, tractor beams are 400% or 4x as effective
  - 200
  - 100
  - 50
  - 25 # very large, tractor beams are 25% or 1/4x as effective

extraStrings:
  - type: en-US
    strings:
      STR_TRACTOR_BEAM_ENGAGED: "TRACTOR BEAM IS ENGAGED!"
      STR_TRACTOR_BEAM_DISENGAGED: "DISENGAGING TRACTOR BEAM"

Edit 171110: This is an official part of OXCE+, so the links for my repository above are deprecated.  This post will remain for documentation.

24

OXCE Suggestions DONE / [Documentation] Mixing and Matching Terrain with MapScripts!

« on: December 03, 2016, 08:58:36 pm »

Hi Everyone!

1/ I've been working on another coding project for the OXCE+ version of the engine, and just got a new feature working: using map scripts to add map blocks from other terrains.  This allows you to do things like adding some forest to a simple farmland ufo mission, like in the screenshot I've attached.  The original intent was to start adding support for having an above-ground portion to base defense maps, but it turned into making more general tools for this purpose.  Map scripts can be given an optional command terrain:, which allows you to pull in a map block from any defined terrain. This works for addBlock, addLine, addCraft, addUFO, and fillArea.

For the example of the farm/forest hybrid map, the script looks like this:

Code: [Select]

mapScripts:
  - type: FARM
    commands:
    - type: addUFO
    - type: addCraft
    - type: addBlock
      terrain: FOREST
      size: 2
      executions: 2
    - type: fillArea
      blocks: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]
      maxUses: [3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3]

2/ The second part of the new code is adding special 'filler' terrains for base defense missions.  In globe.rul, where terrain: is defined by geoscape texture, I've added the possibility to define baseTerrain: in the exact same way - these are to replace the nondescript dirt fill-in with whatever you want.  Maybe you want your base to be placed right next to a charming little farm?  Or have snow cover in the arctic?  The commands I described above will do this with the base squares not filled with facilities by setting the terrain: in the command to "baseTerrain" as in the script example below.  I also added an option baseDefenseMapFromLocation to seed the RNG for generating the base defense maps from the latitude and longitude of the base, so your bases won't have an overactive ground crew completely redoing the landscaping in-between every time your base is attacked.

Edit by Meridian: baseDefenseMapFromLocation seems to be mandatory, not optional, for "baseTerrain" to work

Code: [Select]

terrains:
  - name: XBASE_FILL
    mapDataSets:
      - FOREST
    mapBlocks:
      - name: XBASE_FOREST00
        width: 10
        length: 10
      - name: XBASE_FOREST01
        width: 10
        length: 10
      - name: XBASE_FOREST02
        width: 10
        length: 10
      - name: XBASE_FOREST03
        width: 10
        length: 10
      - name: XBASE_FOREST04
        width: 10
        length: 10

  - type: XBASE
    commands:
    - type: digTunnel
      direction: both
      tunnelData:
        level: 0
        MCDReplacements:
          - type: westWall
            set: 1
            entry: 13
          - type: northWall
            set: 1
            entry: 14
    - type: fillArea
      terrain: baseTerrain

globe:
  textures:
    - id: 0
      terrain:
        - name: FOREST
          area: [0, 360, -90, 0]
        - name: JUNGLE
          area: [0, 360, 0, 90]
      baseTerrain:
        - name: XBASE_FILL
    - id: 1
      terrain:
        - name: CULTA
      baseTerrain:
        - name: XBASE_FILL
#... etc, adding baseTerrain for each texture id: ...

The second attached image shows an example of this at work, though it's not as nice since I messed up making/editing the maps.

Note:  This code has been included in Yankes' OXCE and Meridian's OXCE+ executables, see their threads for source code and .exe's!

25

OXCE Suggestions DONE / [Documentation] UFO and Craft Shields

« on: November 21, 2016, 05:38:19 pm »

Based on a discussion on the Piratez Discord channel, I've coded a new feature for interceptions - rechargeable shields!  The changes include the ability to define shield levels for UFOs and player craft in the ruleset, set effectiveness of craft weapons against shields, new palette-effect GFX for the interception window, and shield percentage information in craft status windows.  This is built against OXCE+ 3.3.

Edit 161220 (especially for Meridian later  ) - I've re-staged the edits on top of OXCE+ 3.5, now into a single commit, found in this branch of my repository.  The executables below are out-of-date, and I don't feel like recompiling right now.

Edit 170130 This is now included in OXCE+, so the urls for my repositories will be deprecated as I clean up to make room for writing new code features.

The ruleset options are:

• (craft/ufo stats) shieldCapacity: 0 - defines the number of shield points a craft has, similar to damageMax.  Defaults to 0.
• (craft/ufo stats) shieldRecharge: 0 - defines the percent chance of recharging a point of shielding per game second during an interception.  Values under 100 are the percent chance, for over 100, every +100 means an automatic +1 to shields per GS.  Thus shieldRecharge: 250 means +2 shields/GS, with a 50% chance of +1 more.  Defaults to 0.
• (craft/ufo stats) shieldRechargeInGeoscape: 0 - similar to shieldRecharge, but acts every 5 seconds in the Geoscape.  Giving it a value of -1 means instant recharge as soon as 5 seconds pass!  Defaults to 0.
• (craft/ufo stats) shieldBleedThrough: 0 - defines the percent of damage that passes the shield when it goes down.  A value of 0 means that with even just 1 shield point, any single hit will be blocked, while 100 means 100% of the damage left after the shield blocks it will go on to damage the craft.  Defaults to 0.
• (craft) shieldRechargedAtBase: 1000 - defines how many shield points are recharged at base per hour for player craft.  Recharge happens on the hour, whether or not the craft is damaged.  Defaults to 1000 (meant to be all shields require just an hour to recharge)
• (craftWeapon) shieldDamageModifier: 100 - defines the percent of power that a weapon does to shields.  Default is 100.

The shieldCapacity, shieldRecharge, shieldRechargeInGeoscape, and shieldBleedThrough parameters can also be defined as a stat bonus by race for UFOs or put on craft weapons (to simulate adding shield generators).

Here's a link to a copy of the Windows and Ubuntu 14.04 executables I've compiled, with a mod and save to test out some of the new features.

Edit: Had to fix a bug with not having proper default color handling, added the commit for that and updating the testing package.

More Edit:  Here are the extra strings for this and my previous interception window tweaks, since those don't have their own thread:

Code: [Select]

extraStrings:
  - type: en-US
    strings:
# Interception window strings
      STR_UFO_HIT_NO_DAMAGE: "BOUNCED OFF THE HULL!"
      STR_UFO_HIT_GLANCING: "GLANCING HIT!"
      STR_UFO_SHIELD_HIT: "HIT THE SHIELDS!"
      STR_UFO_SHIELD_DOWN: "ENEMY SHIELDS DOWN!"
      STR_INTERCEPTOR_SHIELD_HIT: "OUR SHIELDS ARE HOLDING!"
# Craft info window strings
      STR_SHIELD: "SHIELD>{ALT}{0}"


26

Work In Progress / Memory allocation errors when declaring variables in header files

« on: November 18, 2016, 03:27:13 am »

This is a question to the coders out there: I've been trying to add new ruleset options for improving the interception window/minigame for OXCE+, and have run into a number of different memory allocation errors, most of which I narrowed down to how class variables are declared in the header files.  Is there a proper method for adding new variables to the header?

For example, in RuleUfo.cpp, I wanted to implement a method for getting an integer from the ufos: ruleset to point to a resource for the UFO's firing sound, copied somewhat from the methods in RuleCraftWeapon.cpp and .h.  I declared int fireSound in RuleUfo.h, and had it initialize to fireSound(-1) in the class constructor.  Compiled smoothly, but CTD at runtime.  I eventually got it to work by moving the declaration of fireSound a few lines down in RuleUfo.h, but still with all the other variable declarations.  I've done some similar additions (I can provide more specific examples when I'm not on my phone), and it has been the same story of re-ordering the declarations in the header.  It seems like black magic to me, so can anyone provide an explanation why a certain order works, and how to properly code that order without guess and check?

Edit: Thinking about it, could the memory allocation errors come from not recompiling the other .cpp files that include the header before repackaging the executable? I typically only replace the object file for the .cpp file whose header I'm editing, so in the RuleUfo example, only RuleUfo.cpp recompiles into RuleUfo.o when I edit RuleUfo.h.  Should I have found all .cpp files that include RuleUfo.h, removed their associated .o files, and then recompiled?

27

Work In Progress / [WIP] Pulse Weapons and Other Stuff

« on: October 17, 2016, 09:33:19 pm »

I'm creating this thread to release some resources and experiments I've done in modding, mostly since regular releases are a great way to remind myself to keep working on a project!  My goal is to eventually make a total conversion with a modular enough ruleset such that pieces can be easily extracted for use by the community at large.  With that in mind, here are the results of my first steps into making sprites and weapons:

==Pulse Weapons, v 1.1 (Updated 8 November 2016)==
I was inspired by a combination of TFTD's description of its Gauss technology, Mass Effect's small arms, and desire for a rifle with the versatility of an underslung grenade launcher or the variety of rounds available for a shotgun, to create these pulse weapons.  Using some of the features from OpenXcom Extended, it was possible to make a weapon that has a battery similar to the infinite laser weapons that can be quickly unloaded in favor of a specialized grenade or flare, then return to its normal firing mode all within the same turn.  If used in the vanilla game, this mod will give alternatives to the starting rifles and pistols with increased adaptability via special direct-fire grenades.  Perhaps a little broken balance-wise, they're meant to be more of a toy to play with until lasers and plasma make them obsolete.  It should be playable without OpenXcom Extended (I use Meridian's OXCE+), but the tweaks to TU costs for unloading and reloading the weapons won't work, and the battle rifle's special clip will work like a crappy shotgun instead.

The progression between the weapon types and balance will become more clear once I start putting together the story and pacing of my overarching mod, but for now, everybody loves having more sprites to share!  Feel free to take them for use wherever, just remember to credit me.

Edit 8 November 2016:  I've rebalanced the Pulse weapons and made them require some research first to compensate for increased firepower.  Also adding my second set of weapons, called LINAC after the linear particle accelerator idea.

28

XPiratez / Shotgun Rebalance Test Mod

« on: August 18, 2016, 04:45:04 am »

With Meridian's latest OXCE+ update pulling in my re-write of the pellet spread calculation, shotgun-type weapons are much more configurable now.  I've written a short mod to make use of the new values for spread for all weapons with multiple pellets.  If you want to use the new shotgun parameters, you can find the mod here.

Please post feedback on testing the new code here, so we can get Dioxine more information for balancing the weapons later.

29

OXCE Suggestions DONE / [DONE] [Suggestion] 'Realistic' Shotgun Behavior

« on: August 13, 2016, 06:46:51 pm »

'Realistic' Shotgun Behavior Executable
Link for Google Drive Archive with Test Mod
Link for Test Mod Only
Link for OXCE+ Executables
Link for GitHub OXCE+ Repository

Based on the discussion in https://openxcom.org/forum/index.php/topic,4744.0.html, I've created an edited version of Yankes' OpenXcom Extended executable to better model realistic shotgun behavior, or at least make the spread pattern of shotgun pellets configurable enough to look realistic.  I've attached a link to a zip archive of the edited source code (in the subfolder OXCE/src) and a mod that demonstrates this new behavior on a few different shotguns.  There's a compiled executable for Ubuntu 14.04 and Windows.  Here's the rundown of what this modification does:

The base behavior of shotgun pellets starts by calculating a normal trajectory like any other weapon for the 'first' pellet projectile.  The following pellets, up to the number defined by shotgunPellets on the ammunition in the ruleset, take the previous trajectory and modify it by the accuracy of the shot minus 5% for each pellet after the first, leading to a wide cone around wherever you clicked.

The new behavior starts the same way by calculating the first trajectory by the normal weapon/firing accuracy, but then each subsequent pellet is spread around the point of impact, with the spread defined by a few new definitions in the ruleset, affected by the range dropoff of the weapon:

• shotgunSpread:  Defined on an ammunition type as a number between 0 and 100 with a default value of 100.  With shotgunBehavior: true, this is approximatley the percent of pellets after the first that will hit the same tile/target as the first at the maximum accurate range.  With shotgunBehavior: false, it is a multiplicative modifier to the 5% rule for the previous behavior, such that 100 means full normal spread, 0 means spread only from the weapon's accuracy.
• shotgunBehavior:  Defined on an ammunition type as 1 or 0, default 0, determines whether or not the new spread calculation will be used (= 1).
• shotgunChoke:  Defined on a weapon type as a number between 0 and 100 (or higher) with a default value of 100.  Used only for shotgunBehavior: true, acts as a percent modifier to the 'accuracy' of the pellets from shotgunSpread - 100 means only the shotgunSpread value defines the spread pattern, 0 gives maximum possible spread regardless of the shotgunSpread value.

All the ruleset defaults are set such that these changes will not affect weapon/ammunition definitions in current mods, ensuring compatibility and no unexpected changes.

The attached mod borrows a few shotguns from Dioxine's XPiratez mod (https://openxcom.org/forum/index.php/topic,3626.0.html), and adds possible values of the parameters above to give a feeling of what's possible using these changes.

Edit 170130 This has been included in OXCE+ long ago, so the above links to my repositories and .exe's are deprecated in favor of the current OXCE+ version.

30

XPiratez / Craft Weapons DPS Spreadsheet

« on: June 16, 2016, 04:23:39 pm »

Got a little bored on public transit, and saw the need for updated information on craft weapons since the https://ufopaedia.org article is still in the queue for revision.  So here's a link for a spreadsheet I made to calculate DPS for the weapons, based off the 0.99 ruleset file, and assuming you're attacking on aggressive stance.

https://docs.google.com/spreadsheets/d/1R0PvIky-_X6XYGLVkAxw5Prgdnd2_6_toKDOFIBaIaY/edit?usp=sharing

I included columns for the increased accuracy of some of the heavy-weapon toting ships, since I was partially make this to decide what early heavy weapon should go on my Swordfish, and whether or not it'd be fun to equip a Barracuda with the hyper-wave targetter.  In general, the DPS columns are more useful for the light and heavy weapons, with the exception of the plasma and fusion launchers, and the expected output columns are more useful for missiles.  There are also pages for looking at damage vs. different size targets, so you can make informed decisions on what you want to use to take down that cruiser.

Edit:  New sheet for modeling interception, up to date for pilot changes.

Edit: With my code addition of craft shields, determining the outcome of a given interception is no longer feasible without more direct simulation, so this spreadsheet is out-of-date and should not be used to direct your airgame.