aliens

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 - ohartenstein23

Pages: [1] 2 3
1
OpenXcom Extended / [Documentation] [Feedback] Map Editor
« on: October 26, 2020, 12:26:44 am »
I'm making available an alpha release of a map editor for OXCE that I've been working on! This tool is intended for helping modders and other interested community members to make small-scale changes on existing MAP/RMP files in a mod from within OXCE - for large scale map creation the MapView tool maintained by kevL is a better choice.

Attached to this post are 64-bit Windows and Ubuntu 22.04 builds of OXCE with the map editor included - any other operating systems would need to be compiled from my source code, which can be found on GitHub. It is currently built on top of OXCE 7.8.6. Any updates to OXCE or bug fixes for the editor will have to wait until the next feature release of the editor. Installation is done in the same way as for OXCE, and I would recommend keeping the installation of the editor separate from the OXCE version you use for regular play/modding.

*** IMPORTANT CAVEAT: This is an incomplete feature and not a part of official OXCE releases. Do NOT bother Meridian with bug reports or requests regarding this map editor. ***

Extensive documentation of the editor and its features is contained in the build downloads below. For the features currently available and the kinds of feedback I'd appreciate on this build, I'm including a bit from the first page of that documentation:

Quote
This is the documentation for an alpha release version (05 February 2021) of the Map Editor for Open X-Com Extended (OXCE). The alpha release versions are intended for demonstration and testing of the basic functionality of an in-game map editor. Feedback on the user interface and functionality are appreciated as are bug reports, but bug fixing support will likely be slow and tied to new feature releases. Please read through the following list of included and planned features before making suggestions for further development. It is also not intended to replace MapView but rather to provide supplementary map editing with minimal setup outside installation of OXCE. The primary features in this release are

  • Editing of maps included in the currently loaded set of mods
  • Creating new maps from the terrains defined in the currently loaded set of mods
  • Editing single tiles at a time by adding, changing, or removing objects within the tile
  • Editing single AI nodes at a time by adding, moving, changing, and removing them and their links
  • Switching between tile and AI node editing modes
  • Undoing and redoing single tile/node edits
  • Saving edited .MAP and .RMP files in the current OXCE user folder
  • Sample ruleset for implementation of the edited .MAP and .RMP files in the openxcom.log file
  • Opening the main Map Editor Menu for creating/selecting a new map to edit directly from the Editor Interface.
  • Editing multiple tiles/nodes at a time by both rectangular selection and paintbrush-style selection tools
  • Copying, cutting, and pasting selections of multiple tiles/nodes at once
  • Find and replace tools for searching and editing tile and node content
  • Searching of text lists in the Map Editor Menu
  • Find and replace tools for searching and editing tile and node content

The following features are planned for future releases:

  • Option to attempt to match MCDs across maps when pasting tiles
  • Creating new maps with custom terrains from a selection of terrain data sets (.MCD files) from the currently loaded set of mods
  • Direct loading of .MAP files from a specified directory using a supplementary file to indicate which terrain data sets to use
  • Resizing maps
  • Improved Map Editor main menu
  • Testing map being edited in the battlescape before saving and importing changes due to tile destruction

2
Released Mods / [OXCE] Death Splash Messages
« on: June 06, 2019, 10:07:39 pm »
Are you a masochist and want the game to insult you when somebody dies? This mod is for you. A randomized message will be displayed when your soldiers die, reminding you just how bad you are at this game.

This mod uses a simple script to detect when one of your soldiers is killed and makes it clear that you messed up with a brief message.

Right now it only has three messages to randomly select from, but I may add more should the fancy strike me. It also only works for UFO Defense, but it's written to be easily expanded to more extensive mods.

There are animated GIFs available to show off how it works on the mod.io page.

3
40k / [Addon] IG Crewed Weapons Testing
« on: February 15, 2019, 04:22:43 pm »
As I previewed in the latest episode of my LP, I made an aux mod to test the Imperial Guard's heavy weapons to crew-served emplacements. It's available on our mod.io page in the releases section - if you're playing as the Imperial Guard, try it out and leave me some feedback on this thread!

4
Work In Progress / [OXCE] Crewed Weapons Testing
« on: January 28, 2019, 06:36:38 pm »
Updated 190207 - new download in this post.

As previewed in the latest episode of my WH40k Let's Play, I've been designing a set of OXCE scripts that would turn a HWP unit into a crew-served weapon emplacement. The essence of the idea is that the emplacement unit can't do anything until a soldier interacts with it in melee range, then it inherits the firing accuracy and reactions of the soldier that uses it. With proper time unit costs set, the emplacement could require two soldiers to operate at full capacity for setting it up and reloading.

I'm attaching a standalone version of these scripts for testing. It provides a HWP unit purchasable at the start of UFO that is essentially a better heavy cannon with HE ammo. There is an ufopaedia article that explains the basic use, but here's the more in-depth explanation:

Usage:
  • Kneeling melee attack on the turret: "uses" the turret, setting your soldier's TUs to 0, and setting the turret's firing accuracy and reactions to be equal to that of your soldier's stats. If the soldier would've had >50% TUs after the melee attack, the turret gets 100% TUs. If less than, the turret gets 50% TUs. The turret's energy is zeroed to prevent movement. The firing accuracy and reactions stats revert to 1 at the beginning of your next turn.
  • Standing melee attack on the turret: "pushes" the turret, granting it a small number of TUs and energy in order to move. The amount is proportional to a soldier's strength. This can't be done again until the turret is under 7 TUs.
  • Melee attack with the special item "Turret Wrench": "disassembles" the turret, stunning it and allowing it to be easily picked up and moved. It won't recover from stun automatically. Cannot use/push the turret.
  • Ranged attack with the special item "Turret Wrench": "assembles" the turret, reviving it from the stunned state created by disassembly, setting the stun to 0.

If you're bringing the turret on the craft, make sure you bring a stun rod and equip it on a soldier, otherwise the turret will sit on top of your equipment pile and prevent using it! Also, you'll need OXCE later than 19 Jan 2019 for the script to work, and later than 26 Jan 2019 for the firing and reactions to save properly if you save/reload the game.

You can also get some experience from using the weapon emplacement - during each turn, the script keeps track whether or not you hit at least once with the turret. At the end of battle, the script counts how many turns a soldier had a hit with the weapon emplacement and gives firing experience according to that number - +0 or +1 firing for 1 hit, +0 to +2 for 2 hits, and +1 to +3 for 3 hits and up. Reactions training is also planned, but requires some more script hooks in order to function.

If you try the mod out, please let me know what you think!

5
Playthroughs / Let's Play: WH40k
« on: December 11, 2018, 04:23:41 am »
Hi everyone, I'm starting a let's play of the WH40k mod on OXCE! I'll be playing as the Imperial Guard, so there will be plenty of room for recruits - let me know if you want to briefly see your name on screen before a bolter or lasgun vaporizes it. I'll begin recording the actual series once bulletdesigner and I release a new version of the mod where both the Imperial Guard and base content are combined into a single download. I don't know how often I'll post new videos as this is the first time I'm trying recording a LP, but I promise I won't spam too much here as advertisement for this.

Recruitment video: https://youtu.be/xwdZJY1I4_8
Youtube playlist: https://www.youtube.com/playlist?list=PLkcoV_pZgGtJjYhGk25lHW93wR_cyt_It

Edit: I'm attaching the mod I use for soldier names and re-recruitment if anyone wants to have a look how it's done.

6
OXCE Suggestions DONE / [Documentation] Spawning Units from Items
« on: August 22, 2018, 10:13:03 pm »
As of the 21 August 2018 release of OXCE+, new code has been introduced that allows for the spawning of new units during the battlescape using items.  The ruleset for this feature consists of two new parameters on items:
Code: [Select]
items:
  - type: STR_SOME_UNIT_SPAWNING_ITEM
    spawnUnit: STR_SOME_UNIT # Default empty meaning don't spawn a unit, when a valid unit (defined in the units: ruleset) is defined here it will be spawned by this item.
    spawnUnitFaction: -1 # Default -1 meaning the spawned unit will be the same faction as the unit using/firing the item, this defines which faction gets the new unit:
                         #   -1: Same faction as item user
                         #    0: Player faction
                         #    1: Enemy faction
                         #    2: Civilian faction

When this item is fired/used and hits something and either causes a hit animation or an explosion, the chosen unit will be spawned after the hit/explosion.  This means that the new unit cannot be damaged by this item except during an autoshot or if terrain explosions occur after the hit.  If the tile at the center of the hit/explosion is occupied by a unit or an object, the surrounding tiles will be checked in the 3x3 'circle' around the hit/explosion, starting with the tile closest to the unit firing.  The new unit's facing will be in the same direction of the original user.  If there is no unit firing or using the item, then the search for a vaild spawn position will start on the north center tile of the surrounding 'circle' and the chosen facing for the new unit will be random.

Items that may be used to enable this behavior are:
  • Firearms that use themselves as ammo - lasers, single-shot launchers, etc.
  • Any ammunition for a firearm.
  • Melee weapons or melee attacks on any item.
  • Grenades and proximity mines.
  • Psi-amps.

Player units spawned by this code will not count for the purposes of determining whether the player has any soldiers left, so you will automatically lose a mission if you lose all other units but the ones spawned this way.  Spawned player units will be automatically removed before item/unit recovery.  Enemy units spawned by this code will count for the total number of aliens left, and must be killed in order to end a mission by eliminating all hostiles.

This unit spawning also has a special interaction with items placed as part of map blocks:  any items placed on a map block as a primed grenade with a timer of 0 will spawn their unit before the battle begins but without an explosion.  The ruleset for this would look like:
Code: [Select]
items:
  - type: STR_SOME_UNIT_SPAWNING_ITEM
    spawnUnit: STR_SOME_UNIT
    spawnUnitFaction: 0
    battleType: 4 # Must be a grenade in order to spawn correctly before battle

terrains:
  - name: STR_TERRAIN_WITH_BLOCK_THAT_SPAWNS_UNITS
    mapBlocks:
      - name: MAPTOSPAWNUNITS
        items:
          STR_SOME_UNIT_SPAWNING_ITEM:
            - [0, 0, 0] # Position of the item in the map block
        fuseTimers:
          STR_SOME_UNIT_SPAWNING_ITEM: [0, 0] # Set all fuses on these items to 0
Since there is no "user" for this grenade item, the default spawnUnitFaction: -1 will cause the spawned unit to be an enemy - it is best to explicitly define this value for pre-battle unit spawning items.

7
OXCE Suggestions Archive / [Suggestion] Craft Weight Limits for Units
« on: August 05, 2018, 09:24:08 pm »
Based on a discussion with Yankes here on the 40k mod subforum, I'd like to propose a method for limiting the number of soldiers/units on a craft based on more than just their number and size.  Player craft get an optional ruleset paramter for unit weight limit and the sum of the defined weights for the armors on each unit has to be under this limit.  This would not completely replace the crew limit on craft as that has to be in place as a maximum limit for spawning units on the map, but it would allow for defining a "quality" of a unit or simulate a light craft not being able to carry as many soldiers in heavy power armor as soldiers in jumpsuits.

This could be accomplished by two parameters:
Code: [Select]
crafts:
  - type: STR_SOME_LIGHT_CRAFT
    unitWeightLimit: 220 # <-- This defines the weight limit for the craft, have a default of -1 to mean no limit
    soldiers: 10
    vehicles: 1

armors:
  - type: STR_POWER_SUIT_UC
    weightOnCraft: 44 # <-- This defines how much a unit in this armor 'weighs' for the sake of the limit

  - type: STR_NONE_UC
    weightOnCraft: -1 # <-- For an easily-defined default, -1 would mean look up the weight of the first item defined by "corpseBattle"
    corpseBattle:
      - STR_CORPSE # from xcom1 ruleset, STR_CORPSE has a weight of 22

  - type: TANK_ARMOR
    weightOnCraft: 88

  - type: HOVERTANK_ARMOR
    weightOnCraft: 110
In this example, the craft could take 220 / 22 = 10 soldiers wearing no armor but only 220 / 44 = 5 soldiers wearing either power suits or flying suits.  Any combination of soldiers in these armors would be allowed as long as they stay under this limit.  The limit would also apply for any tanks/HWP/auxiliary units loaded onto the craft - in this case it's set so that regular tanks weigh as much as 4 soldiers, the usual cost for loading a tank instead of soldiers, but the hovertank would take as much weight as 5 un-armored soldiers.  Note that if you had a unit with a weightOnCraft value of 20 or less that you would not be able to carry more than 10 units, that limit defined by "soldiers: 10" would still be respected.

Does this system make sense?  Are there ways it could be improved?  Would it bit a useful feature?

8
40k / Weapons and Armor Rebalance
« on: July 30, 2018, 04:03:42 pm »
Starting from some personal edits to weapons in my own campaign and iterating through to give some more useful tools for the Imperial Guard Operations mod, I've developed this rework for some of the weapons balance in the 40k mods.  As a disclaimer, I don't intend this to be a replacement to bulletdesigner's weapon design, more of a re-imagining of what can be done in the OXCE+ engine with these weapons.  The main changes I've made are:

  • Meltas use "shotgun pellets" with 0 spread to simulate a continuous beam and damage more armor, but need to reduce armor to almost 0 in order to do damage and they have shorter range plus a damage dropoff. The multi-melta has been made to fire two blasts instead of doing double damage and has longer range.
  • Bolter weapons that count as "double-barreled," the storm bolter and the assault bike weapon, fire twice instead of doing double HP damage.
  • The fire rate of the heavy bolter has been reduced so that the assault cannon can shine with a truly impressive rate-of-fire.
  • The sniper rifle AP rounds have been reduced in damage to make taking other weapons a more meaningful choice.
  • The shotguns have more pellets but do lower damage for each one, mostly so that the autoguns from the IG mod don't feel completely outclassed from the get-go.
  • Krakk rockets do more armor damage and ignore some armor, but have lower power.
  • Bayonets on Lasguns!
  • Almost all laser weapons now reduce the target's armor before doing damage like the melta (but not quite as good at it), but have lower power to compensate. Save for the lascannon, which is now the epitome of single-shot kill, but only has one shot per turn.
  • Pretty much all power armors can punch, not just the terminator armors.

When you install this mod, make sure it is lower on the list in your options screen than both the 40k mod and the Imperial Guard Operations mod, otherwise these changes will be overwritten and will do nothing for you.

9
OXCE Suggestions DONE / [Documentation] Spray Waypoints Explanation
« on: July 15, 2018, 12:09:57 am »
TL;DR: Hold CTRL+SHIFT while clicking to auto shot to spray and pray when it's enabled.

The newest release of OXCE+ includes a bit of code I wrote for "spray" autoshot attacks, and since it uses some keyboard shortcuts/mechanics not used anywhere else, I wanted to provide an explanation for how it works.  First off, under the hood the engine is using waypoints similar to those placed for firing a blaster bomb, then placing the shots from an autoshot attack spaced out evenly along this waypoint path as if you were able to separately click the firing position for each shot.  That attack looks like this:



The laser rifle from that demonstration has the following lines added to its ruleset:
Code: [Select]
items:
  - type: STR_LASER_RIFLE
    autoShots: 10
    sprayWaypoints: 2
In addition, once the auto shot is selected, I am holding the CTRL+SHIFT keys in order to start placing the waypoints; if I had not, the autoshot would have just fired all 10 shots at the first location clicked.  The second waypoint clicked did not need CTRL+SHIFT held as it automatically fires the attack when the maximum number of waypoints is reached.  If you have the confirm fire mode option turned on, then you will need to click one more time anywhere to start the attack.  As with the blaster bomb waypoints, right-clicking will remove the last one placed.

With this code, it is possible to have more than two waypoints:



The laser rifle from that demonstration has sprayWaypoints increased to 3 from 2.  As before, the attack automatically fires once I place the last waypoint.  If you'd rather stop before the last waypoint, holding CTRL+SHIFT while clicking to place the final waypoint that you desire will execute the attack with only that many waypoints.  In this example I stop at 2 waypoints even though 3 are available:



For modders: the default value of sprayWaypoints is 0, which means this behavior is disabled on that particular weapon.  In order to turn it on, you must give a weapon more than 0 sprayWaypoints.

10
40k / 40k Imperial Guard Operations
« on: June 11, 2018, 12:24:28 am »
This mod is now rolled into the base 40k mod and will no longer be supported separately from the base mod. Check out the new combined version on the mod portal or the forum download page!

I'm leaving this thread open to discuss Imperial Guard-specific content, but any new versions will be released as part of the base mod.


Dioxine, Solarius Scorch, and I have been greatly enjoying bulletdesigner's 40k mod, but have been thinking that the Imperial Guard gameplay could be improved.  Therefore, we're release this mod that creates a tech tree choice between playing as the Ultramarines from the original mod, or playing as a regiment of the Imperial Guard!  The mod includes new weapons, armors, and craft exclusive to the guard so you can truly overwhelm the enemy with superior numbers if not firepower.

Only the first "tier" of weapons and craft are done right now, so expect more content in the future!

To play this mod, make sure you have Meridian's and Yankes' OXCE installed as well as the base 40k mod by bulletdesigner.

It is recommended to start a new campaign with this mod if you've been playing without it, as it makes significant changes to the research tree.

11
OXCE Suggestions DONE / [Documentation] Soldier Transformations
« on: June 01, 2018, 03:45:36 pm »
Edit:  This is now officially a part of OXCE+; while the following description of the UI only applied to the preview version and is therefore obsolete, the ruleset description in the next post is up-to-date with the feature as it is in the official version.

I'm excited to announce a new feature for upcoming versions of OXCE+: Soldier Transformations!  These transformations allow for mods to define projects that allow for direct editing of soldier stats and types in ways previously only possible by save editing, including the possibility of raising your favorite soldier from the dead or creating clones of them!  As this is such a large new piece of code, I'm releasing a preview build of it here for testing and feedback along with a mod that showcases some of the capabilities of transformation projects.  The zip archive I'm attaching to this post is a standalone OpenXcom build with a windows executable and a mod for testing the new code - installation is just unpacking the archive and copying the original game files to the UFO folder, a process familiar to those of you who play Piratez or the X-Com Files.

In order to access the transformation projects, when a project is unlocked via research (similar to a manufacturing project), the button from the Soldiers screen that takes you to the Memorial screen will turn into a drop-down menu for accessing the Soldier Transformations screen, the Memorial, and psi training or physical training if those are available at a base.  It can also be accessed from the Memorial screen in a similar manner if you have any projects available for resurrecting or cloning your fallen soldiers, or from a right-click action on a facility in the basescape view if it is modded to do so.


Once you reach the transformation screen you'll be shown a list of soldiers that are eligible for your unlocked transformation projects at a particular base; any fallen soldiers eligible will show up at the bottom of the list in a different color.  From there, you can select a project from the drop-down in the lower-left corner of the screen that will filter the list of soldiers by those eligible for only that particular project.  In the mod attached here, I've created three different projects to try out - one to send a soldier off to training for a week to bring their firing accuracy up to the maximum possible starting accuracy, one to create a clone of a soldier using their starting stats, and one that will allow you to bring a soldier back from the dead, but at a loss of 25% of the stats they've gained.


Clicking on a soldier in the list with the project selected will bring up an allocation screen where you can preview what's necessary to start the project and, if the option is turned on from the Options menu, how the soldier's stats will change when the project is started.  Clicking the start button performs the selected project on the selected soldier, placing them in a transfer to that base (if defined in ruleset) and giving them recovery time (also if defined in the ruleset).


There are a huge number of possibilities for what you can do with these transformations - XCOM 2012-style MEC soldiers and gene modding?  Yep!  Transferring soldiers' consciousness into cybernetic killing machines?  Check!  Creating an army of undead from all the rookies you sacrificed down the ramp of the Skyranger?  You betcha!  So please test this new code out and let me know what you think, particularly with respect to the interface and what information you get from these screens - I want this to be as clear and fun a process as possible.

12
Since lobstermen can melee attack without a weapon and psionic aliens can still spam you when unarmed, I decided it was time for the player to get some special weapons!  The new code I'm documenting here allows the player to access an armor's specialWeapon, a unit’s meleeWeapon, or a unit’s psiWeapon.

Note: This requires an OXCE+ version published on or after 8 May 2018, otherwise the mods won't do anything.

There are two ways of accomplishing this with the following ruleset parameters:
  • specialIconSprite: -1 # defines an image from SPICONS.DAT for an item to use instead of the 'psi’ button that appears when using a MC’d psionic alien, default -1 means no icon
  • specialUseEmptyHand: false # true here allows this item to be accessed by clicking on a unit's empty hand when used as a special weapon, default is false

If an item is defined as an armor's specialWeapon, a unit's meleeWeapon or psiWeapon, and has either a special icon sprite or can be used in an empty hand, then you'll be able to use it!  There's the further limitation that the item’s battleType must be a firearm, melee weapon, medi-kit, motion scanner, psi-amp, or mind probe; no grenades, no flares, no ammo, and no corpses are allowed to be used as a special weapon.  If the item has a special icon, then it'll appear where the 'psi' button usually does, and can be accessed by clicking on that icon or pressing a hotkey for it, default 'Y'.  If the weapon can be used from an empty hand, just click/press the hotkey for that hand slot when nothing's there.  Both types support middle-clicking to bring up the ufopaedia article for the item if it's been researched, and the empty hand further supports pressing CTRL+M to bring up the preview for melee attack power.  If for some reason you have multiple items that are competing for one of these two access methods, the one displayed will be the first available from this list, in order: melee, psi-amps, firearms, medi-kits, motion scanners, and finally mind probes.

As for item behavior, using either of the buttons will bring up an action menu just the same as any other weapon, though firing animations won't use the item’s handSprite.  The AI already knows how to use melee weapons and psi attacks like this; the code adds use of projectile weapons, but only if the AI unit has no other weapon.  Player units can react with projectile special weapons but only if they have no other weapon in their hands.

If all of that was confusing, here are two example use cases that will hopefully make it clearer.  The first is simply giving X-Com agents the ability to punch with empty hands:
Code: [Select]
items:
# this item is what is used for the attack
  - type: STR_UNARMED_MELEE
    specialUseEmptyHand: true
    # the rest of the item definition procedes as usual, see the attached mod for more

# now, add the attack to X-Com armors
armors:
  - type: STR_NONE_UC
    specialWeapon: STR_UNARMED_MELEE
# the mod attached below does this for personal and power armor too

With this mod, all you have to do is click a soldier's empty hand and start punching away!

The second example puts a built-in gauntlet with a laser equivalent to the laser pistol on the power suit and flying suit:
Code: [Select]
items:
  - type: STR_UNARMED_POWER
    specialIconSprite: 3
    specialUseEmptyHand: true
    # the rest of the item definition is found in the mod attached below

armors:
  - type: STR_POWER_SUIT_UC
    specialWeapon: STR_UNARMED_POWER

  - type: STR_FLYING_SUIT_UC
    specialWeapon: STR_UNARMED_POWER

extraSprites: # get a new image for the icon
  - type: SPICONS.DAT
    width: 32
    height: 24
    files:
      2: Resources/spicon_brawl.png # 0 is used for the launch blaster bomb button, 1 for alien psi
    files:
      3: Resources/spicon_laserpistol.png

Both examples are contained in the mod attached below.

13
Released Mods / [OXCE+] Psi Adepts
« on: March 30, 2018, 11:18:13 pm »
After playing around with some scripting, I came up with a spellcasting resource system, and I wanted to share the fruits of that labor with the community.  This mod adds a new armor type, "ADEPT", made from the combination of a mind probe and a psi amp, that turns your soldiers into mages!  While it looks just like a standard jumpsuit, it's brimming with the latent psionic energy of your soldier - you can channel this energy into a beam attack or store it up to use as a shield to reflect alien plasma beams!

This mod requires OXCE+, so make sure you have that before trying it out!

14
With the release of OXCE+ 3.10, a few new AI behaviors have been added targeted at improving the enemies' use of weapons that have limited max range or use altered UFO Extender Accuracy ranges. The previous behavior when the AI was attempting to shoot with a weapon beyond its maximum range was that it'd select a firing mode and attempt the shot, but since this was not possible the unit would just stand there. The first change is an override to that behavior - respectMaxRange: true in the ai: ruleset will have the AI skip trying to fire when beyond the maximum range of the weapon, allowing it to move when otherwise it would stand still and attempt impossible shots.  If the original behavior is preferred on a per-unit basis, then waitIfOutsideWeaponRange: true can be set in that unit's ruleset, otherwise it defaults to whatever was chosen for respectMaxRange.

The second change is an extension to how the AI picks which firing mode it uses; the original behavior is to pick the firing mode based on set distances to the target and on whether or not the unit has the TUs to fire.  Setting extendedFireModeChoice: true in the ai: ruleset will make the AI use an algorithm to score each firing mode based on the distance to the target, the accuracy of each shot type at that distance, and the amount of TUs it will take to fire.  A higher score comes from a higher expected amount of damage at that range and means that firing mode will be preferred.  The exact workings of this scoring algorithm are documented with the Scout/Sniper AI feature.  Turning this behavior on overrides respectMaxRange: true (but not waitIfOutsideWeaponRange), as it already includes consideration of the distance to the target.

The last change alters how the AI picks a spot to move to if a unit can't shoot from where it's standing.  When extendedFireModeChoice: true is set and the unit's weapon has a maximum range shorter than the distance to the target, then tiles that are closer to the target will be preferred with an increase in 'score' proportional to the range of the weapon divided by the distance to the target. Note that this does not guarantee the enemy will try to close the distance, it's just a nudge in the right direction.

Here's an example ruleset for all of these features, works best if UFO Extender Accuracy is turned on:
Code: [Select]
ai:
  respectMaxRange: true #overriden by next line, but here for completeness. default false
  extendedFireModeChoice: true #default false

units:
  - type: STR_SECTOID_NAVIGATOR
    waitIfOutsideWeaponRange: true #Sectoid navigators will just stand there if their weapon is short-ranged. default false

items:
  - type: STR_PLASMA_PISTOL
    maxRange: 10 # Aliens will need to move much closer to use their pistols

  - type: STR_PLASMA_RIFLE
    maxRange: 15 # Aliens will need to move somewhat close to user their rifles

  - type: STR_HEAVY_PLASMA
    autoRange: 12 # Prepare for hails of heavy plasma fire ;)

15
OXCE Suggestions DONE / [Documentation] Up-/Downgrading Facilities
« on: January 23, 2018, 03:11:49 am »
New feature documentation time!  With a recent code addition to OXCE+, you can now 'upgrade' existing facilities by building over them, and you can also make it such that removing a facility can 'downgrade' it to another facility.

The rules for this feature are as follows:

When a facility is removed, the ruleset is checked for a list of facility names leaveBehindOnSell
  • If the first facility on the list is equal to the size of original, then that facility is placed over the previous one
  • If the list contains all size 1 facilities, then the list is iterated over, placing facilities until the size of the previous is reach
  • If the sizes don't match one of the above conditions, an exception is thrown letting the player/modder know the sizes don't match up
The facilities left behind are given a build time according to the previous facility's removalTime:
  • If removalTime: 0, then the facility is instantly built (default behavior)
  • If removalTime: -1, then the build time is set to the new facility's normal build time
  • If removalTime is a number greater than 0, then the build time for the new facility is set to that number
Any facility placed by this left behind method is flagged for having a facility there previously; this flag makes the facility count as already built for base connectivity, makes it so the facility cannot be removed until it is fully built (this is to represent deconstruction time), and makes the new facility have it's map placed during base defense missions.

When a facility is built, the buildings under where it's being placed are checked for the tag canBeBuiltOver; if the tag is true, then new facility can be built over the previous one.  The refund for removal of each of the facilities being replaced is applied, and the build time for the new facility is reduced by the build time of each of those previous facilities, normalized by the size of the new facility.  This build time can never be reduced below 1 day.  The new facility is flagged similarly to ones left behind after being removed, unless all the facilities being replaced are under construction.
You can further specify which facilities one building is allowed to replace by the buildOverFacilities list - if this list is empty, no filter is applied.  Otherwise, the facilities which are being replaced have to be on this list, otherwise the facility building is blocked.  Upgrading an existing facility is also blocked if all of the other ones connecting to it are under construction, even if build queue is turned on.

I'm attaching a mod to test this code - many of the beginning facilities will leave corridors behind when they're deconstructed, corridors can be upgraded to living quarters and any other facility, general stores can be upgraded to anything but living quarters, and small radar can't be built over anything.  You can also build over hangars, but only with other hangars; this is just to test the code with 2x2 buildings.  The sectoid research mission at the beginning of the game is replaced with a retaliation mission to make sure the base maps are generated correctly.

This code also adds the following messages to let you know exactly why a facility can't be built:
Code: [Select]
#BasescapeState.cpp
  STR_CANNOT_DISMANTLE_FACILITY_UPGRADING: "CANNOT DISMANTLE FACILITY!{SMALLLINE}Facility cannot be removed during upgrading."
#BaseView.cpp
  STR_CANNOT_UPGRADE_FACILITY_ALREADY_UPGRADING: "CANNOT BUILD HERE!{SMALLLINE}Existing facility is already being built over."
  STR_CANNOT_UPGRADE_FACILITY_WRONG_SIZE: "CANNOT BUILD HERE!{SMALLLINE}Selected facility must completely cover existing facility."
  STR_CANNOT_UPGRADE_FACILITY_WRONG_TYPE: "CANNOT BUILD HERE!{SMALLLINE}Existing facility cannot be upgraded over by selected facility."
  STR_CANNOT_UPGRADE_FACILITY_DISALLOWED: "CANNOT BUILD HERE!{SMALLLINE}Existing facility cannot be built over."
  STR_CANNOT_BUILD_QUEUE_OFF: "CANNOT BUILD HERE!{SMALLLINE}Connecting facilities must finish construction first."

Pages: [1] 2 3