I sat down with Dioxine and we have compiled a list of features that we would like to see implemented the most. It is here:
https://docs.google.com/document/d/1pUZBoVKeZmfXUwIm4-FDRLx_fIISGFrp1131DLfyO40/edit?usp=sharing
Each feature contains a brief description of how it should work.
Many of these are old and already mentioned in places. Also, some of them are more sensible/easy than others. But all of them are there for a specific, practical reason, ie. there are actual plans for their use (in Piratez and X-Com Files).
Hopefully this will be of some use.
If possible, I would like to recommend to move random treasure lists to a higher priority. Because it looks (to me, a layman) like a relatively simple job, and I know it'd be colossally beneficial. For example Piratez has many copies of the same ship with the only difference being some items laying on the floor; this is a very messy and time-consuming method.
- type: STR_VESSEL_CC_CLOUDCAR
mapBlocks:
- name: VESSEL_CC5
randomizedItems:
- position: [6, 2, 0]
amount: 30
mixed: false
itemList: [STR_SOME_JUNK, STR_OTHER_JUNK]
- position: [4, 3, 0]
amount: 5
mixed: true
itemList: [STR_RANDOM_ITEM_1, STR_RANDOM_ITEM_2]
width: 10
length: 10
items:
STR_UFO_POWER_SOURCE_SMALL:
- [6, 2, 0]
STR_FIRE_EXT:
- [4, 3, 0]
Yes, it looks very good.
Do I understand this correctly: if I set Mixed to false, I'll get either 30 STR_SOME_JUNK or 30 STR_OTHER_JUNK, with a 50% chance for either. If I set it to true, then I'll get 30 items altogether, some of them STR_SOME_JUNK and some STR_OTHER_JUNK. Yes?
For Yankes (he already changed this part of code, I shouldn't be messing with it)
-------------
- Global damageAlter per type
- Custom damage types
- More than 1 damage type per bullet
Interesting (I'll put it on my todo list)
-------------
- Terrain destruction by melee
- Environmental effects
- Starting conditions by terrain ... except for allowedCraft, since terrain is unknown at take-off time
- Exclude a soldier type from the promotion system/military ranks
- Exclude a soldier type from driving
- Soldiers as pilots
- Sick Bay facility
Hmm? (on todo list with low prio)
-------------
- Terrain trampling by AI units... would need to look at AI... which I don't want
- Random Treasure Lists
- X-Com craft crash sites
- Unhardcode approach/disengage speed per ship
- Definable types of Alien Containment
Meh! (not my taste...)
-------------
- Custom factions in battles
- Alternate vision modes
- Everyone can do everything
Huh? (I have no knowledge of this part of the code, can't say if possible or not)
-------------
- Vertical maps
- type: STR_SOLDIER_S
allowPromotion: false
STR_RANK_NONE: "-"
What about "Integrated HWPs"? Basically, craft could have HWPs pre-attached, which spawned in the same place relative to the craft every time. It would make stuff like gun turrets possible. Imagine: Do you bring 14 men, or 6 men and a craft capable of fire support?
EDIT: also, I wanted to add possibility to limit number of facilities of certain type in a base (and also globally across all bases)... would that be something interesting for you?
Exclusion of soldier types from promotions is now possible: (...)
@Solarius: how should the Sick Bay facility work?
EDIT: also, I wanted to add possibility to limit number of facilities of certain type in a base (and also globally across all bases)... would that be something interesting for you?
That reminds me... if you don't want removing wounded soldiers on the training list, how about at least marking in red those who are signed in, but cannot profit from training anymore? (either due to wounds, or reaching facility's caps).
Not a bad idea.
Though I think it was done best in Apocalypse, where you can go over the max slots, but the training efficiency drops. It would probably be hard to do though.
Depends on how micro-managey you want to get.
Still, such script would need to account for wounded/maxed out soldiers before arriving at final stat gain chance.
Such limit, at least per base, should be controllable with other facilities (eg. 2 Workshops/base for each Power Plant +1 workshop free, or 20 buildings total allowed for each Command Center + 20 free), but even if not, certainly useful!
That reminds me... if you don't want removing wounded soldiers on the training list, how about at least marking in red those who are signed in, but cannot profit from training anymore? (either due to wounds, or reaching facility's caps).
As for the hospital, I'd use the training facility interface. Hospital has capacity, people signed in heal x amount of sick leave each day.
However, this would also probably require unhardcoding the basic healin formula for proper balancing (what I see is formula of number of sick days infliced = (a%....b%)y + (c%...d%)z*e, where y is the amount of hit point lost, and z is percentile amount of health lost (so, setting y to 0, you will have people with high hp heal back as fast as those with low hp).
Also, with cut down recovery times by a factor of 2 or 3, due to hospitals, we can go back to the idea of 'stress from combat' :) (but I'll leave this for later time and better place).
Yes, I think I've explained this before... This can be done by the reversal of "required function" for buildings, which is "forbidden function". So if you want to disallow more than one HQ per base, you can give it the function BASE_HQ add also the flag FORBIDDEN_BASE_FUNC: BASE_HQ so that it forbids itself.
The limit I want to do is a much simpler concept and already allows more... for example allowing max 3 buildings per base (e.g. max three sick bays). And by setting it to one, it encompasses all functionality the "forbids" function can realistically give you.
That particular example is however something I really don't like. The Power Plant is totally useless and annoying. It doesn't serve any purpose other than take valuable space.
User option to automatically remove the soldiers from training is now implemented.
The limit I want to do is a much simpler concept and already allows more... for example allowing max 3 buildings per base (e.g. max three sick bays).
The "forbids" function is fundamentally flawed and simply doesn't work for anything else than making singletons from certain facilities. All other (potential) use cases can be workedaround by the player. I have illustrated this on examples in other thread.Right now `forbidenBaseFunc` prevent building other buildings that give you listed functionalities. If you have already this functionality in base you cant build that building in first place. How could be this workaround? Only way to have some forbidden functionality is that building that prevent it, itself provide it. This mean it could be only one.
The limit I want to do is a much simpler concept and already allows more... for example allowing max 3 buildings per base (e.g. max three sick bays). And by setting it to one, it encompasses all functionality the "forbids" function can realistically give you.
i confess i lost track of things a bit, so forgive me for the stupid question: are these features going to be integrated into OXC extended?
Some (mostly not GUI related) changes will be backported to OXCE... the rest will stay in OXCE+.I see, thanks.
Is there any specific reason why you would prefer OXCE over OXCE+ ? If something is bothering you, I can make it optional :)
I see, thanks.
I'm on vanilla OXC, I'm largely ignorant about OXCE--OXCE+. I just wanted to understand a little the situation, because I've been "lost in pixelation" for months and I was wondering if it made sense to make a comment (on the wishlist) or not.
facilities:
- type: STR_FIELD_HOSPITAL
sickBayAbsoluteBonus: 0.75
sickBayRelativeBonus: 0.0
- type: STR_SURGERY_ROOM
sickBayAbsoluteBonus: 0.25
sickBayRelativeBonus: 1.0
- type: STR_REGENERATION_ROOM
sickBayAbsoluteBonus: 0.0
sickBayRelativeBonus: 10.0
- type: STR_GOAULD_SARCOPHAGUS
sickBayAbsoluteBonus: 90.0
sickBayRelativeBonus: 0.0
I like it, but good luck explaining such limits to the player... Well I mean, that's my job, and I dread it :)
- type: STR_ALIEN_CONTAINMENT
maxAllowedPerBase: 3
STR_CANNOT_BUILD_MORE_OF_THIS_FACILITY_TYPE_AT_BASE: "The maximum allowed number of facilities of this type in this base has been reached!"
Great!
STR_NO_WOUNDED: "-"
In explaining, I meant on this forum, about WHY ONLY THREE??? ;)
People are going to ask, why only a limited number of a given structure is allowed per base. Nvmd, I was just joking.
Soldiers as pilots
If you want to send a fighter, there must be a soldier on board. This is particularly important for the Piratez.
The soldiers’ stats give modifiers for air combat.
If there are more people on board, the first one on the list is the pilot.
crafts:
- type: STR_VENTURA
soldiers: 18
pilots: 2
vehicles: 2
STR_NOT_ENOUGH_PILOTS: "Not enough pilots!{NEWLINE}Minimum: {0}"
Question:
- how exactly should the stats of the pilot(s) modify the air combat?
(Please don't say, you want to be able to use a script to program it yourself based on all imaginable attributes.)
Okay, so absolutely bare minimum needed IMO. Taking numbers from the air, since I have no possibility to test these formulas in practice, obviously. It's only a proposition.
Craft Weapon Accuracy: + Firing Accuracy * 0.2 (this makes the bonus a major one for cannons, small for missiles).
Craft Dodge (in effect, a flat minus to ufo's hit chance): + Reactions *0.25 (halves hit chance for normal UFO, if you have 117 Reactions, before any craft dodge bonus. Low enough to be acceptable even for the clumsiest of crafts, but can make a major difference for hi-end crafts).
Craft Approach/Disengage Speed: x/sec, where x now is 0.25, and I think it could be 0.1+(Bravery *0.004), giving 0.14 for 10 Bra, 0.26 for 40 Bra, and 0.5 for 100 Bra.
Well, you can build only one Access Lift, and nobody is asking why? :)
Also no secondary attributes for the pilot stats?
About approach/disengage speed... wtf is that even? I haven't looked at it yet, but what is the general idea and what does vanilla do at the moment? Does it somehow decide when and if the UFO is outrunning the interceptor? Cos that's the part I never understood :)
In explaining, I meant on this forum, about WHY ONLY THREE??? ;)Leave that to me, I can come up with some good arbitrary explanations for why there are limitations. For sick bays the explanation could be a limitation of power, as it would be easy to presume a surgery room requiring more constant energy (for healing your runts 24/7 and maybe your wounded pilots if that ever becomes a thing) than another room like Stills and cargo holds. Just a thought. Hopefully that helps a little!
Craft Approach/Disengage Speed: x/sec, where x now is 0.25, and I think it could be 0.1+(Bravery *0.004), giving 0.14 for 10 Bra, 0.26 for 40 Bra, and 0.5 for 100 Bra.
Okay, so absolutely bare minimum needed IMO. Taking numbers from the air, since I have no possibility to test these formulas in practice, obviously. It's only a proposition.
Craft Weapon Accuracy: + Firing Accuracy * 0.2 (this makes the bonus a major one for cannons, small for missiles).
Craft Dodge (in effect, a flat minus to ufo's hit chance): + Reactions *0.25 (halves hit chance for normal UFO, if you have 117 Reactions, before any craft dodge bonus. Low enough to be acceptable even for the clumsiest of crafts, but can make a major difference for hi-end crafts).
New formula:
Accuracy bonus: (Firing - 55) * 0.4
firing=40 => -6 %
firing=55 => 0 %
firing=70 => 6 %
firing=120 => 26 %
Dodge bonus: (Reactions - 55) * 0.6
reactions=40 => -9 %
reactions=56 => 0 %
reactions=72 => 10 %
reactions=100 => 27 %
All attributes are taken without armor modifiers.
I like this, can't think of anything that would be missing.
So, it looks like my archers are going to double as Bonny pilots now. :)
EDIT: I understand dogs can't be pilots? I mean, when they are redone as races, we will be able to exclude them from piloting?
Also no secondary attributes for the pilot stats?
Would it be difficult to designate 'roles' for ships with interception capabilities and multiple Hand slots?
For example you have a Gunner slot which governs the Accuracy bonus, and a Pilot slot which governs the approach speed and Dodge bonus.
It is a small thing admittedly, but would be a nice touch.
Yeah, I was thinking of this a lot.
The last people/person is not the worst... they should anyway be the last to step off the craft... you want your pilots alive :)
Forgot to tell you, but I came up with the same idea independently :). Craft deploys were long crafted with Pilots being the last guys on the craft in mind (that's why last hand on the Airbus spawns near the console, etc.). So it's all cool :) I especially like the way some ships may need multiple pilots! Um, but whose stats are taken into account? The best of all pilots? (that'd be the best I think, so multi-pilot ships would have an advantage - select a specialist with high bravery, another one with high Firing, and the last one with high reactions!)
Would it be difficult to designate 'roles' for ships with interception capabilities and multiple Hand slots?
For example you have a Gunner slot which governs the Accuracy bonus, and a Pilot slot which governs the approach speed and Dodge bonus.
It is a small thing admittedly, but would be a nice touch.
Currently, the skills of all pilots are averaged.
Maximum from all pilots is also a good idea... I'll let people respond what they think would be better for the game (not better for the player, since that's clear).
It's not difficult to implement.
It's difficult to display/put it somewhere on the GUI(s)... if you prepare good mockups, we can discuss it further.
EDIT:
- [DONE] Soldiers as pilots
- [DONE] Exclude a soldier type from driving
- [DONE] Unhardcode approach/disengage speedper ship..per pilot(s)?
The rest will take longer, as my holidays are slowly coming to an end.
The "pilots are the last deployed" thing is going to mess me up though.
Cool stuff! We're moving well into a RPG territory!
The "pilots are the last deployed" thing is going to mess me up though. Normally my last people are snipers with the best firing accuracy I can get (good!), little regard for bravery (if you berserk all alone on top of the Bonny, there's nobody to hurt, so I don't care much compared to frontlines) and low reactions (if you've got good ones, you are at worst in the midfield. Long Range reaction firing is useless since snap accuracies decrease so much with range. If snipers could effectively reaction snipe, that'd be different...).
How about checkmarks in the crew list allowing you to pick your pilots?
1. new flag on craft to decide whether to take average or max stat (if multiple pilots)
2. ability (and necessity!) to choose pilots... except for case, when selected crew size is equal to amount of required pilots (all will be selected automatically... hopefully useful for interceptors)
STR_ADD_PILOT: "Add a pilot"
STR_REMOVE_ALL_PILOTS: "Remove all pilots"
STR_SELECT_PILOT: "SELECT A PILOT"
I just did that and realized that it is stupid during testing.
If you need for example 2 pilots... one of them has max stats and second has min stats... the max stats of the first pilot would be used and second pilot would make no difference. That defies the purpose of requiring a second pilot.
So, I will revert the change and use average stats as per now.
If we start dividing them into pilots and gunners, why not also add navigators, technicians and maître de cabin? ;) And of course one pilot must be the captain and the other one "number 1".
Because it's kind of silly to have the ace pilot's terrible accuracy mess with the ace gunner's dead on aim, or vice versa in terms of piloting, and because shooting and piloting are the two skills actually being tested/utilized by the game.
Depends how the craft is controlled. What you say is true for a craft that has separate turrets, but we don't have such crafts. In a 2-seater, like attack helicopter, cooperation between pilot and gunner is important; gunner's terrible accuracy does mess with ace pilot's aim,
- Terrain destruction by melee
- Environmental effects
- Starting conditions by terrain ... except for allowedCraft, since terrain is unknown at take-off time
- Definable types of Alien Containment
- Alternate vision modes (simple heat and psi vision)
So tomorrow I will be sitting in a car, train, another train, tram, bus, plane, train and a bus for about 15 hours...
... which two of the following would you want next?Code: [Select]- Terrain destruction by melee
- Environmental effects
- Starting conditions by terrain ... except for allowedCraft, since terrain is unknown at take-off time
- Definable types of Alien Containment
- Alternate vision modes (simple heat and psi vision)
Also, can you tell me more about how should the environmental effects work?
- is it just plain hp damage per turn? or...
- is it definable type of damage? e.g. 50 plasma?
- do armors and resistances count?
- does it apply to civilians and aliens too?
- does it create fatal wounds?
- etc.
Wait what?
Also, the pilot's accuracy should be utterly irrelevant if you have devoted gunners concerned exclusively with the weapon systems.
- Hit location (side and bodypart) needs to be rolled for randomly, unless explosive damage
Depends how abstract is the accuracy stat (very abstract in this case). If aiming involves not only aiming itself, but also pointing the nose of the craft towards enemy's ass and keeping it that way, crappy pilot WILL interfere with gunning efficiency. This would only be untrue for multiple, independent weapon systems. Crafts in this game do not generally seem to be like that.
Terrain destruction by melee looks like an important thing, so we can do away with magic hammers.
But if we're talking about enviro damage, maybe it's better to do 'starting conditions by terrain'.
Second would be taking a stab at enviro effects, not sure what to say. It has to be done well (even by small steps) or not done at all. What do we need:
- Chance to apply damage per turn;
- a 'Weapon' which applies damage (having it as a weapon solves many, many problems IMO, allowing for full definition of everything and keeping crashes at bay, since weapon engine is working). This weapon can be any battletype 1, and auto-hits (yes, I don't have anything against explosions centered on units, if a modder wishes so). Using weapon engine solves most of our problems, as things like armor efficiency and damage type can be defined.
- Hit location (side and bodypart) needs to be rolled for randomly, unless explosive damage
- Toggle who is affected. 0-all (default), 1-player only, 2-player+civvies, 3-player+enemies
Last question:
- should this weapon actually create a projectile with animation and sound effects?
- or should I skip that and just do the damage? (in this case I will have more control over the hit location... and probably easier job with "hidden movement" overlay... and it will be instantaneous... waiting a minute until all 80 deep ones and lobstermen get hit may be a little annoying)
Proper and effective orientation of the craft is more the purview of actual piloting though; if you would include that functionality as a component of firing accuracy it seems like a bit of a stretch. Further, even if we assume that's true, for those ships with say 3+ crew slots (in excess of a pilot or pilot + co-pilot/gunner), we're definitely getting into independent rather than fixed weapon systems; that's like B17 territory.
Show me that B17 in Piratez. About the only craft which we can safely assume has independent turrets is the Conqueror, and there's little sense in adjusting everything for a single craft. Also, where is that 'actual piloting' if not in Firing Acc? It is the general 'attack' stat here, just like reactions are general 'defense' stat and bravery is general 'initiative' stat. If we want to stay on this level of abstraction, without going down into more detailed setups, you have no comparable solution. And more detailed setups would require kicking out the whole super-simple air combat model and replacing it with something else.
Reactions and Bravery appear to be the 'piloting' stats as they actually govern the piloting functions.
Pilots governing accuracy might make sense for 1-2 man interceptors (because small interceptors are more likely to have fixed weapons and responsibilities for piloting and gunning tend to be shared), but not much else.
Also, pretty much any craft that goes beyond the typical 1-2 man interceptor crew (whichever they happen to be) would approach B17 territory. Beyond the 2 man mark, you don't need any more pilots, but gunners? Sure. Also, keep in mind that multi/omni-directional turrets and other forms of non-fixed weaponry don't need to necessarily be massive gunblisters; with future-tech they can actually be quite compact.
That's what you say. I don't agree since accurately firing at the enemy is also a function of general 'piloting'.
1-2 man interceptors happen to be the mainstay of this game's fleet. As for bigger craft, they're still quite small and do not posses any independent turrets. If extra crew is needed, their functions are of support nature, like electronic warfare or channeling power between weapons, shields and engines, or other engineering functions. As such they would have the impact on overall performance.
AI modules is what we had from 1994 to 2016... it's like saying " thanks meridian for implementing a feature nobody needs".
What if I have a bunch of mouthbreathing rookie retards in several of my many interception/manufacturing bases that are handily outperformed by upgraded pilot Slave AIs?
Like I said earlier, even the best Slave AIs would be outperformed by a (near) fully developed gal, but they would handily beat out pretty much anyone else, and you'd have several upgrade levels, so you don't start out with an effective 130 firing accuracy/90 reactions module.
Exclusion of soldier types from promotions is now possible:Code: [Select]- type: STR_SOLDIER_S
allowPromotion: false
Technically, these guys are rookies.
Instead of rookie, description STR_RANK_NONE is used everywhere.
For promotion mechanics, these soldiers don't exist... i.e. cannot be promoted and also don't count into number of soldiers when determining promotions eligibility.
Translations:Code: [Select]STR_RANK_NONE: "-"
Should these unfortunates receive commendations or not?
- type: STR_PSI_VISION_ARMOR
psiVision: 12 # sees everybody through everything at max 12 tiles
- type: STR_PSI_VISION_IMMUNE_ARMOR
fearImmune: true
- type: STR_HEAT_VISION_ARMOR
heatVision: 60 # 60% of smoke is ignored
Psi VisionCode: [Select]- type: STR_PSI_VISION_ARMOR
psiVision: 12 # sees everybody through everything at max 12 tiles
- type: STR_PSI_VISION_IMMUNE_ARMOR
fearImmune: true
Noise Vision
How about just use motion scanner... it detects movement, which produces noise.
Heat VisionCode: [Select]- type: STR_HEAT_VISION_ARMOR
heatVision: 60 # 60% of smoke is ignored
Does it mean that fearImmune: true makes a unit invisible to psi vision?
Q1. Is fearImmune an innate ability of 2x2 units? (I know I can impart/take away this ability with Yankes' commands).
Q2. Does PsiVision in any way interact with normal vision, predator vision, night vision, active camo? (I assume not).
Q1: no, that's bleedImmune... I specifically took the one, which didn't have hidden defaults... or would you prefer bleedImmune?
No, you've made a good choice. fearImmune is something different than effective fear immunity, given by 110+ Bravery, right?
Also, fearImmune is a separate boolean attribute, not affected by Bravery. It was introduced by Yankes and if a unit has it set to true, their morale doesn't drop, ever, regardless of bravery.
Zombification result per target
Zombified humans turn into zombies. But zombified dogs should turn into zombie dogs, REapers into zombie Reapers, etc.
Q1.
Ehm, so I was wrong... fearImmune does get pre-set for 2x2 units to "true".
Just like bleedImmune, painImmune and zombiImmune. But you can easily override it...
Zombification result per target
Zombified humans turn into zombies. But zombified dogs should turn into zombie dogs, REapers into zombie Reapers, etc.
Isn't it like, splitting hairs? Just make them zombiImmune as the chryssalid is clearly custom-tailored to work on humanoids only.
Ugh, yeah, I never knew there was such a flag. :P
facilities:
- type: STR_ALIEN_CONTAINMENT
aliens: 15
prisonType: 0 # default
- type: STR_PRISON
aliens: 30
prisonType: 1
- type: STR_ANIMAL_CAGES
aliens: 100
prisonType: 2
- type: STR_HAREM
aliens: 10
prisonType: 3
items:
- type: STR_CHRYSSALID_TERRORIST
liveAlien: true
prisonType: 0 # default
- type: STR_GUILD_NAVIGATOR
liveAlien: true
prisonType: 1
- type: STR_BLOOD_DOG_TERRORIST
liveAlien: true
prisonType: 2
- type: STR_MAGICAL_GIRL
liveAlien: true
prisonType: 3
# 0 = alien containment
# 1 = prison
# 2 = animal cages
# 3 = harem
#Debriefing
STR_CONTAINMENT_EXCEEDED: "ALIEN CONTAINMENT LIMITS EXCEEDED!{SMALLLINE}Insufficient containment space at {0}. You must remove excess aliens from containment (who will then die)."
STR_CONTAINMENT_EXCEEDED_1: "NO MORE ROOM IN PRISON!{SMALLLINE}Ran out of cells in {0}. We must throw excess prisoners out!"
STR_CONTAINMENT_EXCEEDED_2: "NO MORE SPACE IN THE CAGES!{SMALLLINE}If you don't tidy up in {0}, the animals will start killing each other!"
STR_CONTAINMENT_EXCEEDED_3: "HAREM IS FULL!{SMALLLINE}Not enough space at {0}. What are you waiting for?"
#Transfer
STR_NO_ALIEN_CONTAINMENT_FOR_TRANSFER: "NO ALIEN CONTAINMENT FOR TRANSFER!{SMALLLINE}Live aliens need an alien containment facility in order to survive."
STR_NO_ALIEN_CONTAINMENT_FOR_TRANSFER_1: "THIS IS MADNESS!{SMALLLINE}There are no prison cells at that hideout, Cap'n!"
STR_NO_ALIEN_CONTAINMENT_FOR_TRANSFER_2: "HOLD YOUR HORSES!{SMALLLINE}There are no animal cages there..."
STR_NO_ALIEN_CONTAINMENT_FOR_TRANSFER_3: "WHAT?!{SMALLLINE}My virgins are going nowhere!"
#No Containment
STR_ALIEN_DIES_NO_ALIEN_CONTAINMENT_FACILITY: "Alien dies as there is no alien containment facility"
STR_ALIEN_DIES_NO_ALIEN_CONTAINMENT_FACILITY_1: "No free prison cells. Hostages were looted and kicked out!"
STR_ALIEN_DIES_NO_ALIEN_CONTAINMENT_FACILITY_2: "There's no animal cages, we have let them free"
STR_ALIEN_DIES_NO_ALIEN_CONTAINMENT_FACILITY_3: "The virgins have been deflowered prematurely"
#Manage Containment
STR_REMOVE_SELECTED: "Remove Selected"
STR_REMOVE_SELECTED_1: "Ransom!"
STR_REMOVE_SELECTED_2: "Put to sleep"
STR_REMOVE_SELECTED_3: "Not a virgin? Sell at slave market!"
STR_MANAGE_CONTAINMENT: "Manage Alien Containment"
STR_MANAGE_CONTAINMENT_1: "Manage Prison"
STR_MANAGE_CONTAINMENT_2: "Manage Animal Cages"
STR_MANAGE_CONTAINMENT_3: "Manage Harem"
STR_ALIEN: "Alien"
STR_ALIEN_1: "Hostage"
STR_ALIEN_2: "Animal"
STR_ALIEN_3: "Virgin"
STR_LIVE_ALIENS: "Live{NEWLINE}Specimens"
STR_LIVE_ALIENS_1: "Keep"
STR_LIVE_ALIENS_2: "How{NEWLINE}cute!"
STR_LIVE_ALIENS_3: "Keep{NEWLINE}for later"
STR_DEAD_ALIENS: "Rejected{NEWLINE}Specimens"
STR_DEAD_ALIENS_1: "Ransom"
STR_DEAD_ALIENS_2: "Ugh,{NEWLINE}ugly!"
STR_DEAD_ALIENS_3: "Deflower{NEWLINE}now!"
STR_UNDER_INTERROGATION: "Being{NEWLINE}Studied"
STR_UNDER_INTERROGATION_1: "Being{NEWLINE}interrogated"
STR_UNDER_INTERROGATION_2: "In Lab"
STR_UNDER_INTERROGATION_3: "Being{NEWLINE}deflowered"
And here it is... the stupidest-est feature I've ever implemented!
Selective storage is interesting. If used sparingly for like say needing slave housing or fridge for perishable food. To much storage micro would suck. Already kinda run close to what I find tolerable once the world is covered.
Only thing now we are lacking is custom storage types for not "live" items :>
Like special container for uranium or elerium.
[ps] because of that I think better would be name this property as "storageType" but this depend if you want do that.
Hmm... I could use that to limit the numbers of slaves and/or HWPs by requiring them to be housed in special buildings, not sure if the mod really needs it tho...
Make them 'livingAliens' & need special 'containment' type, then add a facility that is just that.
Starting conditions by terrain
Terrain can affect starting conditions, just like deployment. Terrain takes preference.
Yeah, this complicates matters.
I'm not completely sure at the moment, I think Dioxine has a clearer concept than I. But I guess solution 3 would be best.
By the way: how hard would it be to make a combined effect of conditions by deployment and by terrain? Say for example, deployment forbids pistols and terrain changes all light armours to Maid Outfit, so in the end both conditions apply.
I'll wait for Dioxine's feedback too.
Doable, but I would need to change quite a lot.
By the way: how hard would it be to make a combined effect of conditions by deployment and by terrain? Say for example, deployment forbids pistols and terrain changes all light armours to Maid Outfit, so in the end both conditions apply.
Hmm I cannot imagine a situation where you'd need multiple enviros per map... Either you're on Mars, or you're not. Either you're underwater, or you're not. How many enviros would one need? 5? 10? If no more than this, combining makes little sense.
EDIT: Also multiple enviros per map can lead to direct conflicts between enviro rules, and unclear preference of armor. Naturally a modder can make it in a way that avoids conflicts, but - this way you can make 500 or more enviro combinations, but with much tighter constraints. If you don't need 500 enviros (combinations), I think it is better to stick to '1 enviro per map' rule, as there will be no conflicts and modding would be much easier.
Let's K.I.S.S. Skip projectiles, sounds and animations completely, for now at least. While this will limit the uses a bit, these aren't important uses for now, and it can be played with later.
- type: STR_ENVIRO_CYDONIA
environmentalConditions:
STR_FRIENDLY:
chancePerTurn: 100 # 30 = 30% chance of hitting per turn
firstTurn: 1 # first turn to apply damage
lastTurn: 1000 # last turn to apply damage
message: "STR_LOW_PRESSURE" # code of message to be displayed on "Next Turn" screen (e.g. STR_LOW_PRESSURE = "Extreme low pressure is hurting us.{NEWLINE}Hurry up!")
color: 29 # color of the message (battlescape palette: 13..16 + i*16)
weaponOrAmmo: "STR_PISTOL_CLIP" # code of weapon or ammo used for damage calculation
side: 3 # side to be hit from (-1=random, 0=front, 1=left, 2=right, 3=rear, 4=under)
bodyPart: 0 # bodypart to be hit (-1=random, 0=head, 1=torso, 2=right arm, 3=left arm, 4=right leg, 5=left leg)
STR_HOSTILE:
chancePerTurn: 100
firstTurn: 1
lastTurn: 1000
message: "STR_TICKLE" # The guards' morale is rising.{NEWLINE}Second line...
color: 45
weaponOrAmmo: "STR_PISTOL_CLIP"
side: -1
bodyPart: -1
STR_NEUTRAL:
chancePerTurn: 10
firstTurn: 1
lastTurn: 1000
message: "STR_KILLING_ME_SOFTLY" # The VIP is slowly dying. Hurry up!
color: 109
weaponOrAmmo: "STR_GAUSS_PISTOL_CLIP"
side: -1
bodyPart: -1
defaultArmor:
STR_SOLDIER: STR_SPACE_SUIT_UC
STR_SOLDIER_S: STR_SPACE_SUIT_UC
allowedArmors:
- STR_SPACE_SUIT_UC
- STR_BIO_SUIT_ADV_UC
- STR_IRONMAN_ARMOR_UC
- STR_ANNIHILATOR_ARMOR_UC
- STR_STEALTH_ARMOR_UC
- STR_ARRANCAR_ARMOR_UC
- STR_LOADER_ARMOR_UC
Looks real good! :) Except we don't need that 'ammo', why complicate. Would you really think I'd use weapon + ammo if I can use ammo-less weapon? :)
Ammo is optional.
PS: I'd like to see a mission with a single neutral VIP unit with 1000+ armor (i.e. can't be killed by guards by accident) taking constant health damage per turn (i.e. dies for example in 20 turns). The mission objective is to kill all guards, i.e. rescue the VIP :) With nice fat score if you manage to save him.
https:// Note: there are limitations, since we're not using a projectile and nobody is actually shooting
https:// 1. no power bonus based on shooting unit's stats (nobody is shooting)
https:// 2. no power range reduction (there is no projectile, range = 0)
https:// 3. no AOE damage from explosions (targets are damaged directly without affecting anyone/anything)
https:// 4. no terrain damage
https:// 5. no self-destruct
https:// 6. no vanilla target morale loss when hurt; vanilla morale loss for fatal wounds still applies though
https://
https:// 7. no setting target on fire (...could be added if needed)
https:// 8. no fire extinguisher
I have a tiny feature request :) Some streamling of the Pedia that'll allow modders to save time and space (and avoid errors), while looking more elegant to the player. In weapon's attacks list, Instead of the current Auto, can we have Auto (x3), or whatever the number of autoshots a weapon fires when used in this mode? The number is the key, extra letters and symbols should be arrangeable as translator wishes.
STR_SHOT_TYPE_AUTO: "Auto (x{0})"
Terrain destruction by melee
So we could attack walls and objects with melee weapons. Should only work when the tile doesn’t have any units standing on it (unconscious units are ignored).
Or should I trace an invisible bullet and see what it hits? If so, which voxel to take as starting point (e.g. unit's eyes) and as end point (e.g. center of the target tile's floor)?
And what if I am a 2x2 unit (tank or a reaper)... which tile am I even targeting? Or am I targeting both tiles in front of me?
soldiers:
- type: STR_SOLDIER
dogfightExperience:
bravery: 100 # guaranteed to improve by 1
reactions: 0 # no improvement possible
firing: 50 # 50% chance of improvement by 1
So, any idea how should this work exactly?
There can be only one unit on a tile (easy)... but there can be several objects to destroy (on a screenshot, should I destroy the wall or the stairs behind the wall?)
Also the objects don't occupy the whole tile... if I aim for the center of the tile, I can destroy for example a stone fence or wooden stairs... but I cannot destroy a wall (since it's not in the center of the tile).
Should I check all 6144 voxels (16*16*24) for a presence of an object? :)
And what if I am elevated... should I check neighboring tile(s) as well?
Or should I trace an invisible bullet and see what it hits? If so, which voxel to take as starting point (e.g. unit's eyes) and as end point (e.g. center of the target tile's floor)?
And what if I am a 2x2 unit (tank or a reaper)... which tile am I even targeting? Or am I targeting both tiles in front of me?
dogfightExperience:
bravery: 20
In this example:Code: [Select]dogfightExperience:
bravery: 20
Would it mean +10 to Bravery each 5 succesful interceptions on average?
No it goes up only by +1 just like other stats.
Would +5 or +10 be better?
Ugh how? Is Bravery no longer going up by 10s only? You need to explain this :)
randomizedItems:
- position: [1, 1, 2]
amount: 3
mixed: true
itemList: [STR_ALIEN_DATA_SLATE, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_AXE, STR_STUN_ROD, STR_MEDI_PACK, STR_ALIEN_ELECTRONICS, STR_PSICLONE, STR_MONEY_BRIEFCASE]
Meridian, can I add an item to the random loot list several times, to make it appear more frequently?
We can do anything we like. Just tell me.
Being able to allocate Runts to expedite craft repair might be a good idea; if you need to limit the rapidity of repairs and the opportunity cost of not manufacturing goods with those Runts is thought to be an inadequate limiter by itself, merely cap the number of Runts that can work on each ship.
That sure looks familiar:
You weren't the first guy here to come up with this, sorry for raining on your parade.
If you really have to know, it wasn't worth commenting for the dual-pronged reasons of being a well-known improvement idea, and the reality that it needed an attention of a coder to happen (which just happened).
That seems sensible. I'm impressed you even went with NE-SE-SW-NW wall destruction as well.
It would have expected to require that you face the wall you want to destroy directly and can only destroy objects to the NE-SE-SW-NW of you if there are no walls in the way.
As I said in the second post, I don't like Solar's "crew unification" proposal ("everybody can do everything"), I won't be implementing that. We'd have a completely different game if we did that.
As soon as I get rid of that stupid bandwith limit, I'm gonna binge watch some LPs! :D
Best idea I've had so far for tougher landed UFOs: Have a timer during which you have to get a gal inside the enemy UFO, or it will power up engines and weapons and destroy your ship that is a sitting duck on the ground.
If you had that, the next feature would be: an option to bombard a landed UFO to turn a "landed" site into a "crashed" site, so you can choose your risk/reward.
Best idea I've had so far for tougher landed UFOs: Have a timer during which you have to get a gal inside the enemy UFO, or it will power up engines and weapons and destroy your ship that is a sitting duck on the ground.
Anyway, back on topic: I am considering adding more psionic powers to the Great Duumvirate of Panic and Mind Control. I mean powers that actually require new code and cannot be hacked with damageAlter and such. Do you people think it makes sense? And Meridian, does it clash with the "no AI modding" principle?
Well, you didn't tell us much.
I'd need a bit more info about what should this new thing be to tell anything reasonable.
How hard would it be to allow renaming HWP-type units? It doesn't have to be all that involved, just alias would do fine, if I use up my Reaper to manufacture Mutated Reaper, and lose the one I renamed to Teddy Bear, I won't cry, I can just rename him again.
You probably want to avoid deployment trouble auto-magically, eh? Do your worst, if you insist :)
EDIT: to clarify my statement, if we go that way, I intend to completely remove any old-style HWP units from X-Piratez and change every last one of them into a soldier type.
And to simulate current limit on allowed hwps per craft (due to floor plan limitations), I would introduce a limit per soldier type per craft... that's actually on my todo list for several months now.
PS: btw. please think also about if these ideas add anything (new) to the game... I won't be implementing any more features like the Alien Containment types, which are there just for decoration
I never knew I wanted this until now, but I need gals piloting Sectopods.
I never knew I wanted this until now, but I need gals piloting Sectopods.
Nah, just instead of "isHWP" on armor, the "size" attribute is already enough to do calculations/limitations on total space available/used.Solder with 2x2 size already are handled as HWP in case of craft space.
And to simulate current limit on allowed hwps per craft (due to floor plan limitations), I would introduce a limit per soldier type per craft... that's actually on my todo list for several months now.
Any ideas? And, if I just stack the existing .maps on top of each other, wouldn't the AI be confused?
It would be confused in the sense they wouldn't patrol between floors, but that's not a problem, because this behaviour is disabled anyway when they spot an enemy. So they can chase after you even if you change the floor.Well, that's great, no problem then.
It's a very interesting project of yours, thanks for taking a stab at this. And can you explain more what you are trying to achieve, regarding the Syberia Base example? Some sort of a mix between horizontal and vertical map composition?
I know for sure that many z-levels, especially with lots of objects, inflict a heavy burden on the CPU.
Yes, it's most noticeable when defending a built-up base (and also mansions). But since it's quite rare, I think there's not enough pressure to optimize the drawing. I for one thought about it, but decided that two rare mission types isn't worth reading that much code. When it ceases to be rare I'm sure someone will get fed up and will fix it.
It's rare, because it's slow, not the other way around :)
And I think it might get even slower with OXCE 3.3.
I heard DarkDefender has tried optimizing it (link (https://colabti.org/irclogger/irclogger_log/openxcom?date=2016-06-14#l142)), but I never saw anything...
Forced movement and teleportation mechanics would be highly desirable.
Why? What's coming?I added new light system that allow walls/objects block light.
The map generator can't do this sorry. Though a map paying homage to the Infernal Runner would be much fun :)
I'm referring to mechanics for items/weapons.
A small request (for deployments):
maxShade: use night/day cycle, but never set greater shade than this (useful for eg. city maps)
minShade: use night/day cycle, but never set lower shade than this (useful for eg. underwater missions, smog-ridden cities)
I uploaded the document, added Dioxine's request and also one from me: an option to spawn more than one UFO per map.
Isn't this implemented already?
I believe Hobbes has been adding multiple craft per map in Area 51 already... "addCraft" command in mapScript.
A small request (for deployments):
maxShade: use night/day cycle, but never set greater shade than this (useful for eg. city maps)
minShade: use night/day cycle, but never set lower shade than this (useful for eg. underwater missions, smog-ridden cities)
alienDeployments:
- type: STR_MY_ALIEN_DEPLOYMENT
shade: 7 #existing, default -1
minShade: 4 #new, default -1
maxShade: 9 #new, default -1
Addendum to the surrender mode: a flag is needed to exempt an unit from surrender calculations. Some units will never surrender & never trigger surrender, but should surrender once their masters do (drones, reapers). Not sure how this will work out, though (I can see funny situations arising), so I'd appreciate input.
units:
- type: STR_DRONE
autoSurrender: true
- type: STR_REAPER
autoSurrender: true
Well, if you got notifications of that sort, what the hell would you need radars for?
Well, if you got notifications of that sort, what the hell would you need radars for? Also there are more early air combat options now.
As it is now we've got to drop from 1/day time compression to 5/min time compression while the UFO buzzes around, waiting for it to land, if it ever does. For the first couple months of game time it's tedious.
Radars have nothing to do with it. I just want a notification when the UFO dot turns from red to green.
As it is now we've got to drop from 1/day time compression to 5/min time compression while the UFO buzzes around, waiting for it to land, if it ever does. For the first couple months of game time it's tedious.
Suggestion: vampiric weapon/ammo. Vampiric weapon adds settable amount of HP, stun, morale, energy for each point of damage caused.already in my plans
already in my plans
Minimum Reaction Accuracy setting
An option to set a minimum accuracy where reaction fire is used. This is to prevent short-range weapons from firing at long distances, at 0% chance to hit.
This wasn't necessary in vanilla, but with vision range 40 and weapons like the Sawed-Off...
Best to pass the reaction check altogether if accuracy below that threshold, so we won't stop each tile when an enemy with throwing knives is at the other edge of the map...
Commendation Bonuses
Multi-stage production automatization
Minimum Reaction Accuracy setting
How about not creating such projects in the first place.
I don't feel the need to clean up your mess to be honest... keep it simple (one of very important rules of game design) or suffer the consequences.
Minimum Reaction Accuracy setting
An option to set a minimum accuracy where reaction fire is used. This is to prevent short-range weapons from firing at long distances, at 0% chance to hit.
This wasn't necessary in vanilla, but with vision range 40 and weapons like the Sawed-Off...
Active when UFO accuracy option is turned on.
If accuracy is 0% or if target is out of range, don't react.
Does this also fix the bug where firing while berserk could shoot outside of your maximum weapon range?
Commendation Bonuses
Commendations give various bonuses to units, for example Wrestler increases Strength (+1 per skull) and Nightingale increases night vision (+1 per skull colour). This would give the commendations some actual meaning, allow for advancement of units who are maxed out, and also help personalize units further.
When you have some time, could you write what kind of bonuses would you like for each award?
Just to help me mentally prepare for the complexity (or lack of it).
1) Since night vision is already visually represented by a green palette across the screen,Is it? Everything looks normal to me. How do you see in green?
Is it? Everything looks normal to me. How do you see in green?
What would the dead need bonuses for? :)
There are no Challenge Coins in Hell...
Once Hell is ready as a mission region, we might be getting our dead girls back. :PGet the "Devil's Coins" and use them + a cloning machine to revive one girl? That'd be AWESOME :D
Gladly!
Here's a list of suggestions - for the current commendations and some potential new ones, too. (Co-produced with Dioxine.)
Can bonus from commendations go above the maximum?
I.e. let's say I reach 100 bravery in normal way... can I get to bravery 150 if I have +50 bravery from commendations?
Btw. I vote for "yes".
Probably shouldn't allow to go below minimum?
I.e. with bravery 10 and -50 from commendations... I should probably still have 10 bravery. I guess negative values would not go well with various formulas.
Could we have it, while we're at it, to implement a check if wearing an armor would get stats below 0, and disallowing equipping said armor in such a case? Would help 40k mod, for example, where several armors are locked out from early use by huge penalties (-50 Str, for example) and currently the punishment for disregarding it is buggy game behaviour.
I understood damage inflicted :)
Not sure if it is doable (without big changes) tho.
More info on weapons
Some additional weapon stats could be displayed in Ufopedia which for now have to be added manually: additional “bleedthrough” damage, damage bonuses from stats, accuracy formulas.
More info on armours
Some additional armour stats could be displayed in Ufopedia which for now have to be added manually: weight, vision (various modes), camo. Also dodge chance if it’s not too complicated (as it usually relies on stats).
Added two items:
The first one is problematic, because there's hardly enough space to put that info, but it's up for discussion. The latter can be just put into the scrolled text.
I would like to add:
- Ammo capacity for clips
- Fuel type for crafts
- Projectile speed for craft weapons
B/ For geeks, nerds, and number-gasm-folks, we could have a button "Stats for nerds", which opens a pop-up with full ruleset definition, either raw or slightly formatted.
I'd be fine if damage range was displayed, but maybe not on the bars...
@Meridian
1) In my fork based on yours 3.5 i did some ufopedia improvments, to allow moder to add less description. interested in merging ?
2) or in general are you interested in UI improvement. ?
ok so now just convince Meridian to merge my pull request with OXCE+ :)
Including target's resistances in that number would be a straight cheat, though.
Yeah, actually playing around with the image in paint, I agree that just "weapon power" is enough under the hit %. It saves some space, can represent power drop with distance, and the RNG range is something the player should be able to calculate (50-150% or 0-200% are not hard calculations, the important, annoying number is the A*X+B*Y+C of listed power)
I second posting links to repos, that way I can merge them in even if Meridian doesn't like it (like the awesome, cheesy but so much easier to use that it's worth it scanner) :P
You could only display it for researched enemies. I think that is doable and would not be cheaty. The point is to hide the math from the player. Think Blowpipe vs Osiron Security. Another example: Self Charging Laspistol vs Mechtoid. Takes a lot of shots, but you can kill a Mechtoid with that.
Now that I'm thinking about enemy info: The mind probe should show resistances too, and not just armor. Would have to solve the display space problem first though.
The thing is, if a weapon is 0-200% or 50-150% is not always clear. If that were explicitly stated in the Bootypeadia, I would say it's not that important (something for the nerd button). But right now I still have to look in the ruleset from time to time because I'm not sure about the damage range. I would still prefer to have the damage range, because why no. It does not use that much more space and saves me a little bit of math.
We still need ideas how to display this stuff for melee weapons though, because they don't have a target crosshair. And melee weapons is where this would be most helpful because these are the bulk of stat dependent damage items.
Could you please post your executable for the folk like me who don't know how to merge and build their own executable?I could publish my code on github.
You could only display it for researched enemies. I think that is doable and would not be cheaty. The point is to hide the math from the player. Think Blowpipe vs Osiron Security. Another example: Self Charging Laspistol vs Mechtoid. Takes a lot of shots, but you can kill a Mechtoid with that.
Then you will just raze some useless crap and build these 6 buildings. What's the problem?
I think the shroud could definitely use a geoscape notification of some type with a toggle in the base info screen or even just a right click option on the module itself - as for the defenses, how hard would it be to allow us to manually fire them instead of having them fire automatically when the UFO comes in for a landing?
Gah, maybe do it simpler....
>Base gets attacked
>Player is prompted: should defenses fire, or let invaders land?
Is it possible to make a ufo shot down by base defense spawn a crash site?
Is it possible to make a ufo shot down by base defense spawn a crash site?
I'd really love to see how would you implement that 'simplest' solution (making base defenses as difficult as to be unwelcome but not an instakill for early-mid game).
Please don't turn my question to a nerfing/buffing flamewar.
Is it possible to make a ufo shot down by base defense spawn a crash site?That would be a good alternative to making defenses not fire since having a crash site means you could get all the good loot people want and you'd fight a slightly less advantageous battle since bases are usually designed to be easy to defend, compared to UFOs that are often a pain to clear.
Although I do believe that it could be achieved with multiple ranks in a given factions, and retaliations only using the hardcore ranks + being given hardcore weapons
Bonus: no more first year retaliations with plasma weapons and blaster launchers. (Or am I wrong and base defence uses always the same weapon layout?)
Not really. They're already using best weapons. And even Mercs are a fodder. All it takes is to nuke hangars.
It's certainly a big step forward. But I still think the next step should be a settable threshold fwor reaction fire. Accuracy 5% isn't noticeably different from 0%. If I could set it myself, I'd probably go for something like 30%, but someone else might prefer 20% (because of different personal preferences or different weapons choice), so I don't think enforcing a particular threshold would be a good idea.
minReactionAccuracy: 30
Random Manufacturing
A manufacturing project has many possible outcomes. the resulting item is chosen randomly, according to a list with weighs.
(There are several potential uses, for example "unpacking" a parcel to find random treasure. Yes, it can be done with random loot, but in some cases it's not exactly enough.)
If you want this backwards-compatible, then I can do:
1. either same weights... and keep possibility to manufacture more than 1 item
2. or use number of produced items as weight... and produce always just one item
If you want both, I would have to introduce a new attribute (can't reuse "producedItems") and make it a bit messier than it already is.
itemList: [STR_ALIEN_DATA_SLATE, STR_ALIEN_DATA_SLATE, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_CYBERWEB_BATTERY, STR_AXE, STR_AXE, STR_INCENDIARY_GRENADE, STR_INCENDIARY_GRENADE, STR_STUN_ROD, STR_STUN_ROD, STR_MEDI_PACK, STR_MEDI_PACK, STR_MEDI_PACK, STR_ALIEN_ELECTRONICS, STR_MUTANT_BLOOD_PLASMA, STR_PSICLONE, STR_PSICLONE, STR_ALIEN_GRENADE, STR_SONIC_PULSER, STR_GAUSS_PISTOL_CLIP, STR_GAUSS_RIFLE_CLIP, STR_HEAVY_GAUSS_CLIP, STR_CANISTER_GUN_CLIP_CH, STR_CANISTER_GUN_CLIP_I, STR_TOXIGUN_FLASK, STR_PLASMA_CASTER_CLIP, STR_PLASMA_PISTOL_CLIP, STR_SONIC_PISTOL_CLIP, STR_SONIC_BLASTA_RIFLE_CLIP, STR_SONIC_CANNON_CLIP, STR_CONCUSSION_CANNON_CLIP, STR_TLETH_SPEAR, STR_TLETH_HATCHET, STR_VIBRO_BLADE, STR_MONEY_BRIEFCASE, STR_MONEY_BRIEFCASE]
itemList:
- STR_ALIEN_DATA_SLATE
- STR_ALIEN_DATA_SLATE
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_CYBERWEB_BATTERY
- STR_AXE
- STR_AXE
- STR_INCENDIARY_GRENADE
- STR_INCENDIARY_GRENADE
- STR_STUN_ROD
- STR_STUN_ROD
- STR_MEDI_PACK
- STR_MEDI_PACK
- STR_MEDI_PACK
- STR_ALIEN_ELECTRONICS
- STR_MUTANT_BLOOD_PLASMA
- STR_PSICLONE
- STR_PSICLONE
- STR_ALIEN_GRENADE
- STR_SONIC_PULSER
- STR_GAUSS_PISTOL_CLIP
- STR_GAUSS_RIFLE_CLIP
- STR_HEAVY_GAUSS_CLIP
- STR_CANISTER_GUN_CLIP_CH
- STR_CANISTER_GUN_CLIP_I
- STR_TOXIGUN_FLASK
- STR_PLASMA_CASTER_CLIP
- STR_PLASMA_PISTOL_CLIP
- STR_SONIC_PISTOL_CLIP
- STR_SONIC_BLASTA_RIFLE_CLIP
- STR_SONIC_CANNON_CLIP
- STR_CONCUSSION_CANNON_CLIP
- STR_TLETH_SPEAR
- STR_TLETH_HATCHET
- STR_VIBRO_BLADE
- STR_MONEY_BRIEFCASE
- STR_MONEY_BRIEFCASE
itemList:
- STR_ALIEN_DATA_SLATE: 2
- STR_CYBERWEB_BATTERY: 8
- STR_AXE: 2
- STR_INCENDIARY_GRENADE: 2
- STR_STUN_ROD: 2
- STR_MEDI_PACK: 3
- STR_ALIEN_ELECTRONICS: 1
- STR_MUTANT_BLOOD_PLASMA: 1
- STR_PSICLONE: 2
- STR_ALIEN_GRENADE: 1
- STR_SONIC_PULSER: 1
- STR_GAUSS_PISTOL_CLIP: 1
- STR_GAUSS_RIFLE_CLIP: 1
- STR_HEAVY_GAUSS_CLIP: 1
- STR_CANISTER_GUN_CLIP_CH: 1
- STR_CANISTER_GUN_CLIP_I: 1
- STR_TOXIGUN_FLASK: 1
- STR_PLASMA_CASTER_CLIP: 1
- STR_PLASMA_PISTOL_CLIP: 1
- STR_SONIC_PISTOL_CLIP: 1
- STR_SONIC_BLASTA_RIFLE_CLIP: 1
- STR_SONIC_CANNON_CLIP: 1
- STR_CONCUSSION_CANNON_CLIP: 1
- STR_TLETH_SPEAR: 1
- STR_TLETH_HATCHET: 1
- STR_VIBRO_BLADE: 1
- STR_MONEY_BRIEFCASE: 2
bla: [bla1, bla2]
bla:
- bla1
- bla2
are equivalent... you can use the one you prefer
I have an idea regarding grenade balance. Since we now have the code to restrict inventory slots to certain items, how about restricting primed grenades to be hand only items? That would be a good way to remove the sillyness of having potentially 10+ primed grenades in your inventory and the resulting grenade spam.
they're a source of revenue for many players...
That is quite unrealistic and it turns something that should be punishing for the player and the goal is to avoid it into somehting that rewards player.
If I believe myself unassailable, I should be able to PROVOKE an enemy into hastily attacking my Fortified settlement because they don't know any better....
If primed grenades explode also in inventory, after the timer is up, it would be a good solution.
I think Yankes is already working on this.
Then they are not enemies but prey. The big factions at least should have some semblance of threat about them.
Or for a more modern example. The piracy in Somalia was a problem know to the world for months but it took the capture of an American ship and crew, for the US to get off it's butt and address the problem. Until criminal acts are actively threatening an established powers stability and or reputation with its own constituents they will do nothing. The bigger a power the bigger the threat needed to get things in gear.
Right now I am interested in getting just one item, randomized according to weighs... Getting more would be an interesting option though, if not hard to code.
What should be displayed in the monthly profit column?
Something like "???" is the only solution, I guess.
Not sure if I can display exactly that smiley :-)
In Piratez you can shoot down their cruisers and battleships and the only answer to something clearly threatening to their reputation is an anemic hideout raid.Even if crackdowns become automatic losses, it won't make them resistant to abuse.
For the monthly profit, I'd suggest the weighted average of the possible profits.
Your runts (or whoever is running the numbers) have no idea what the manufacturing result will be; they may not even have a list of possibilities. It's like buying a shed with everything in it before opening it. How would they/you appraise its value?Fair enough. I was imagining that the runts _did_ know. For example, if they were opening a treasure chest; they might not know what's in there, but they do know from their treasure chest research roughly what the value will be... ...
No, it should be a big fat question mark. It's a surprise!
A more proper solution would be to make crackdown missions appropriately hard (always scaling with actual player's progress), while at the same time removing all instakill heavy ordinance from the game at all (chinese dragon, baby nukes, etc), because instakill weapons trivialize crackdown missions way too much. At least all replenishable instakill weapons.
Since difficulty level has been discussed in another thread:
How hard would it be to code in additional starting items / facilities based on difficulty level?
IF difficulty lower then 4/3/2/1 THEN lookup in ruleset which additional items/facilities/soldiers to add to starting base.
To reduce smoke spam and make gas-related weapons actually worth using. Smoke does very little stun damage on its own otherwise.But presumably the damage of smoke related weapons could be increased, and the damage modifier decreased, so that the final damage is the same as it currently is. Right?
Okay, let me rephrase: smoke stun damage per turn is hardcoded into the damage type. The intent was to make standing in smoke a bad idea and not just a minor nuisance like in vanilla, and the only way to do that is to up the damage modifier. OXCE can do a lot, but damage over time is not exposed to ruleset.Understood. Thanks.
- type: STR_KNUCKLES
damageBonus:
# strength: 0.6
# melee: 0.2
rank: [0.0, 10.0] # 10*rank^2
fatalWounds: [10.0, 2.0]
soldiersPerSergeant: 5
soldiersPerCaptain: 11
soldiersPerColonel: 23
soldiersPerCommander: 30
- type: STR_SOLDIER_S
costBuy: 20000
costSalary: 5000 # rookie base salary 5'000
costSalarySquaddie: 5000 # squaddie salary 10'000
costSalarySergeant: 10000 # sergeant salary 15'000
costSalaryCaptain: 15000 # captain salary 20'000
costSalaryColonel: 50000 # colonel salary 55'000
costSalaryCommander: 500000 # commander salary 505'000
EDIT: New feature request, after Dioxine's and mine experiences with X-Com Files:
Vanishing targeted missions
An option (in mission settings) to make the mission disappear after time is up even if it is targeted by a vehicle. This is to prevent abuse by targeting the mission by zeppelins, slow cars etc.
alienMissions:
- type: STR_ALIEN_TERROR
despawnEvenIfTargeted: true # followers will automatically return to base
points: 10
objective: 3
Why not simply show in that case "ufo tracking lost" with different text?
Define random number of civilians
Defining a number random of civilians in deployment, for example 4-20. Currently it’s a fixed number with some mysterious randomization.
The range can be affected by difficulty level, if it already influences the number.
Custom factions in battles
Facilities: required staff (soldiers)
Current randomization is 50% - 100%.
So if "civilians: 16", it will be a random number between 8 and 16.
If there are no free spawn points, game tries to place them near other civilians (which should usually be successful, but has a small chance of failing if there are too many units on battlescape in total). If this fails too, civilian is not placed.
Is this enough random?
I suggest moving these 2 to "scrapped" section.
alertDescription: STR_ALIENS_TERRORISE_DESCRIPTION
And the appropriate string to the language.It would be enough if 'details' showed briefing... up to modder to decide how much info he's going to disclose in the briefing... Could be a bit immersion-breaking, tho, dunno.
Well, if 'facilities require staff' was scrapped, I can only express my sadness about this fact, had plans with that.
extraSprites:
- type: TAC00.SCR
singleImage: false #default is "true"
width: 320
height: 200
files:
0: backgrounds/Back_33_Cus.gif
1: backgrounds/Back_34_Cus.gif
2: backgrounds/Back_34_Cus.gif
Ruleset-wise, this would be done by adding this to the alienDeployments:Code: [Select]alertDescription: STR_ALIENS_TERRORISE_DESCRIPTION
And the appropriate string to the language.
If alertDescription is not present in the deployment, the DETAILS button doesn't appear.
What do you think?
alienDeployments:
- type: STR_LOC_SPACE_STATION_3
alert: STR_ALERT_ORBIT
alertDescription: STR_ALERT_ORBIT_INFO
briefing:
palette: 3
background: ORBIT_BACKGROUND.SCR
extraStrings:
- type: en-US
strings:
STR_INFO: "INFO"
Allow Multiple Background images to be defined for a particular mission. This would allow for more variety in the Hidden Movement screens ala XCom Apocalypse. Purely cosmetic, but more immersion building.
hiddenMovementBackgrounds:
- TAC00.SCR
- TAC01.SCR # DON'T use this one, it will be cut off on the edges, which you don't want
- BACK04.SCR # use other existing backgrounds on your own risk, I'd create new ones, just to be sure...
Yes, it's clear enough, thank you. However it's not the random number that is the main problem, but control over what spawns. (Sorry I haven't explained it well enough before, I failed at reading what I wrote and forgot half the sentence somehow. My bad.)
For example, I have a mission where you are supposed to rescue a council member from an assassination attempt. Civilians for this mission are: the council member, some bodyguards and some servants. With how it is now, there is no guarantee that the council member will spawn at all, or that only one spawns. If she doesn't spawn, then the mission is pretty much pointless and you must repeat it (and because you have no control over where she spawns, there's a significant probability that she will be dead anyway before you get to her, so repeating this mission will probably be inevitable even without the mission VIP). And having two or more is acceptable in this case (if awkward), but in some other mission it could be a big problem.
So, the best thing would be something analogous to alien deployments, where you could define the numbers of civilians of a particular type. I know it's probably complicated, and perhaps impractical, but I thought I'd at least ask, since you added the recoverable civilians feature already (which is a great thing).
alienDeployments:
- type: STR_LOC_LOKNAR_VILLAGE_DEFENSE
civilians: 0 # no random civilians
civiliansByType:
STR_SECTOID_COMMANDER: 1 # yes, now he's a civilian (not for diary purposes tho, can't fool the race)
STR_HUMAN_FATMAN: 4 # with 2-4 sumo guards
0 = 0 to 0
1 = 1 to 1
2 = 1 to 2
3 = 2 to 3
4 = 2 to 4
5 = 3 to 5
6 = 3 to 6
7 = 4 to 7
etc.
I'll leave this to Yankes if he wants, not going into other man's cabbage:Done, Done, Done, probably not in 100% but very closely, mostly you will need do something like this:
- Global damageAlter per type
- More than 1 damage type per bullet
- Alternate animation for overkill
Commendation Bonuses ... waiting for OXCE 3.7 to see what Yankes will changeRight now there be no big changes in 3.7 aside of multi layer battlescape, I decide not hoarding it and release before I do all my stuff I planed for 3.7.
Right now there be no big changes in 3.7 aside of multi layer battlescape, I decide not hoarding it and release before I do all my stuff I planed for 3.7.
Probably this will be tomorrow or next day, I need finish one thing I have half done and test and merge ohartenstein23 changes.
Are you going to merge latest nightly too?Yes
I've noticed that my laptop literally does not have the Scroll Lock key. As such, I am unable to try out the night vision mode, so I'd appreciate if it was possible to rebind it to another key. What does it do anyway?
Another thing that would be nice is if there was a key allowing you to put a single weapon back into ship inventory during preparations. Sometimes it just happens that multiple pages of the ship inventory are filled up, it doesn't scroll to a new page, and there's simply no room to put down an item manually without removing all equipment from a soldier.
- Hold CTRL, then Left-Click on an item to automatically remove from inventory to floor.
hot damn that makes life alot easier, I was wishing for something like thatsame here, nice.
In the OXCE subforum there was the suggestion of accuracy reduction for indirect fire, meaning you only get full accuracy for aiming at tiles your unit can actually see.
In the reverse, I would also love to see the AI beeing taught how to do sniper spotter tactics, limited by intelligence. The intelligence check could be for all availiable units (high intelligence commander telling his troops what to do), so killing the commander would actually change the enemy tactics (no more sniper spotter tactics if troops are too stupid). Also, you would actually notice a difference between intelligent and dumb enemies.
I can think of one more AI improvement that is easy to implement: Kamikaze flag.
If a unit has the kamikaze flag, skip the retreat algorithm (fleeing when too many opponents spotted). Useful for zombies.
Kamikaze behaviour could also be triggered by low intelligence if a seperate parameter is not wanted.
When you get too close to zombies, it's kind of terrifying. Maybe it's that I haven't yet run into a crysallid since aggression was boosted, but other melee units I've seen aren't nearly as scary as a zombie showing up 5 spaces away from your gal, say because you're clearing buildings, and biting 4+ times. Problem is getting the zombie to that point, as they're still wishy-washy.
Given the new CQC checks, is it possible to setup gunbutt strikes to override snapshot as the reaction action while adjacent?
- name: STR_SOME_ALIEN
getOneFree:
- STR_RESEARCH_ONE
- STR_RESEARCH_TWO
- STR_RESEARCH_THREE
- STR_RESEARCH_FOUR
- STR_RESEARCH_FIVE # requires STR_UFO_POWER_SOURCE
- STR_RESEARCH_SIX # requires STR_UFO_POWER_SOURCE
- STR_RESEARCH_SEVEN # requires STR_UFO_NAVIGATION
- STR_RESEARCH_EIGHT # requires STR_MUTON_AUTOPSY and STR_BATTLESHIP
- name: STR_SYNDICATE_AGENT
requiresBaseFunc: [INTLAB]
cost: 10
points: 10
needItem: true
destroyItem: true
unlocks:
- STR_SYNDICATE
getOneFree:
- STR_PISTOL
- STR_SMG
- STR_BLACKOPS_SHOTGUN
- STR_BLACKOPS_MAGNUM
- STR_DOSSIER_ILYA_DOLVICH
- STR_DOSSIER_HARLEY_STONE
- STR_DOSSIER_IVAN_VASLOV
- STR_DOSSIER_TERRENCE_LOCKHART
- STR_DOSSIER_ERNIE_LLOYD_SOBATKA
- STR_DOSSIER_CARLOS_TANAKA
- STR_DOSSIER_ELIAS_SEPPA
- STR_DOSSIER_OWEN_HOFFER
- STR_DOSSIER_KIM_HARWELL
- STR_DOSSIER_MONICA_GRUMMANN
- STR_DOSSIER_TYVARIUS_STIENBURG
- STR_DOSSIER_GERTRUDE_ELLISON
- STR_DOSSIER_HENRY_GARRISON
- STR_STAFF_001
- STR_STAFF_002
- STR_STAFF_003
- STR_STAFF_007
- STR_STAFF_008
- STR_STAFF_009
- STR_STAFF_010
- STR_STAFF_012
This is just crazy... there must be a better way to do the same... I'll try to come up with options.
I suggest the ZZZ sign on KO units changes colour the higher their stun is, giving players an idea of how much time they have to wake them. I'd also like to suggest it take a bit longer for them to die from high stun
Thanks! I'm open for suggestions.
research:
- name: STR_BOTH
cost: 0
dependencies:
- STR_MEDI_KIT
- STR_MOTION_SCANNER
- name: STR_SECTOID_NAVIGATOR
sequentialGetOneFree: true # getOneFree topics will be given in sequential order, not random
getOneFree:
- STR_ALIEN_RESEARCH # free
- STR_ALIEN_HARVEST # free
#
# getOneFreeProtected topics will *NOT* be given in sequential order!!
# - The 3 groups (A, B, A+B) can be read from the file in a different order by YAML
# - Within the group itself, they will be given sequentially though
getOneFreeProtected:
STR_MEDI_KIT:
- STR_ALIEN_ABDUCTION # not free, requires A (medikit)
- STR_ALIEN_TERROR # not free, requires A
STR_MOTION_SCANNER:
- STR_ALIEN_BASE # not free, requires B (scanner)
- STR_ALIEN_SUPPLY # not free, requires B
STR_BOTH:
- STR_ALIEN_RETALIATION # not free, requires A+B
- STR_ALIEN_INFILTRATION # not free, requires A+B
research:
- name: STR_SECTOID_NAVIGATOR
getOneFree:
- STR_ALIEN_RESEARCH # no requirement
- STR_ALIEN_HARVEST # no requirement
getOneFreeProtected:
STR_MEDI_KIT:
- STR_ALIEN_ABDUCTION # requires medikit researched
- STR_ALIEN_TERROR # requires medikit researched
On a different topic, shouldn't this thread be moved to OXCE+ subforum?
Gladly!
Here's a list of suggestions - for the current commendations and some potential new ones, too. (Co-produced with Dioxine.)
0. GLOBAL DAMAGE ALTER PER TYPE
Priority: very low
Justification: While it would be helpful, I have accepted that this would be difficult/controversial to implement. Since we can do the same with individual weapons, and the bulk of my work there has already been done, I don't really care much any more.
A more general system for inheriting parts of item definition would be awesome though.
1. MORE THAN 1 DAMAGE TYPE PER BULLET
Priority: low
Justification: With the new definable damage types, the need for multiple damage types per attack has significantly diminished. For example instead of making an AP bullet which also deals electric damage, I can simply create a new damage type and match armours accordingly. Again, this is much more work for me, but it is doable.
2. TERRAIN DESTRUCTION BY MELEE
Priority: high
Justification: Lack of this feature has been a pain since melee weapons were added, and nothing has changed here. Half-assed solutions like 1-tile "ranged" weapons are not really satisfactory, and impossibility of using a machete to damage a bush is frustrating.
3. TERRAIN TRAMPLING BY AI UNITS
Priority: medium
Justification: Reaper rampaging through walls would be a fun feature to have, and it would make the AI more unpredictable. Small features like this one, when aggregated, make for a better, more complex and enjoyable experience. Still, it's a small addition, which in itself wouldn't impact the game all that much. Desireable, but not a high priority.
4. ALTERNATE ANIMATION FOR OVERKILL
Priority: medium
Justification: A purely aesthetic thing, but adding it would really enhance the experience. Ludicrous Gibs are a trope for a reason, and some weapons just aren't the same without it. Plus it seems (to a layman like me) to be relatively easy to add.
5. MULTIPLE UFOS/CRAFTS
Priority: low
Justification: You can circumvent this problem by using UFOs with the same tilesets, which makes this feature a little less urgent. I'd probably place it at medium priority, but I already learned to live without it without much loss.
6. X-COM CRAFT CRASH SITES
Priority: very low
Justification: I don't even know how I would want to use this feature. Would have probably removed it long ago, but some other modders expressed interest in it, so I'm keeping it for now.
7. RESEARCH: FALSE FOR UFOPAEDIA ARTICLES
Priority: medium
Justification: Lack of this option causes confusion with some Piratez players and there's no other way of clearing it up easily (without sacrificing some gameplay).
8. FACILITIES: REQUIRED STAFF (SOLDIERS)
Priority: low
Justification: I think we have all accepted that this wouldn't happen anytime soon. Anyway, it's not my request and I have never really been interested in it personally, so it's hard for me to evaluate its value.
9. (not on the list but requested elsewhere) MID-BATTLE REINFORCEMENTS FOR THE AI
Priority: very high
Justification: I literally have several missions already designed (and some of it even made!) around this concept. Definitely a must have for almost any tactical game which is supposed to cover various scenarios, and OXCE+ as a whole moves X-Com in that area.
MID-BATTLE REINFORCEMENTS FOR THE AI
Just curiosity. How would this be implemented?
This for XCom or Alien? T
Thanks.
For 8. FACILITIES: REQUIRED STAFF (SOLDIERS)
Like you can put turrets on craft. You can spawn soldiers in Maps of xcom facilities?
One idea of mine is to convert a facility into a Turrets Bottleneck thing. Multiple turrets in a facility, act as a bottle neck and choke points in a base. Like in APOC. This you can do without any extra coding.
Then again, I am not 100% in understanding what this feature is for. Until I do, I reserved myself from making more input.
No, it's about having staff for base facilities.
Same like you need scientists to do research... you would need extra people to operate a radar, clean up living quarters, organize storage rooms, etc.
Pure geoscape thing.
It's not designed yet.Would it be practical for reinforcements re-use existing spawn points or would these need to have separate zones/tiles? Solarius mentioned having missions/mission ideas in mind for this - are there any actual requests how/where the reinforcement should spawn? Just trying to get an overview of what is actually being proposed here.
Feedback/suggestions welcome.
========= CURRENT DEPLOYMENT =========
- type: STR_CROP_CIRCLES
width: 40
length: 40
height: 4
alert: STR_ALERT_CROP_CIRCLES
alertBackground: BACK03.SCR
briefing:
palette: 2
music: AS_2_INTRO
showTarget: false
music:
- ZIZZ_STUDIO_SPOOKY_SCAPE
markerName: STR_CROP_CIRCLES
duration: [80, 104]
despawnPenalty: 50
turnLimit: 10
chronoTrigger: 1
terrains:
- CULTA_CROP_CIRCLES
data:
- alienRank: 5
lowQty: 1
highQty: 3
dQty: 0
percentageOutsideUfo: 100
itemSets:
-
[]
-
[]
-
[]
-
- STR_AXE
-
- STR_PUMP_ACTION
- STR_PUMP_ACTION_SHELLS
- STR_PUMP_ACTION_SHELLS
========= PROPOSED DEPLOYMENT =========
- type: STR_CROP_CIRCLES
width: 40
length: 40
height: 4
alert: STR_ALERT_CROP_CIRCLES
alertBackground: BACK03.SCR
briefing:
palette: 2
music: AS_2_INTRO
showTarget: false
music:
- ZIZZ_STUDIO_SPOOKY_SCAPE
markerName: STR_CROP_CIRCLES
duration: [80, 104]
despawnPenalty: 50
terrains:
- CULTA_CROP_CIRCLES
data:
- alienRank: 5
lowQty: 1
highQty: 3
dQty: 0
percentageOutsideUfo: 100
itemSets:
-
[]
-
[]
-
[]
-
- STR_AXE
-
- STR_PUMP_ACTION
- STR_PUMP_ACTION_SHELLS
- STR_PUMP_ACTION_SHELLS
reinforcements:
turn: 10 # when reinforcements arrive
direction: [N, W, S, E] # they appear near any map border; newly spawned units have full TUs and can move right away
- STR_MIB_SOLDIER # unit that appears; works like alienRank
lowQty: 7
highQty: 15
dQty: 0
itemSets:
-
- STR_SMG
- STR_SMG_CLIP
- STR_SMG_CLIP
- STR_SMG_CLIP
-
- STR_SMG
- STR_SMG_AA_CLIP
- STR_SMG_AA_CLIP
- STR_SMG_AA_CLIP
-
- STR_BLACKOPS_SMARTPISTOL
- STR_PISTOL_AA_CLIP
- STR_PISTOL_AA_CLIP
-
- STR_LASER_PISTOL_MIB
- STR_LASER_PISTOL_MIB_CLIP
- STR_LASER_PISTOL_MIB_CLIP
-
- STR_GAUSS_PISTOL
- STR_GAUSS_PISTOL_CLIP
- STR_GAUSS_PISTOL_CLIP
- STR_MIB_NAVIGATOR
lowQty: 3
highQty: 4
dQty: 0
itemSets:
(...)
========= VARIANTS =========
(omitting repeatable elements)
reinforcements:
turn: 2-17 # random (probably needs different format, but you get the idea)
direction: [N, W] # they appear either at north or west border of the map; if not specified, any border (like in the previous example)
- STR_MIB_SOLDIER
lowQty: 7
highQty: 15
dQty: 0
itemSets:
(...)
reinforcements:
turnChance: 10 # 10% chance each turn
repeats: 2 # if happened twice, no more checks; default 0 - is never disabled
direction: random # appear randomly on the battlefield, like paratroopers or teleporters
- STR_MIB_SOLDIER
lowQty: 7
highQty: 15
dQty: 0
itemSets:
(...)
reinforcements:
turn: 0 # is present on the map since beginning (a way to override alienRace limitations)
direction: random
- STR_MIB_SOLDIER
lowQty: 7
highQty: 15
dQty: 0
itemSets:
(...)
This one is for Yankes, I can't comment much.Yes, different overkill animations should be possible as you can change any frame of unit graphic.
(IMO) not worth the effort.
It is a small feature gameplay-wise, but a very large feature (IMO) technically.
UFO crash/landing sites are limited to one UFO and one xcom craft.
Visually, you can create a craft that looks like two or more craft... see 40k.
Visually, you can create a UFO, which looks like multiple UFOs...
But in the background, there will always be just one of each.
What is this?
Then don't put it on your list? :)
Anyway, Soldier Transformations now support transforming soldiers into items... so you can make a project that transforms your senior psi operative(s) into resource(s) required to build some advanced Psi facility for example... as requested by Nord.
I have this from someone:
Interesting, thanks.
Wouldn't this run the risk of having units spawn in unreachable/blocked locations, given the random nature of map generation? Would it be possible (or rather practical) to define spawn points manually, akin to how base storage tiles or spawned items (in terrains) are defined?
Cool so is that reinforcements supported now? If so I look forward to seeing what people do with that![...]I think it's supported as in 'considered' and not as in 'implemented' though.
I think it's supported as in 'considered' and not as in 'implemented' though.
The problem I see with the facillities option is that is specific for base assaults, not universal. If you go that route you need different defintions for non base assault situations. I would prefer an universal approach that can be adapted for various mission types/map layouts. Same probably goes for SpawnInSprites - to take advantage of that option you actually need to design your map around it, and you need a way to include that animation (how/where would it be defined? Would it be unit specific? etc.). I think the original request was simply to allow additional unit spawns after the first/zeroth round.
6. SUICIDE BOMBERS (new)
Priority: medium
Justification: Enemy units running towards the player and then blowing up is a common thing in games, and it keeps coming up in the OXC community. I consider it useful.
Suggestion of how this will work in benefit with existing available mechanic.
Unit in unit ruleset must have isLeeroyJenkins in its list.
In the item ruleset
Item melee weapon.
damageType: 7
power: 1
costMelee
health: -350
Some code to handle the unit wielding the melee weapon dying instantly in battlescape.
Item melee weapon.
battleType: 12
power: -350
battleType 12 is self-melee, a modification from Battletype 3. It might involve more coding but this has added benefit of allowing the future expansion of self inflicting weapons like syringe type weapon to boost a soldier stats.
Won't work reliably (if at all)...
Question, I believe the suicide unit has to be “tricked” into thinking like it is using a normal melee weapon. However, when it is attacking a player’s soldier, if it’s weapon does a melee attack on itself, it could bring its health down below zero and dies?
Hi Meridian, if you choose the path of using a new battletype for this self melee/suicide feature.You don't need a new battletype if you can get a unit into melee range with a ranged weapon, hence my question of using 'isLeeroyJenkins' behaviour with ranged weapons. Either by introducing a new variable that replicates isLeeroyJenkins but with all weapon types or by introducing a flag which enables an item to be considered a melee weapon for 'isLeeroyJenkins'.
Melee weapons don't do area-of-effect damage, you can't hurt yourself with a melee weapon.
If you choose the path of giving melee weapon able to do area-of-effect-damage (if possible). Would this also meet Solarius request having Melee weapon able to do terrain damage?No, since area of effect damage isn't the underlaying problem with that. It's that melee weapons only work on units. You can't 'target' melee attacks the way you can with other weapons. Area off effect damage doesn't change that.
If you choose the path of giving melee weapon able to do area-of-effect-damage (if possible). Would this also meet Solarius request having Melee weapon able to do terrain damage? If you can confirm with yes or no?
This question cannot be answered with yes or no.
Okay, thanks for the honest and candid reply. If you can give me a short and detail answer, that will be much appreciated.
Lastly, of the two path I laid down above, which would you go to code it. If you approve of this feature.
All new attributes are subject to change during actual implementation, depending on compatibility with other features and potential extension of cyberdisc/bio-drone self-destruct triggers, power and type.Might this include the possibility of 'disarming' units that are set to self-destruct, in case stunned units wake up again?
Might this include the possibility of 'disarming' units that are set to self-destruct, in case stunned units wake up again?
Disarm which units?Stunnning units that are set to self-destruct on
(The self-destructed ones will be insta-killed and won't be able to rise from the dead.)
Stunnning units that are set to self-destruct on death. Would it be possible to remove/disable the self-destruct flag if the unit is successfully stunned and falls unconscious? Example would be a suicide bomber unit that is (supposed) to wear an explosive vest. Would it be possible to either retrieve the 'vest' (if the function is bound to an item that can be dropped) or disable the self-destruct alltogether?
My question concerns what happens to those units when they wake up. I've never encountered a cyberdisc getting back up after being stunned, but supposedly they would still self-destruct if killed (since the existing self-destruct mechanic is bound to the corpse afaik).
Normal units drop their weapons (if they aren't part of their armor definitions) if they fall unconscious, which includes grenades etc. - would a suicide bomber that is stunned and wakes up still be able to explode or would it be possible to set item(s) that govern the "self-destruct on attack" ability (if the ability is implemented this way) to be droppable?
2x2 units (cyberdisc) cannot wake up, ever.I think I misunderstood the "dummy-item" part you mentioned. I guess my question then would be if the self-destruct flag can be dynamic, with an option to set it to false if the unit falls unconscious.
1x1 units (bio-drone) can wake up, same way as normal units. If you stunned or killed a bio-drone that woke up, it would work exactly the same as if you were doing it to him for the first time. Or in other words, the fact it was stunned before has no impact on anything.
I don't plan to implement any items (droppable or fixed) to perform unit self-destruct.
The unit itself will explode, not any item it is carrying.
DEV update:
Changing default values technically requires either:
1. not changing them at all, store both modded value and modded default value and decide real-time, which one to use... which is inefficient, prone to errors and cannot be generalized... it's used on a few places, but it's an extreme PITA and cannot be used on larger scale
2. creating a completely new secondary mod system that is processed before the current mod system... just to have the default values prepared before any of the primary mod stuff is processed... that's a huge amount of work, for very questionable benefit
You can basically consider this request as rejected.
A workaround/compromise I can offer is to create a few templates and use
There is no such thing in OXC/E at the moment.