OpenXcom Forum
Modding => OpenXcom Extended => OXCE Suggestions DONE => Topic started by: ohartenstein23 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:
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:
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.
-
Reserved for sample mods.
-
this is amazing. thanks.
-
Long live the returned ability of the CELATID to clone! :D
-
So now we can have map30 in X-Com.
-
sounds awesome.. think there are a few sprites floating around on these forums that have been waiting for this feature.
one thing that is unclear to me... can this be used to reliably auto spawn enemies on some modder-determined turn n, mid-mission? My thought here would be to have the alien reproduction map items in some UFOs/bases spawn an alien maybe after ~20 turns, or even better if it could be a range like 15 to 25.. is there some way to achieve this here, or maybe cobbled through other features?
would be a great way to add a vanilla-esque sense of urgency to some missions, or secondary objectives etc.
-
One question for code, why you did:
if (ammo->getClipSize() > 0 && item->getClipSize() > 0)In `BattlescapeGenerator::addXCOMVehicle` there is only
ammoItem->setAmmoQuantity(v->getAmmo());Should both behave same?
-
The first snippet is from the validation for loading vehicles onto the craft from the basescape; since the unit doesn't exist as a vehicle loaded on the craft before spawning it, I can't just check a 'vehicle' data structure for the ammo.
-
Right, I miss that it get value from vehicle not item.
-
This looks very cool can't wait to try this
--- posts merged. Please don't make me do this, I have a family ---
Hmm got this working, which is awesome, have a question though, is there any way to make the unit recoverable as its spawner. For instance if it was pokemon or turret, and that unit survived you'd want to reuse it. Any ideas?
-
Hmm got this working, which is awesome, have a question though, is there any way to make the unit recoverable as its spawner. For instance if it was pokemon or turret, and that unit survived you'd want to reuse it. Any ideas?
It certainly works for civilians, just like with civilians who spawn normally:
units:
- type: STR_COUNCIL_MEMBER
civilianRecoveryType: STR_COUNCIL_MEMBER
I haven't tried it with the other sides.
-
Ah I see where I went wrong sorry, I was using a pre-existing unit, so instead I need to create my own recoverable unit, thanks!
-
Yes, this will work for neutral/civilian units, but unit/corpse recovery is specifically disabled for player-controlled units spawned in this manner.
-
Thus technically, for example, a mod can be implemented where the unit carries a player-controlled micro-UAV, that would allow terrain scouting. The UAV can be fired from its own special launcher. After battle it can be recovered and reused again on the next battle. And this won't count towards the unit limit on crafts.
Am I about right or I need more coffee :) ?
-
No, player-controlled units spawned by this code won't be recovered. What you can do is make a 'launcher' for the micro-UAVs and then make the 'ammo' that spawns the UAV cost very little, but the reload is expensive enough TUs-wise that you can't do it during battle so you need multiple launchers if you want multiple UAVs.
-
Ah this makes me sad, could the unit/corpse maybe carry drop an additional corpse on it that is recoverable?
Maybe the unit could on death become an enemy "zombie" which then spawns a recoverable body?
Edit: No wait that doesn't make sense if it lives you can't have it if it dies you shouldn't have it :(
Could it be a civilian that is automatically mind-controlled?
That's probably not a thing ::) :P
Well, it's still cool for bio-weapons, like apoc leech-cannons, alien proximity eggs, etc. look forward to seeing what people do with it
-
The recovery limitation is that the live unit and any items in the unit's inventory are removed from the game before anything is counted to bring back to base, but this only holds for units spawned under the player's control. If the unit dies or falls unconscious, then items it drops besides its corpse can be recovered.
-
The recovery limitation is that the live unit and any items in the unit's inventory are removed from the game before anything is counted to bring back to base, but this only holds for units spawned under the player's control. If the unit dies or falls unconscious, then items it drops besides its corpse can be recovered.
Thus on the micro UAV example, the spawned unit can have a limited span, with either stun or (better) damage per turn. Then after a few turns it drops "dead". Then it's recovered after the battle ends. However if the battle end with the unit still in the air, then no recovery is possible. Alternatively, the units can be 100% expendable, if made cheap enough can be a good alternative to scouting for heavy encounters.
-
Yeah I was thinking you could definitely give it some sort of bleed, but yeah if the mission ends before the device is out of juice you'll lose it, ideally you'll only want the device returned to the craft if it's intact as well as if it's snoozing.
I think I remember there were mods out there that allowed you to recover damaged armor, but I'm guessing they just used alien-corpses leaving us with a similar problem. Without being able to confiscate the inventory of the unit, or better yet the unit itself, there doesn't really seem a fix without making them disposable as stated.
Still useful, but not ideal for something like a portable turret, servo-skull, pokemon, RC car, etc, unless they're AI driven civilians i guess (which isn't awful).
-
Can I spawn item-units into a X-Com craft map block?
Like this:
crafts:
- type: STR_TRANSP
[...]
battlescapeTerrainData:
name: TRANSP
mapDataSets: *mapDataSetsXcomCraft
mapBlocks:
- name: TRANSP
width: 10
length: 20
items:
STR_ROBOTURRET_XCOM_PLASMA_SPAWNER:
- [2, 9, 0] # x, y ,z Position of the item in the map block
- [7, 9, 0]
fuseTimers:
STR_ROBOTURRET_XCOM_PLASMA_SPAWNER: [0, 0] # Set all fuses on these items to 0
-
Yes! We use this in the 40k mod to give ground vehicles turrets.
-
Yes! We use this in the 40k mod to give ground vehicles turrets.
Then... I think I found a bug with the vertical terrains: the item-units are spawned normally when the craft is on a normal terrain but I get Segmentation Fault error when starting the mission on a terrain that uses vertical levels. Maybe the Z coordinate of the item-unit defined for the craft map goes crazy.
But of course there is also a large probability that the issue is in my terrain/script.
-
Can you upload an example of this? Items should be placed correctly even with vertical levels. Does the log file after you get the crash say anything about the height of the map?
Edit: I was able to reproduce the crash by uncommenting the spawners on the Transporter and using it on the Alien Gate Assault mission. It looks like the height offset of the craft is getting added to the z-position of the items twice, placing your turrets off the top of the map. I'm working on refactoring the verticalLevels code and this is already fixed in my WIP version of OXCE. In the meantime, if you increase the height of the deployment to 11 and leave the height of the verticalLevels at 9, the turrets will be spawned without a crash. They'll also look a little weird since they'll fall from the top of the map to their intended positions.
-
Can you upload an example of this? Items should be placed correctly even with vertical levels. Does the log file after you get the crash say anything about the height of the map?
Edit: I was able to reproduce the crash by uncommenting the spawners on the Transporter and using it on the Alien Gate Assault mission. It looks like the height offset of the craft is getting added to the z-position of the items twice, placing your turrets off the top of the map. I'm working on refactoring the verticalLevels code and this is already fixed in my WIP version of OXCE. In the meantime, if you increase the height of the deployment to 11 and leave the height of the verticalLevels at 9, the turrets will be spawned without a crash. They'll also look a little weird since they'll fall from the top of the map to their intended positions.
I see thanks.
Does this also mean I can make brainsuckers rain onto the map?
-
Probably, just put the spawn item high enough on the map blocks.
-
Anyone found some trick to make X-Com spawned units recoverable?
I just finished a portable robot only to discover that I can't recover it in any way aaahhhh
-
Anyone found some trick to make X-Com spawned units recoverable?
I just finished a portable robot only to discover that I can't recover it in any way aaahhhh
Using "civilianRecoveryType".
-
Using "civilianRecoveryType".
It works! Thanks a lot.
-
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.
So, things that count as “attacks”.
Well, it's still cool for bio-weapons, like apoc leech-cannons, alien proximity eggs, etc. look forward to seeing what people do with it
Mods use this for arbitrary spawns pre-placed on map as “grenades”. That could also be invisible and timed or toggling / unreliable, perhaps.
Hmm, maybe proxy mines as ambush / wildlife type spawns?
Doom spawn cubes / Half-life Nihilant’s teleports as “guns”…
Also, spawning does not interfere with the usual functionality (such as explosion, which goes off before the unit is spawned). I can only think of 2 uses: “splat! lol, telefrag” and special effects of “summoning in a puff of smoke” sort.
-
One problem i encounter:
"spawnunit" does not work with corpseitem, used with "specab".
It leads to broken functionality with resurrecting units. (like phoenix) Only working decision now for that is an item, placed in a unit's pocket. But this grenade-item will explode and spawn new unit not only after wearer's death, but after stunning too. So these units become non-capturable, or bugged.
Two ways to fix it i see:
- first, add spawnunit functionality to corpsess with specab.
- second, make some kind of built-in weapons dropable. Dont know how to do it, really.