-
Extended version of OpenXcom
Mod version 4.0a
OpenXcom date: Nightly 2018-08-17
OpenXcom commit: a6d2d32495d9a2efa5b3460a284b7be33629129d
Extended date: 2018-09-09
Extended commit: 5fb565cd9d7b31978b4a152a38b55cd389b1ffb0
Ubuntu required libs
sudo apt-get install libsdl1.2debian libsdl-mixer1.2 libsdl-gfx1.2-4 libsdl-image1.2 libyaml-cpp0.5
Behavior change
Hyper-Wave Decoder can have less than 100% chance to detect aliens.
Explosions don't remove unconscious unit if they can't kill them first.
Craft weapon equip screen is a bit rearranged.
Fixed "weapons" like the Medikit are now equipped by unit.
Psi-Amp use 3d range, not 2d.
Psi-Amp can use weapon power.
Fixed ammo are added after weapons in armor and unit (armor items are before unit items).
Corpses, items and Chryssalids are not spawned when unit is killed by weapons with overkill.
Stunned units can be hited by bullets and fire.
Big groups of aliens (20+) get less morale losses from casualties.
Terror units can now spawn with any built-in weapon, not only one defined by name.
While loading and unloading weapons you must pay the cost of moving the item to hand.
You can unprime granade for half of prime TUs cost.
Support for Ufo2000 armor damage type.
Psi-Amp can now obey maximum weapon range.
Psi-Amp can now deal direct damage using special attack type in popup menu.
Throwing now requires a healthy arm to do it (if the item is two-handed, then it requires both).
You can hit aliens in the head using any item you like, not only firearms stock.
Items can now be non-throwable.
Rewriten handling of alien psi attacks to handle new features of Psi-Amp.
Building, manufactures and research can now have special requirements for buildings available in base.
Throwing and hitting using two-handed weapons have the same penalty as with shooting.
1.6:
You can train your solders basic skills.
Aliens weapon types/weapons can have different turn restriction.
You can rename weapon slot names in geoscape craft info.
1.7:
Rewritten item use cost. Now is possible to spend HP, Morale or grain stun damage from using items.
You can't use old `energy*` properties in item, they are removed and replaced by new one in `cost*`.
Item have now range threshold unit they start calculating range power reduction.
Damage type can now change default power change per tile in explosion.
1.8:
Option for custom weapon deploy for alien missions and ufos.
1.9:
Options for customizing retaliation mission after shooting dow ufo.
Options for adding custom dodge chance or unit psi defence.
2.0:
Breaking change: Psi-Amp use now weapon dropoff and aimRange for attack chance.
Breaking change: Drop support for Regeneration stat in armor. Use new regen stats now.
Inventory screens can now have up to 128 backgrounds.
Unit sprites recolors can now support up to 128 values.
Option for custom change of TU, HP, Energy, Morale or Stun after next turn based on unit stats.
New stat bonus based on stun level of unit.
Option for changing fuse type in granades and flare.
Option for pre-priming granades on map spawn.
Option for dodge chance based on direction of attack.
Oprion for bonus morale recovery when using medkit.
Option for self heal using medikit.
2.1:
Craft can now have up to 4 different wepon type per slot.
Oprion for overriding shape of alien base.
Option for setting chance of special effect of item.
Moving can trigger all close proxy not only one.
Corpse explosion now can have bonus based on unit stats.
Grenades now can explode at once without destroying each others.
2.2:
Option for custom sound and animation for miss attack and psi weapons.
2.3:
Option for defining percent of all action cost stats. Old use of `flatPrime` and `flatThrow` is deprecated.
Facilities can now require items to build.
Medikit can now be used without UI and can use `hitSound`.
2.4:
Option for defining bonus and damage type for melee in range weapons.
Option for big explosion sound for each items.
Option for showing fixed weapons on unit.
2.5:
Update to nightly and bug fix.
2.9:
Scripting support in unit graphic (more info in game log with debug on).
`bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version.
New property `refNode` used to shared values between items/solders/armors etc.
Option for setting numbers of melee hits done by AI.
Control space usage of soldiers with 2x2 armors in crafts.
3.0:
Backported game machanic changes from Meridian OXCE+.
Fix stun damage calculation and add random for random option for final stats change by damage.
Refactored script handling.
Script support in reaction atack chance calculations.
Some light handling improvments.
New recolr and replace script graphic option for items.
Option for global events shared by scripts.
Custom tags that have user defined values.
3.1:
Base building can now prevent building other buildings.
New tag type that store other mod id.
Option for changing defualt unit light radius.
New functions exposed to script.
Reaction scripts have now information about runing or strafing of target.
3.2:
New functions exposed to script.
3.3:
New light system.
Option for reserving more space for mod in common surface/sound sets.
Visibility scripts that determine visibility of targets.
3.5:
Update to buildin script functions.
Update to recent nightly OpenXcom.
3.6:
Config for new lighting system.
New map script options made by ohartenstein23.
New scripts for items and units.
Add option for grenades to explode in hand.
Changes in handlig items with prime.
Primed granades are not recoverable if consumable property is set.
3.6a:
Fix couple of bugs.
Add some missed scripts.
Add damage type param to unit damage script.
3.6b:
Fix critical bug in unit damage function.
3.7:
New params with shooting weapon and shooter to damage and hit script.
Merge chagnes from master.
Random functions in script.
Vertical map generation support.
3.8:
Add multi ammo weapons.
New param with battle action for unit hit and damage script.
3.8a:
Bug fix.
3.9:
Bug fix.
Improvments in displaying multiple ammo items in inventory.
Script altering experience grain.
3.9a:
Bug fix.
3.9b:
Bug fix.
3.9c:
Bug fix.
3.10:
Bug fix.
Update nightly.
New grenade fuse config.
3.10a:
Bug fix.
Update nightly.
3.10b:
4.0:
Damage script can now alter zombie transformation chance.
Add access to current difficulty level in scripts.
Add base function requirmets to buy items, crafts and solders.
Add access to geoscape soldier in scripts.
Add script that is run at end of mission.
Add arcing shoots per attack type (by ohartenstein23).
Breaking change: Renamed `action` to `battle_action` in reaction scripts.
Add battle action to `awardExperience` script.
Breaking change: Renamed access function to statis in armor (added prefix `Stats.`).
4.0a:
Bug fix.
Links
Current working branch:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended
Download available on mod site (require latest nightly):
http://www.openxcom.com/mod/openxcom-extended
Backup:
https://www.mediafire.com/folder/w07p0ibc985kd/OXCE
Forum thread:
http://openxcom.org/forum/index.php?topic=2915.msg31641#msg31641
Credits
Meridian for OXCE+ :)
stiansel for FOV speedup.
redv & WarBoy1982 for a couple of commits.
SolarusScorch for fixing language in readme.
SupSuper & WarBoy1982 & Daiky for OpenXcom :)
-
Do you interested in ready to use features for modders?
I.e:
* Radars of aircrafts can have not 100% chance to detect UFOs. https://github.com/SupSuper/OpenXcom/pull/932
* Hyperwave decoder used the rule "radarChance" too. https://github.com/SupSuper/OpenXcom/pull/931
* User can change rules of max view distance, max view distance at dark, max darkness to see unit. https://github.com/SupSuper/OpenXcom/pull/904
Max view distance at dark depend of armour that you wear.
* Ammunition for HWPs used the same rules as for aircrafts. https://github.com/SupSuper/OpenXcom/pull/895
-
Yes, when I get some free time, I will look closer on your features.
-
While you're at it... and it seems this project might be indeed what modders are looking for (I am very reluctant to custom .exes, but... so many possibilities are not to be scoofed at! As long as it can maintain the level of stability as the standard OXCom)...
https://openxcom.org/forum/index.php?topic=2788.0 - hope this isn't too convoluted, but I've come up with system that'd allow to create all sorts of "shield" items with only a short ruleset list of features and no new in-battle properties of items. Maybe you can salvage something out of it.
Another major thing would be allowing 4 weapons per craft, adding a (type) property to weapons and array of allowed types to slots, and allowing these weapons to modify the existing stats of the craft.
I just hope you won't get buried under a mountain of requests that are inevitable to follow and keep it simple, since it could mean a start of something really big...
-
This is an immensely interesting project, and as a modder I am very excited about it, but my concern is that it might too early go a different way than the basic openxcom. In other words, it's an Openxcom 2.0 that might be lacking functionalities that will show up in the future nightlies.
Therefore I think it's essential to incorporate all openxcom nightlies to this, ASAP. Otherwise we'll have competing codes, and that would be counter-productive and perhaps even destructive to the community.
I think it would be best if features implemented here would later be merged with the basic openxcom, as a "2.0". But that depends on the devs.
-
I will try keep backward compatibility with basic OXC. Best would be if any mod could work with my version without any big rewrites.
-
How much more freedom for Modders... THis much https://openxcom.org/forum/index.php?topic=2743.0 :P
-
As a lurker I had to make an account to say how exciting this idea is. I've downloaded many of the mods here and made some changes of my own, the ability to have custom damage types would open up the possibility to make much more interesting weapons. I've already looked at how the ruleset would work and thought of some changes I would make by giving different weapons custom damage types:
Grenades would do less damage to terrain, they're meant to damage living things rather than walls (applies to alien grenades specifically)
The opposite could apply to high explosive.
Stun weapons should do a small amount of health damage, and possibly cause fatal wounds.
Some new weapons could do 50/50 stun and health damage, and/or cause a larger hit to morale.
(some) armour piercing weapons could be made to be actually armour piercing.
Perhaps plasma weapons could do a large amount of damage to armour and lower morale but not so much to health, there would be more chance to survive a shot but be significantly wounded and more vulnerable afterwards.
The possibilities are nearly endless, can't wait for the exe!
-
Greetings, Dave. (https://www.veryicon.com/icon/png/System/World%20of%20Aqua%203/HAL%209000.png)
(Sorry, couldn't resist. :P)
Grenades would do less damage to terrain, they're meant to damage living things rather than walls (applies to alien grenades specifically)
This could technically be achieved by cutting the explosion power by half and then increasing vulnerability of all units in the game by 100%, but that's a very dirty solution and would create problems with blast radius. It could be done with a special flag:
terrainDamage: 0.5
(multiplies damage to terrain by 0.5)
Stun weapons should do a small amount of health damage, and possibly cause fatal wounds.
Yep, as long as it's costomizable in the ruleset.
Some new weapons could do 50/50 stun and health damage, and/or cause a larger hit to morale.
This is relatively unlikely, since AFAIK the battlescape code is very hard to work with. Someone would have to crack it first.
(some) armour piercing weapons could be made to be actually armour piercing.
hell, even I am afraid of going this way. :P
Perhaps plasma weapons could do a large amount of damage to armour and lower morale but not so much to health, there would be more chance to survive a shot but be significantly wounded and more vulnerable afterwards.
Nah, that's just lunacy. But I'd like plasma to cause fires (not my idea, but can't remember whose).
-
While you're at it... and it seems this project might be indeed what modders are looking for (I am very reluctant to custom .exes, but... so many possibilities are not to be scoofed at! As long as it can maintain the level of stability as the standard OXCom)...
https://openxcom.org/forum/index.php?topic=2788.0 - hope this isn't too convoluted, but I've come up with system that'd allow to create all sorts of "shield" items with only a short ruleset list of features and no new in-battle properties of items. Maybe you can salvage something out of it.
Another major thing would be allowing 4 weapons per craft, adding a (type) property to weapons and array of allowed types to slots, and allowing these weapons to modify the existing stats of the craft.
I just hope you won't get buried under a mountain of requests that are inevitable to follow and keep it simple, since it could mean a start of something really big...
I think about shields but I don't have jet elegant solution for that. 4 weapon is in TODO list (basic functionality is done but not merged jet).
How much more freedom for Modders... THis much https://openxcom.org/forum/index.php?topic=2743.0 :P
Tracking temporary buffs require special system for handling it. OXC don't have any thing like that. Right now I stick to ready or easy implementable features, because of this buffs are outside current scope.
As a lurker I had to make an account to say how exciting this idea is. I've downloaded many of the mods here and made some changes of my own, the ability to have custom damage types would open up the possibility to make much more interesting weapons. I've already looked at how the ruleset would work and thought of some changes I would make by giving different weapons custom damage types:
Grenades would do less damage to terrain, they're meant to damage living things rather than walls (applies to alien grenades specifically)
The opposite could apply to high explosive.
Stun weapons should do a small amount of health damage, and possibly cause fatal wounds.
Some new weapons could do 50/50 stun and health damage, and/or cause a larger hit to morale.
(some) armour piercing weapons could be made to be actually armour piercing.
Perhaps plasma weapons could do a large amount of damage to armour and lower morale but not so much to health, there would be more chance to survive a shot but be significantly wounded and more vulnerable afterwards.
The possibilities are nearly endless, can't wait for the exe!
Most of things form your list is working, only direct morale change is unimplemented.
-
Hi Yankes and Solarius
I should have explained better, my wish list was what I thought could be modifiable using the Unified Damage Types from here https://github.com/SupSuper/OpenXcom/pull/938 (https://github.com/SupSuper/OpenXcom/pull/938), which I assumed was was included in this mod. Like I say I've been lurking for a while, I read the link before and thought it looked cool but I'm not able to compile the code so was hoping it would be included in the nighties or released as an exe at some point.
As for changing plasma weapons, my thinking was it could work a bit like halo, where plasma weapons are quite good at destroying armor but not really much better than human weapons other than that. It could make things more interesting, although I admit it would make the game easier if plasma weapons weren't as good. But I get bored of everything being one-shot kills, so some way to make a weapon more likely to cause severe damage but not kill outright in one shot appeals to me.
-
You can make it work with the current ruleset options, simply adding resistance to plasma to all unarmored/lightly armored targets, whatever sense does it make :)
-
Yes - this is exactly what a modder needs.
When (or if) you get to implement ruleset defined view distance I would have one more suggestion related to it.
My two cents - I would prefer to keep backward compatibility even if it means not implementing certain mods. Keeping track of odsolete versions to play certain mods is NIGHTMARE - look at Minecraft beta mods or some older DooM mods like Zanzan DooM.
-
My two cents - I would prefer to keep backward compatibility even if it means not implementing certain mods. Keeping track of odsolete versions to play certain mods is NIGHTMARE - look at Minecraft beta mods or some older DooM mods like Zanzan DooM.
But you're asking for this when there is a code fork that will not be merged, or it's simply not sure it will be.
My take on the thing is that once TFTD support will be in beta and only bugfixes will have to be stapled down....that could be a good time to pull most of the feature requests for OXC, at least concerning the UFO part.
I see no reason to fork away at this point risking incompatibilities with TFTD specific code.
Of course I do NOT mean "do not work on this", but I'd play along the lines of doing something you're confident it will be POSSIBLE to merge, and not divergin already.
Of course I don't know if this is at all possible, eh.
-
Yes - this is exactly what a modder needs.
When (or if) you get to implement ruleset defined view distance I would have one more suggestion related to it.
My two cents - I would prefer to keep backward compatibility even if it means not implementing certain mods. Keeping track of odsolete versions to play certain mods is NIGHTMARE - look at Minecraft beta mods or some older DooM mods like Zanzan DooM.
The view distance mod is backward and forward compatible with regular version of OpenXcom.
-
But you're asking for this when there is a code fork that will not be merged, or it's simply not sure it will be.
My take on the thing is that once TFTD support will be in beta and only bugfixes will have to be stapled down....that could be a good time to pull most of the feature requests for OXC, at least concerning the UFO part.
I see no reason to fork away at this point risking incompatibilities with TFTD specific code.
Of course I do NOT mean "do not work on this", but I'd play along the lines of doing something you're confident it will be POSSIBLE to merge, and not divergin already.
Of course I don't know if this is at all possible, eh.
I may have misworded what I meant - I think that things that conflict or potentially conflict with vanilla OpenXcom mods probably shouldn't be priority. Also things that can potentially change ingame mechanics in a way that original behaviour is no longer possible with a port. I think good port for a game should be able to let one play the game in its original state as close to vanilla as possible while also supporting diverse mods.
I don't want a both way compatibility - thats nonsense and I know it. But it shouldn't end up with two completely different ports with two exclusive sets of rules.
It's similar situation like with ZDooM and GZDooM - ZDooM focuses on new mechanics and GZDooM focuses on graphics while retaining compatibility with ZDooM. So you can play ZDooM mods with GZDooM but not all GZDooM mods with ZDooM.
The view distance mod is backward and forward compatible with regular version of OpenXcom.
I know, I checked what it should do and I wanted to try building it last weekend but I had some problems. I probalby didn't merged the branch correctly. I am not used to Git. Or programming.
-
The view distance mod is backward and forward compatible with regular version of OpenXcom.
This is mostly what I was talking about. ;D
-
I think if we stick to features that aren't conflicting/redundant with what Sup & Warboy are doing, and keep features reasonable (compatible with XCom core elements & interface limitations), this is going to be merged eventually. But I wouldn't worry too much - Yankes seems to be doing this in a modular fashion so nothing that he changes is set in stone. I agree though that 1.0 is far too early to branch off - just look at all the cool features that were added to OXCom since this thread started.
-
The view distance mod is backward and forward compatible with regular version of OpenXcom.
I think this best approach, one way to archive it is do not altering save games. This will allow swamping back and forward what version you are using.
Of course some mods could be crippled, but game should be playable.
btw meanwhile I fighting with my toolchain to get exe without additional dlls like nightly. Current I installed VirtualBox and Ubuntu to get access to same toolchain like openxcom.org use of nightly :)
--- posts merge ---
After victorious battle with toolchain I created stand alone exe :)
-
Gratz!
An extended feature idea: we have strengthApplied and psiStrengthApplied... how about adding throwingApplied? This skill sees little use as of now, it could be linked with weapons like thrown knives as a damage buff. Also, would it be possible that all these applied flags would be percentage (multiplier) instead of boolean? Adding 100% strength to weapons damage is usually an overkill...
Man, more of this and we'll have XCom: Role Playing game :)
-
good idea dioxine :)
next step 20% of intelligence applied to weapon accuracy, 30% of melee skill applied to weapon power and -25% of strength applied to tu costs .. *dream*
-
Gratz!
An extended feature idea: we have strengthApplied and psiStrengthApplied... how about adding throwingApplied? This skill sees little use as of now, it could be linked with weapons like thrown knives as a damage buff. Also, would it be possible that all these applied flags would be percentage (multiplier) instead of boolean? Adding 100% strength to weapons damage is usually an overkill...
Man, more of this and we'll have XCom: Role Playing game :)
I never intended use bool for that, only "strengthApplied" is bool for backward compatibility and new functionality use [0.0, 1.0] scale.
Current options:
damageBonus:
strength: 1.0 #set default to 1 if `strengthApplied: true`
psi: 0.3 # == psiSkill*psiStrength like power of psi-amp
psiSkill: 0
psiStrength: 0
Throw could be used there too.
-
Great idea, thank you for giving us new opportunities. :)
I'd love to see more functions un-hardcoded so they could be customized.
I only have 2 small requests which I think are reasonable.:
1) Enable to use medipack on yourself (would allow special food / drugs / potions without the need of having somebody else feed them to you).
2) Enable custom explosion sprites in the same way as hit sprites
-
Ability to coup-de-grace an unconscious character.
I hate having to use a medi-kit to revive an alien just so I can shoot him again. Since you get more points for killing an alien than you do for subduing it (like 20 or 25 for the later ones, vs 10 for capture).
-
Ability to coup-de-grace an unconscious character.
I hate having to use a medi-kit to revive an alien just so I can shoot him again. Since you get more points for killing an alien than you do for subduing it (like 20 or 25 for the later ones, vs 10 for capture).
Enable Alien Bleeding. And afaik you should be getting double points for capture vs. killing...?
-
Taking site
Enviado desde mi LG-D802 mediante Tapatalk
-
Good idea with including the overall Psi in this damage formula... A modder has to be careful with that though as it maxes out at 10k (even 10200 I think) :) I love when soldier's stats are relevant to tactics in many aspects.
@Ran: I support this on both accounts although I think Warboy will (fingers crossed) create custom explosion sprites support as a part of TFTD (it needs separate underwater & above-water explosions).
-
Not sure if it's just me, but I can't get the exe to work. It loads up ok, but crashes when I try and start a new game or battle.
-
What version of OpenXcom did you have? And what error you get?
I build it based on recent nightly. Additional I tried recreate toolchain that is used for nightly builds.
Every thing should work similar way to original version of OXC.
-
I have version 1.0, I'll downloading the latest nightly first and try again.
-
Yeah that was my problem, it's working now.
Do you have any example rulesets you could share? How would I go about making stun damage also do some health damage? Is it possible to add a new damage type, if so how would I do that and get a weapon to use it?
-
I have snippets for item (like stun rod):
damageType: 6 #load default values of stun damage type
damageAlter:
ToHealth: 0.5 #this attack do half power as health damage
ToStun: 0.5 #this attack do half power as stun level
[ps]
new exe is out, updated with recent nightly, two redv mods (chance_hyperwave, chance_crafts_radar), big unit can inhale smoke, throw bonus to damage.
-
Awesome idea, but where i can find a new options list?
Edit: It seems to have a habit to crash after i end tactical mission either by escaping or completing it. Non-mod related bug. Latest version used.
-
Latest build contain ViewDistance mod. https://www.openxcom.com/mod/openxcom-extended
You can change maximum view distance, view distance at dark, threshold between daytime and night vision rules.
This ruleset contain rules by default (see attachment). It is a good starting point for your own rules.
# X-COM 1 (UFO: Enemy Unknown) ruleset
# Armour has attribute "visibilityAtDark". Default value is 20 tiles. Vanilla Xcom sets 9 tiles for humans.
# Therefore possible to make:
# - armour with night vision properties;
# - difference by night vision among alien races.
armors:
- type: STR_NONE_UC
visibilityAtDark: 9
- type: STR_PERSONAL_ARMOR_UC
visibilityAtDark: 9
- type: STR_POWER_SUIT_UC
visibilityAtDark: 9
- type: STR_FLYING_SUIT_UC
visibilityAtDark: 9
- type: TANK_ARMOR
visibilityAtDark: 9
- type: HOVERTANK_ARMOR
visibilityAtDark: 9
- type: CIVM_ARMOR
visibilityAtDark: 9
- type: CIVF_ARMOR
visibilityAtDark: 9
# Default value for "maxViewDistance" is 20 tiles.
maxViewDistance: 20
# Default value for "maxDarknessToSeeUnits" is 9.
# maxDarknessToSeeUnits is threshold between daytime and night vision rules.
# If shade 0-9, then used daytime vision rules. If shade 10-15, then used night vision.
maxDarknessToSeeUnits: 9
-
I've attached my ruleset so far, I've made the stun rod and stun bomb do health damage and cause wounds, and incendiary clips and rockets do real upfront damage. Tested both in a battle and they seem to work as expected.
I got the crashing issue with the new exe too, after leaving a battle. I've moved back to the previous exe for now, which doesn't seem to have the same issue.
-
I have a personal request:
I would really like to be sable to disable a certain mission up to a certain point of time, for example "don't create terror missions before August 1999" (just an example, not a part of an actual project). The easiest way to do this would be to enable it in alienMissions, as an additional flag somehow.
-
Latest build contain ViewDistance mod. https://www.openxcom.com/mod/openxcom-extended
You can change maximum view distance, view distance at dark, threshold between daytime and night vision rules.
This ruleset contain rules by default (see attachment). It is a good starting point for your own rules.
# X-COM 1 (UFO: Enemy Unknown) ruleset
# Armour has attribute "visibilityAtDark". Default value is 20 tiles. Vanilla Xcom sets 9 tiles for humans.
# Therefore possible to make:
# - armour with night vision properties;
# - difference by night vision among alien races.
armors:
- type: STR_NONE_UC
visibilityAtDark: 9
- type: STR_PERSONAL_ARMOR_UC
visibilityAtDark: 9
- type: STR_POWER_SUIT_UC
visibilityAtDark: 9
- type: STR_FLYING_SUIT_UC
visibilityAtDark: 9
- type: TANK_ARMOR
visibilityAtDark: 9
- type: HOVERTANK_ARMOR
visibilityAtDark: 9
- type: CIVM_ARMOR
visibilityAtDark: 9
- type: CIVF_ARMOR
visibilityAtDark: 9
# Default value for "maxViewDistance" is 20 tiles.
maxViewDistance: 20
# Default value for "maxDarknessToSeeUnits" is 9.
# maxDarknessToSeeUnits is threshold between daytime and night vision rules.
# If shade 0-9, then used daytime vision rules. If shade 10-15, then used night vision.
maxDarknessToSeeUnits: 9
I altered redv mod that you don't need define default "9" range for solders.
I've attached my ruleset so far, I've made the stun rod and stun bomb do health damage and cause wounds, and incendiary clips and rockets do real upfront damage. Tested both in a battle and they seem to work as expected.
I got the crashing issue with the new exe too, after leaving a battle. I've moved back to the previous exe for now, which doesn't seem to have the same issue.
Every mission, or only one? I would be glad if you send me save from that mission. Meanwhile I will try reproduce it myself.
-
New version crash on start for me :P
-
Do you used 1.0 or Nightly? if 1.0 then its to old. My version require Nightly to work.
Because of some strange error in my toolchain I get crash at end of every mission, if I sue different compiler, everything works fine.
I will try find cause of this.
--- posts merge ---
Ok, I find culprit, again its Warboy fault :D.
I include recent changes form Nightly, and Warboy add new functionality and changed default ruleset.
New nightly is required as base for exe.
-
One of the issues with recent nightlies that has been crashing mods:
Hitanimations:
Warboy has updated those and it now affects HE/smoke/incendiary weapons. Before these had no affect whatsoever.
Ensure your hitanimation has an appropriate value if you are using one of these weapons.
See chatlog below.
Warboy specifically, the ammo the smoke launcher uses, and the hitAnimation defined for it
06:03 FeelyMcFeelerson https://pastebin.com/4mUqkpcZ
06:03 FeelyMcFeelerson Scout_drone
06:05 Warboy hitAnimation: 26
06:06 Warboy change that to 0
06:06 FeelyMcFeelerson I have no idea what that means, but if it fixes it, it's alllright
06:06 Warboy hitAnimation refers to the sprite to use when a projectile hits its target
06:07 Warboy for HE/smoke/incendiary weapons this field did nothing whatsoever
06:07 Warboy until about two days ago when i made the explosion sprites moddable
06:08 Warboy the explosion spritesheet has 8 entries, using hitAnimation: 26 tells it to start at frame 26. there is no frame 26
06:09 Warboy the author probably got this via lazy copy/paste, and as it was vestigial at the time, it went unnoticed
Cheers, Ivan :D
-
I've been toying with the night visibility options and I want to ask one thing - The light emmited from X-Com Soldiers is counted as normal light by the engine? Because if so, Aliens will never use their nightvision stat, because every X-com soldier is standing in the light.
Otherwise, the increased nightvision for X-Com soldiers seems to work fine.
-
I updated a bit first post. More info about changes in extended version.
I've been toying with the night visibility options and I want to ask one thing - The light emmited from X-Com Soldiers is counted as normal light by the engine? Because if so, Aliens will never use their nightvision stat, because every X-com soldier is standing in the light.
Otherwise, the increased nightvision for X-Com soldiers seems to work fine.
I don't know, redv add this feature and he probably know answer for that.
-
How hard would it be to add option to disable soldier glow depending on armor used? Or maybe even add option to have enemies that glow. I tried to find where the glow is applied in the battlescape engine but its beyond my skills (it took me 5 hours and 4 tries to get the git and visual studio working).
-
I've been toying with the night visibility options and I want to ask one thing - The light emmited from X-Com Soldiers is counted as normal light by the engine? Because if so, Aliens will never use their nightvision stat, because every X-com soldier is standing in the light.
It is real light. Therefore each soldier looks like a walking christmas tree.
But you can switch off this light by pressing "L".
-
Wow, that is pretty huge design flaw there.
Quick testing, model situation: Alien can be seen by one soldier further than 9 tiles away only because its illuminated by personal light of another soldier that actually don't see this alien. If you get into this situation with light off and than turn if on - it wont update - you wont see that alien. On the other hand, when you turn the light off, you still see the alien as if it was illuminated. You can update by turning around, but thats not how it should be. Also aliens with modified nightvission suffer the same problem - and they are not that kind to update their FOV by turning around before frying the soldier with plasma.
When setting the light on or off a recalculation of FOV must be done for all soldiers (and with OpenXcom Extended even for all aliens) or else you will get into weird situations. This should be done even in main OpenXcom build. I will post a bug to feedback forum later.
But for the diferent nightvision values to work correctly this have to be modified further. My suggestions:
1) Forcing the lighting to be on all the time but let the ruleset decide if the armor is glowing or not (also applicable for aliens so you can make glowing ones).
2) Make the personal lighting toggleable soldier by soldier. And costing TUs to turn on or off while also provoking reaction fire. It would still benefit from ability to define if the armor light is on by default or not - you don't want your sneaky soldiers to give out their position in first turn. (This would probably need some new GUI for devices that don't have keyboard like android tablets)
3) Make the default glow intensity lower than 9 to be sure that nightvision rules will be used. I dont know if the light in X-Com is additive so a tile illuminated by two sources (like a soldier and flare) would have light intensity of highest value or both values added toghether.
Alternativally combination of points 2 and 3 - light is toggleable on soldier by soldier basis and it switches between daylight intensity and nightime intensity. So even when the lights are off its not pitch dark everywhere. Or even better - have ability to set if the armor have toggleable light, if its on by default, what is light intensity when on and what is light intensity when off.
-
Well, I somehow managed to externalize unit glows and it seems to work. My code is probably terrible and should be rewritten but it is good enough for a proof that it's possible and as toy for me to find out how useful it can be. At least hunting glowing blind mutons in darkness is fun.
When I figure out how to post the code to git I will send link there.
-
Wow, that is pretty huge design flaw there.
Quick testing, model situation: Alien can be seen by one soldier further than 9 tiles away only because its illuminated by personal light of another soldier that actually don't see this alien. If you get into this situation with light off and than turn if on - it wont update - you wont see that alien. On the other hand, when you turn the light off, you still see the alien as if it was illuminated. You can update by turning around, but thats not how it should be. Also aliens with modified nightvission suffer the same problem - and they are not that kind to update their FOV by turning around before frying the soldier with plasma.
When setting the light on or off a recalculation of FOV must be done for all soldiers (and with OpenXcom Extended even for all aliens) or else you will get into weird situations. This should be done even in main OpenXcom build. I will post a bug to feedback forum later.
It's not a bug, it's vanilla behavior.
If you spotted enemy units, then you know where they are.
3) Make the default glow intensity lower than 9 to be sure that nightvision rules will be used. I dont know if the light in X-Com is additive so a tile illuminated by two sources (like a soldier and flare) would have light intensity of highest value or both values added toghether.
Yes, the light in X-Com is additive.
-
It's not a bug, it's vanilla behavior.
If you spotted enemy units, then you know where they are.
I don't remmember ability to disable personal lighning in original X-Com.
-
Switch on/off an personal lighting is just a particular case.
If your soldier spotted enemy units (any manner), then you know where they are. Even if this soldier will be killed.
It's not a bug, it's vanilla behavior.
-
doing it differently would be strange
xcom is a turnbased game!
if i play oxc/monopoly/chess and close my eyes during my turn the opponents pieces dont move because i cant see them with eyes closed
sure in oxc they can shoot back but that does not change the principle of "i know there is an alien" even if the spotter is killed
-
Switch on/off an personal lighting is just a particular case.
If your soldier spotted enemy units (any manner), then you know where they are. Even if this soldier will be killed.
It's not a bug, it's vanilla behavior.
Yet other way around can happen too - you won't be able to spot an enemy even if you are looking at him because this feature - switching personal light on and off - is not properly implemented. It's more of a debug feature and as such it shoudn't be part of a gamedesign. I agree - its not bug, it's just not finished gamedesign-wise and it have to be adressed somehow - marking it as a debug feature or finishing it. Untill it's resolved somehow it is a flaw and additional mechanics shoudn't be based on it - that includes diferent nightvision values for aliens. Having such inconsistencies in a game is just bad practice and it should be avoided if possible.
-
About use case of radarChance of Hyperwave decoder.
Default value is 100. For instance, if set:
facilities:
- type: STR_HYPER_WAVE_DECODER
radarChance: 50
then chance of detection of UFOs will be 50/50 every 30 min.
Interesting option will be if set radarChance to 0.
facilities:
- type: STR_HYPER_WAVE_DECODER
radarChance: 0
In this case hyperwave decoder cannot determine position of UFO but can decode an UFOs transmissions.
My scenario:
1. Conventional radars detects UFOs.
2. Then, after 30 min, hyperwave decoder decodes transmissions and gives additional information about UFO. Blue info screen changes to red.
Looks realistic:)
-
Interesting option will be if set radarChance to 0.
facilities:
- type: STR_HYPER_WAVE_DECODER
radarChance: 0
In this case hyperwave decoder cannot determine position of UFO but can decode an UFOs transmissions.
Sorry, please clarify if this is true for the OpenXCom Extended only, or works for vanilla OpenXCom as well?
-
Extended, vanilla have always 100%
-
Sorry, please clarify if this is true for the OpenXCom Extended only, or works for vanilla OpenXCom as well?
This works only for OpenXcom Extended now.
In regular OpenXcom hyperwave decoder always has 100% chance of UFO detection.
Maybe later will work in regular OpenXcom too:)
Pull request was send: https://github.com/SupSuper/OpenXcom/pull/931
-
It makes a lot of sense, thou 30 minutes might be both A LOT or NO SWEAT.
I'll try out it in the future
-
(multiplies damage to terrain by 0.5)
In truth the way the game originally worked was it had a set of Armor Multipliers in Castes. The ETs, Tanks, Soldiers each had different Castes they belonged to (13 of them) which applied the damage multipliers.
Caste 0 (Unarmored) was used by terrain.
It would be better to just give Armor Multipliers for Terrain in that case. Applicable to all terrain just to get started.
I made a mod once for TFTD which adjusted the armor multipliers for terrain so that different weapons did altered damage to them. For example I lowered it for Gauss and AP so human weapons wouldnt put holes in walls. Raised it for Explosives (for everyone actually) because I lowered explosion damage across the board (to decrease explosion size). Raised it for Sonic so that way sonic shots would almost always melt walls.
Actually I lowered the numbers all over to make it consistent with smaller explosions, but I raised the damage multipliers in many cases so it was still as effective as before.
-
I made a mod once for TFTD which adjusted the armor multipliers for terrain so that different weapons did altered damage to them. For example I lowered it for Gauss and AP so human weapons wouldnt put holes in walls. Raised it for Explosives (for everyone actually) because I lowered explosion damage across the board (to decrease explosion size). Raised it for Sonic so that way sonic shots would almost always melt walls.
By the way, from what I've recently read, it's easier to knock down a building with a blast of an explosion than to kill a person. Overpressure that is sufficient to collapse most of buildings would just burst eardrums of 1% of people affected by it.
-
Next build of OpenXcomExtended will have some craft improvements.
Now every craft can have up to 4 weapons.
Every weapon slot and every weapon can have defined weapon type.
Only weapons with same type can be equipped in that weapon slot.
craft:
weapons: 4
weaponTypes: [0, 0, 0, 1] # slot 1 accept weapon with type 0, ... slot 4 accept weapon with type 1
craft weapon:
weaponType: 1 #default value 0
My next target will be probably bonus stats in craft weapons.
-
Yep. I read a thing a while ago too (possibly the same thing) saying that the military is starting to lean away from using buildings as cover from small arms due to thermobaric warheads becoming more prolific on the arms market.
They did a study iirc and found that, all things being equal, they'd usually just be better off being shot at individually than putting all their eggs in one basket, so to speak.
Also, for some reason (probably something to do with transmission of the concussive blast) ordinary ballistic armour actually makes such threats MORE dangerous. So ingame that'd be a negative damage modifier I guess, although having armour that makes your more vulnerable to explosives does seem very counterintuitive.
-
Can you put ay the end of a mission a page tha sais the increased stats of soldiers. This is interesting to manage the squad
And a option to recover countries to council again XD
Enviado desde mi LG-D802 mediante Tapatalk
-
Can you put ay the end of a mission a page tha sais the increased stats of soldiers. This is interesting to manage the squad
And a option to recover countries to council again XD
I Second this motion. Many a time have I been stuck with Russia as my only funding (Though I had a constant Laser Tank factory selling stuff at the same time, so forget everyone else :P)
Also Stat improvements will be a bit of an overflow, everyone in the mission AFAIK gets improvements to almost every stat, and how to fit all of that in one line seems to be a very hard puzzle (even people who do daily sudoku books will have a hard time with this!)
-
Maybe with colored bars? Every stat has a different color, so soldier name followed by multi-colored bar - each +1 is 2 pixels width of a given color...
I agree with you on principle (it is sudoku-difficult as the soldiers increase a lot of stats) but seeing stat increases would be awesome none the less :)
-
It's a neat idea, and besides I don't see the problem of the UI.
Of course one woudl have to design a new debrief screen with the soldiers stats embedded.....
-
Quick question about the visibilityAtDark setting on armors. If I have mods that add extra aliens, will I have to set this property on their armors to 20 otherwise they will have the default visibility of 9? Or will the game give them a default visibility of 20 in the dark because they are aliens?
Edit: I have another request to improve the AI in a way I think could be added to the ruleset as so not to affect unmodded OpenXcom. The AI at the moment hardly ever uses autoshot. This is even more noticeable when using mods like Xeno operations, where the aliens get the plasma assaulter which has a great autoshot which the aliens refuse to use unless the target is within 3 squares of them.
One solution would be to rewrite the AI to chose the type of shot that gives them the best chance of hitting based on distance (if using ufoextender accuracy). This could easily be calculated, but would change the AI for everyone and some might prefer the vanilla AI that hardly ever uses autoshot.
So instead, perhaps a property could be added to the item. My understanding of the code is that the AI prefers to use autoshot if the target is less than 4 squares from them, prefers to use aimed shot if the target is more than 12 squares from them, and will prefer to use snapshot otherwise. They will only use other types of shot if they don't have enough TUs to use the prefered shot. Could these values come from the ruleset instead? E.g. have an AIAutoRange and an AIAimedRange property on the item, that defaults to 4 and 12. Then this could be modified in a ruleset to allow the AI to use each weapon more effectively.
-
Quick question about the visibilityAtDark setting on armors. If I have mods that add extra aliens, will I have to set this property on their armors to 20 otherwise they will have the default visibility of 9? Or will the game give them a default visibility of 20 in the dark because they are aliens?
visibilityAtDark sets 20 tiles for aliens and 9 tiles for humans by default.
Therefore all extra aliens will see 20 tiles at dark.
If you don't want change this, then you dont need write extra "visibilityAtDark" strings in your ruleset.
-
Can I pull down a branch and work on fixing the shotgun hack so that is not a hack?
-
Yup, if result is less hackly than current solution I will gladly include it to may branch.
BTW do you have plan how to fix it?
-
New feature, crafts weapon can alter craft stats.
For now you can change:
stats: #stats that are add to crafts stats
fuelMax: 0
damageMax: 0
speedMax: 0
accel: 0
radarRange: 0
radarChance: 0
sightRange: 0
-
Ohhhh posibilities. Fuel extend . turbo boost. Power acelerator.
May be extra cargo for skiranger??? More soldiers or one more tank XD
Enviado desde mi LG-D802 mediante Tapatalk
-
New feature, crafts weapon can alter craft stats.
For now you can change:
stats: #stats that are add to crafts stats
fuelMax: 0
damageMax: 0
speedMax: 0
accel: 0
radarRange: 0
radarChance: 0
sightRange: 0
this + the 4 slots.. if the goal was an Apocalypse-like customization (for crafts), then you have reached it.
(Now we'd need UFOs to do a little more too, they should at least have the option to get a second weapon :P ).
I haven't followed the development, but I wish this to be integrated with the main OXC release.
-
(Now we'd need UFOs to do a little more too, they should at least have the option to get a second weapon :P ).
Yes, they should have the ability to FIRE ZE MISSILES!
-
May be extra cargo for skiranger??? More soldiers or one more tank XD
This will require to much effort to implement that this is worth. This is limited primary by battlescape and adding any number will not fix that.
Another problem is adding new code that will throwing out stuff from craft when you remove weapon that give out additional solder/tank slot.
-
This will require to much effort to implement that this is worth. This is limited primary by battlescape and adding any number will not fix that.
Another problem is adding new code that will throwing out stuff from craft when you remove weapon that give out additional solder/tank slot.
Ok. Only is a idea. But may be possible others options in future.
Enviado desde mi LG-D802 mediante Tapatalk
-
So instead, perhaps a property could be added to the item. My understanding of the code is that the AI prefers to use autoshot if the target is less than 4 squares from them, prefers to use aimed shot if the target is more than 12 squares from them, and will prefer to use snapshot otherwise. They will only use other types of shot if they don't have enough TUs to use the prefered shot. Could these values come from the ruleset instead? E.g. have an AIAutoRange and an AIAimedRange property on the item, that defaults to 4 and 12. Then this could be modified in a ruleset to allow the AI to use each weapon more effectively.
I have a feeling it should change dynamically according to:
- weapon accuracy (use less accurate firing modes if it's accurate enough - say, use Snap Shot over Aimed Shot if chance to hit is 75% or more),
- autoshots number (the more bullet a weapon spews per auto shot, the higher the preference for using auto shot).
I believe it would make for a much more robust, versatile and efficient AI system, at a small cost of adding these formulas.
BTW , I'm really excited about the new weapon type/slot system. Really excited. :)
-
Yeah it'd be best for the AI formula to simulate player's line of thought, meaning it'd usually go for a maximum overall chance to hit (hence range calculations are crucial), with a random factor added.
-
Small update with two changes:
`fix fixed weapon (should always placed into "hands")` by redv
`Support for fire and smoke for any damage type`
And recent fix form nightly.
-
new build,
I added bit more depth to craft combat. Now craft & ufo can have armor that reduce damage, better hit chance and better avoidance.
New hit formula:
newHitChance = oldHitChance + attacker->hitBonus - target->avoidBonus
Additional craft weapon can now buff overall damage form all weapons.
Ufo can have different stats based on race that use it.
Items now can be available in shop if you research require technologies (change for Solarius Scorch's FMP+).
-
Awesome. I'm obviously happy for my request being granted, and the new air combat mechanics are very exciting.
-
Seems that Warboy has double-backed on the Limited Psi Weapon Range formula; from about two dozens test battles however I am pretty sure that was the exact thing needed to finally balance Psi. Can we count on a (working) version of limited range (OR extarnalizing the Psi formulas so one could affect a similar effect by increasing range penalty for psi power usage - ideally tied to psi items and working like "dropoff" works for firearms)?
-
Seems that Warboy has double-backed on the Limited Psi Weapon Range formula; from about two dozens test battles however I am pretty sure that was the exact thing needed to finally balance Psi. Can we count on a (working) version of limited range (OR extarnalizing the Psi formulas so one could affect a similar effect by increasing range penalty for psi power usage - ideally tied to psi items and working like "dropoff" works for firearms)?
Increased range does penalty for PSI attack. It is vanilla behavior. https://www.ufopaedia.org/index.php?title=Psionics
Attack Strength (AS) = INT( Psi Strength * Psi Skill / 50 ) Attacker stats
Defense Strength (DS) = INT( Psi Strength + ( Psi Skill / 5 ) ) Defender stats
Constant = 25 for Mind Control; 45 for Panic
Attack Success (A%) = 100/56 * ( Constant + AS - DS - Distance )
Therefore psi abilities limited by distance "by design".
-
Note that I wrote "INCREASING range penalty" not "INTRODUCING range penalty" and I am well aware of psionic equations, I was using them extensively to balance psi interactions in my mod. I meant extarnalizing the *exact* "dropoff" value for psi weapons associated with distance, because the vanilla value has (in my subjective opinion) a rather slim effect, as AS tops at about 200, DS can be over a 100, and the distance of above 25 is basically "everywhere", so there's about 5:1 domination of power factor over the distance factor.
-
"Dropoff" of firearms (different by type of shots) is just a silly workaround instead of using true "range based accuracy" formula.
Artificial "dropoff" of psi abilities will be the same workaround. You can balance psi-interactions by increasing psi-strength of aliens (for instance +30 or +40 psi str works well).
-
"Dropoff" of firearms (different by type of shots) is just a silly workaround instead of using true "range based accuracy" formula.
Not exactly. The FMP modpack is balanced for UFO Extender Accuracy, but still I'm using dropoff to increase weapon versatility. (It was actually Dioxine's idea.) The basis being dropoff is not equal to accuracy; for example pistols and shotguns are quite accurate, but only on short distances.
-
"Dropoff" introduced in UFO Extender. I mean UFO Extender Accuracy is a silly workaround. For instance, you see that your chance to hit 50%. In attached picture you can see a difference among different models of shooting. So, UFO Extender accuracy looks very strange.
-
Shouldn't your graph look more like " -< " for the UFOExtender Accuracy? There is no big loss in accuracy at a certain point (your horizontals), just that you start losing some in a linear fashion after a certain distance.
If you want weapons that behave like your graph on the left, just give them high accuracy and an optimal range of 1, then the dropoff will kick in and reduce your accuracy linearly with distance starting 2 tiles away. The system is there.
I agree with Dioxine that adding a "DistanceFactor" that can be modded would be a good thing for mods. Changing the equation to:
Attack Success (A%) = 100/56 * ( Constant + AS - DS - DistanceFactor*Distance )
would allow to give more or less impact to distance depending on what the modder intends, which is not the same as just a flat increase in alien psi strength.
With that, you could make the psi system more complex, with XCom's first psiamp having a huge distance factor so it is really short range, then later version diminishing that to represent better understanding of psi-tech. Or.. I'm not sure if it is possible to give different psi-weapons to the aliens, but sectoids could have a larger factor, representing that they are not as adept mind controllers as Ethereals (who themselves could have various versions by ranks, some which need LoS, some which don't).
There's a lot that could be done with the psi-system. Externalizing the parameters would be great.
-
If you want weapons that behave like your graph on the left, just give them high accuracy and an optimal range of 1, then the dropoff will kick in and reduce your accuracy linearly with distance starting 2 tiles away. The system is there.
It's wrong.
Angle in range based accuracy depends on accuracy. But angle in UFO extender will be always the same (~pi/2) even if you set 100% accuracy.
I agree with Dioxine that adding a "DistanceFactor" that can be modded would be a good thing for mods. Changing the equation to:
Attack Success (A%) = 100/56 * ( Constant + AS - DS - DistanceFactor*Distance )
would allow to give more or less impact to distance depending on what the modder intends, which is not the same as just a flat increase in alien psi strength.
I suggested increase psiStr, then will be increased DS. Therefore Attack Success will be decreased.
You suggested increase Distance by increasing DistanceFactor. Therefore Attack Success will be decreased.
The result will be the same: Attack Success will be decreased.
If there is no difference, why need write new code?
-
Note that I wrote "INCREASING range penalty" not "INTRODUCING range penalty" and I am well aware of psionic equations, I was using them extensively to balance psi interactions in my mod. I meant extarnalizing the *exact* "dropoff" value for psi weapons associated with distance, because the vanilla value has (in my subjective opinion) a rather slim effect, as AS tops at about 200, DS can be over a 100, and the distance of above 25 is basically "everywhere", so there's about 5:1 domination of power factor over the distance factor.
I think that will be easy to do. I will look for things that can be externalized. One thing I will try do is apply same code to AS like in power bonus from normal weapons. This will allow creating psi-amp that is great for solder with big psi skill or only with psi strength (or normal strength or throw, but this is only side effect :D)
-
It's wrong.
Angle in range based accuracy depends on accuracy. But angle in UFO extender will be always the same (~pi/2) even if you set 100% accuracy.
That's true, the accuracy loss is always the same for a given weapon, range & shot combination. It might be better if it depended on the soldier as well. But given that the initial accuracy does depend on the soldier, the accuracy at range does too. A better marksman will have better odds of hitting at long range, just by virtue of having a greater chance to hit from which to substract the range adjustment.
You can control the angle by setting the "dropoff" properties of weapons, the increment by which accuracy is reduced for a tile (default = 2, but you can set a shotgun to, say, 5 so it becomes useless quickly at range, and a marksman or laser rifle to 1, to represent that range has little impact).
I suggested increase psiStr, then will be increased DS. Therefore Attack Success will be decreased.
You suggested increase Distance by increasing DistanceFactor. Therefore Attack Success will be decreased.
The result will be the same: Attack Success will be decreased.
If there is no difference, why need write new code?
Because your way makes it more difficult to use psi at all distances, whereas adding a factor there can make it more difficult only when the target is far away? Both might make it more difficult, but they're really not the same thing... With a factor, controlling a sectoid standing right next to you may be easy, but one far away won't be. With increased psi-strength, both will be as easy/hard to control. In fact, increasing psi-strength decreases the relative importance of distance even further...
The idea here is to add a similar but different mechanic from weapons where psi do not need LoS (so they are different), but also do not work at all distances (because then it's too powerful and becomes boring). I will be experimenting with setting a maxrange on psi weapons (and maybe giving ethereals a better weapon than sectoids, to allow them to use psi from farther away). You can do that in vanilla, right?
Then I'll wait for warboy to triple back and put in a moddable modifier..! ;)
-
That's true, the accuracy loss is always the same for a given weapon, range & shot combination. It might be better if it depended on the soldier as well. But given that the initial accuracy does depend on the soldier, the accuracy at range does too. A better marksman will have better odds of hitting at long range, just by virtue of having a greater chance to hit from which to substract the range adjustment.
You can control the angle by setting the "dropoff" properties of weapons, the increment by which accuracy is reduced for a tile (default = 2, but you can set a shotgun to, say, 5 so it becomes useless quickly at range, and a marksman or laser rifle to 1, to represent that range has little impact).
It's wrong. Look at the code:
Start of calculate "modifier": https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/Projectile.cpp#L264
Result: https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/Projectile.cpp#L283
Therefore before some threshold probability to hit depends on accuracy. After threshold probability always set to 0. Therefore after threshold angle will be always the same. You cannot control this angle, because the angle is hardcoded: https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/Projectile.cpp#L304
-
I'm starting to think we're talking about different things.
From the code, it does seem like the dropoff is taken into account, so your accuracy (the % to hit displayed on top of your cursor) depends on: Firing accuracy, weapon accuracy and the distance beyond max range * dropoff. Basically, chance to hit = FiringAccuracy * WeaponAccuracy - (DistanceOverMax * DropOff).
Now if that value drops to zero or lower, it is set to 0. Afterall, you can't have less than a 0% chance to hit. What happens when it is 0% is beyond me from a code perspective, but game wise, you miss, which is as expected.
I was talking about the period during which accuracy is above 0% and how that value decreases. I am guessing you are talking of when it hits 0% and beyond? And/Or about what happens when you have above 0% but miss the shot? In those cases, where the shot goes can indeed be really weird (and usually tends to be towards a fellow operative, or a civilian ;)). That could (should?) indeed be improved upon so I guess.. we agree on that?
-
@redv
Let's take 2 instances of MC attempt. In the first one, I am increasing alien's Psi strength by +10. In the other, I am increasing Distance factor by a factor of 2.
Each of these 2 instances will be cacled for ranges 10, 20 and 30. Let's assume Psi Str attacker = 100, Skill = 50 and basic Psi Str of an alien = 30
So, AS is constant (5000/50 = 100) while DS is 30 in the first case, 40 in the second case.
1.
A%@dist 10 = 0.56*(25+100-40-10) = 0.56*75 = 42
A%@dist 20 = 0.56*(25+100-40-20) = 0.56*65 = 36.4
A%@dist 30 = 0.56*(25+100-40-30) = 0.56*55 = 30.8
2.
A%@dist 10 = 0.56*(25+100-30-20) = 0.56*75 = 42
A%@dist 20 = 0.56*(25+100-30-40) = 0.56*55 = 30.8
A%@dist 30 = 0.56*(25+100-30-60) = 0.56*35 = 19.6
As you can see, while it is possible to balance with enemy's Psi Str on a given distance, the results are quite different for different distances. And I don't quite get what "artificial solution" means and what does it all have to do with projectile cones and angles.
EDIT: but I think you're saying that instead of an artificial % chance, the effective accuracy@range should effect the deviation of a bullet, thus rendering UFO's current accuracy formulas useless.
EDIT2: to be more clear, the current accuracy operator is "a chance to pick the perfect trajectory"; in your approach, this would be irrelevant, as accuracy operator would be "the tighteness of Gaussian cone of possible deviation angles". Am I right?
-
Now if that value drops to zero or lower, it is set to 0. Afterall, you can't have less than a 0% chance to hit. What happens when it is 0% is beyond me from a code perspective, but game wise, you miss, which is as expected.
I was talking about the period during which accuracy is above 0% and how that value decreases. I am guessing you are talking of when it hits 0% and beyond? And/Or about what happens when you have above 0% but miss the shot? In those cases, where the shot goes can indeed be really weird (and usually tends to be towards a fellow operative, or a civilian ;)). That could (should?) indeed be improved upon so I guess.. we agree on that?
I talking about chance to hit 50% (for instance) in vanilla Xcom meaning.
But in UFO extender, after threshold accuracy sets to 0.
Actually the game is 3D. You can press F10 in battlescape and see a 3D screenshot.
Therefore even if accuracy = 0 (after threshold) you still have chance to hit in 3D space. But the angle is hardcoded.
In my opinion this behavior just workaround. True range based accuracy will be work better and will be logically in 3D.
-
50% hit chance in vanilla means there's a 50% chance of "autoaim" kicking in and the bullet following a trajectry that the game calculates as a true shot; and 50% of it going randomly astray.
Let's start calling your system "angle-based accuracy" because the XComUtil system is also based on range (as opposed to binary accuracy in vanilla), so your monicker "range-based accuracy" is either sloppy or consciously misleading.
However I am not sure if it will work. For starters, we assume the formula is not cheating and calculates deviation without any secret modifiers. Therefore the hit chances drop geometrically: if at 10 tiles away a target has a cross-section, for example, 20 units, it will only have a cross-section of 5 at 40 tiles away. A 100% hit chance at 10 tiles turns into 50% chance at 20 tiles, 25% hit chance at 40 tiles and so on. While this would work for a game with real ranges involved, I am not 100% sure it will work for much more abstract XCom.
Perhaps more sensible will be adding a better Gaussian formula to the current system, which would kick in when the shot misses; so it doesn't miss randomly but in a flexible cone dependant on the original to-hit chances. However if the cone is too tight, much of the dice-rolled misses would hit anyway, so it wouldn't be any good.
-
i made an image that shows the drop of accuracy using pure "angle" based accuracy
i defined 100% accuracy as always hits ethereal sized unit from 6 tiles away (if no obstacle)
one can of course change the distance (6) part but the geometrical loss of accuracy always leads to "use the best accuracy weapon"-strategy in all cases :/
-
the geometrical loss of accuracy always leads to "use the best accuracy weapon"-strategy in all cases :/
Even worse, it defeats the purpose of three separate firing modes - with just 2 positive variables (accuracy, TU%), either all three modes are perfectly balanced to deliver exact same DPS, or they're not which makes one mode default and the other 2 modes inferior and probably never used. Further mechanics would have to be introduced (like recoil etc.) to fix that crudeness.
-
Nice work Falko!
One thing we see is that accuracy drops faster and faster as distance increase (fixed cross-section compared to the sherical area which grows as r^2) and means you better be standing right in the face of something to hit it. This explains why it's so hard to hit things in real life (a small deviation in aim means you're missing by a huge amount with some distance), but wouldn't be much fun in XCom, except maybe for a Really Up Close and Personal where you mostly use melee and don't bother shooting outside of a few tiles.
Perhaps more sensible will be adding a better Gaussian formula to the current system, which would kick in when the shot misses; so it doesn't miss randomly but in a flexible cone dependant on the original to-hit chances. However if the cone is too tight, much of the dice-rolled misses would hit anyway, so it wouldn't be any good.
YES! Please! Get rid of "sniper hits 95% of the time, but boy, when he misses, the shot actually goes sideways!". And maybe tighten the gaussian depending on the shot type? From autoshot being pretty wide to aimed shot being pretty tight?
-
A gaussian dice roll, and a formula that only improves upon the current model, instead of throwing it out of the window. The % value calced by Xcomutil Extender still holds true... *in lab environment*. For a standard-sized target. Suddenly though, 100% shots start to miss when there is some cover involved, or the target is small. Conversely, a dice roll that would normally be a few points short of the target value and go completely astray (like that 95% sniper) could still reliably hit a HWP or even a big powered armor with a large Loftemps cross-section defined (you may not know that, but 1-tile units have 5 or 6 varied thickness cyllinders to represent them in 3d space). Accuracy values of over 100% would finally be of use to defeat cover; and most importantly for myself, kneeling behind a rock or shooting from a window would make you really less likely to be hit.
(https://i242.photobucket.com/albums/ff62/max_smirnov/Hits_zps093e4665.png) (https://s242.photobucket.com/user/max_smirnov/media/Hits_zps093e4665.png.html)
(https://i242.photobucket.com/albums/ff62/max_smirnov/DiceBasedDeviations_zpsaa6b6c5b.png) (https://s242.photobucket.com/user/max_smirnov/media/DiceBasedDeviations_zpsaa6b6c5b.png.html)
-
a solution to counteract the geometrical loss of accuracy:
instead of randomly shooting within the cone of fire we would shoot more frequently in the middle and less frequently on the edges of the cone
see image
lets say " [snap,auto,aim]Range" defines the distance where shot on ethereal sized unit hits 50% of the time (without obstacles) so " [snap,auto,aim]Range" defines the maximal size of the cone(angle)
and accuracy defines the angle distribution so high accuracy soldier + high accuracy weapon = very high likelihood to hit exactly in center and hopefully avoid obstacles or hit targets further away
it makes hitting 4tile units easier then now
i think it makes close combat more realistic
it makes use out of accuracy values >100%
[not sure how exactly shotguns work so no idea how it would integrate into this]
enabling angle based accuracy would need to lower the aimrange default value to ~40 so we can calculate a realistic sized cone for each shot type that does not overpower the aimshot
-
Let's start calling your system "angle-based accuracy" because the XComUtil system is also based on range (as opposed to binary accuracy in vanilla), so your monicker "range-based accuracy" is either sloppy or consciously misleading.
However I am not sure if it will work. For starters, we assume the formula is not cheating and calculates deviation without any secret modifiers. Therefore the hit chances drop geometrically: if at 10 tiles away a target has a cross-section, for example, 20 units, it will only have a cross-section of 5 at 40 tiles away. A 100% hit chance at 10 tiles turns into 50% chance at 20 tiles, 25% hit chance at 40 tiles and so on. While this would work for a game with real ranges involved, I am not 100% sure it will work for much more abstract XCom.
Perhaps more sensible will be adding a better Gaussian formula to the current system, which would kick in when the shot misses; so it doesn't miss randomly but in a flexible cone dependant on the original to-hit chances. However if the cone is too tight, much of the dice-rolled misses would hit anyway, so it wouldn't be any good.
I don't understand what do you mean about "angle based" because if you use normal distribution, then angle = 360 degree.
Range based accuracy was a part of OpenXcom long time ago.
Latest working code: https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L314
Advantages:
- true calculation based on normal distribution;
- taken into account shades on the target;
- if unit on the knee, then chance to hit them reduced;
- taken into account smoke between shooter and target;
- recoil. next shot of autoshot reduces accuracy.
Disadvantages:
- unsupported latest changes in code.
I mean this range-based accuracy.
-
Then I clearly misunderstood you, sorry. I was thinking of replacing the base mechanics that selects a "golden" trajectory with a cone of fire (hence angle), with a gaussian spread. Could you explain how your system works, in math terms, because not everyone knows C++? Doesn't it make current weapon stats completely off-balanced?
(about the scripts that mod the hit chance based on disputable ideas like not seen personally or recoil - this is beside the point now)
-
1. calculate a baseDeviation in radian (+- 3 sigma) https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L352
restrictions: 0.02 <= baseDeviation <= 2.45
2. calculate horizontal and vertical deviations in radian, based on normal distribution (you calls it "gaussian spread")
https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L363
3. calculate a target voxel: https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L372
it's all:)
-
@Yankes! I just remembered an important feature that's missing in the original: ability to declare (if desired) separate bigob and floorob for a creature/soldier that's not killed only stunned. Could it be added to the wishlist at least? :)
-
I will try do it in next build.
-
This is looking pretty great! Keep up the good work!
-
Yankes/redv, a proposal for an extended feature that should be pullable easily into UPSTREAM: make soldiers in a base sortable even f there is no trooper craft (i.e. Radar Base defense troopers), best would be if they could also be equipped & armored like in the equip craft screen.
I know it is of limited use since there is real "deployment order" on base defense but it's a perk of mine to be able to set up my squad in advance and sort them as well.
Cheers.
Andy
-
This would better fit official branch. Another things is scope of my mod, I prefer stick to ruleset improvements for mod authors.
-
My small PC is having performance problems with this mod (and the Real Vision exe as well), so I have to stick to the default exe... :-[
But what some others here say is true: Essential things like this mod should be combined and added to the default game, maybe combining it with the Real-Vision mod and adding the excellent performance of the default game *dreams*.... :)
-
New update.
All ammo types have new property "powerRangeReduction" reducing power per tile passed.
Psi-amp now can use weapon "power" as bonus to psi attack, can use "damageBonus" and "powerRangeReduction".
Weapons, grenades and corpses have "floorSpriteAlt" and "bigSpriteAlt" for live unit, loaded gun and armed grenade.
My small PC is having performance problems with this mod (and the Real Vision exe as well), so I have to stick to the default exe... :-[
Did you increase vision range? without it performance should be equal.
-
....
Weapons, grenades and corpses have "floorSpriteAlt" and "bigSpriteAlt" for live unit, loaded gun and armed grenade.
This is a lovely idea. :)
-
My small PC is having performance problems with this mod (and the Real Vision exe as well), so I have to stick to the default exe... :-[
Could you send me a battlescape save file, where performance of OpenXcom extended (with default vision range) lesser than in regular OpenXcom?
-
You people are really, really tempting me to move my mod developement to this Extended version... You'll be catching, if not the best, then at least the largest mod out there :)
Question: are night/day sight ranges already implemented (and hopefully armor-dependant)? I don't want anything as radical as Real Vision, but in my mod (and perhaps others) you're, for example, facing humans, who shouldn't see in the dark any better than you do... Also swicthable personal light! I can actually navigate my soldiers in complete darkness. Naturally this isn't an easy order, because without the flashlight, there should be an option to see the battlefield in some sort of NV... (a simple monochrome filter that's activated by a hotkey and shows all visible tiles as lit-up, even in complete darkness? Alternatively, every unit, enemy or otherwise could simply emit *very* weak light, like strength 10 or below, and the right visibility can be adjusted based on that premise...
Oh yeah and an enhancement suggestion: Afaik Warboy overrode Sup's suggestion that BuiltInWeapons should be tied to armors, not units. Which is a wrong move, because tying them to armors doesn't yield any special problems, BUT allows X-Com soldiers to use 2x2 armor suits! (tested, works, but ofc without the possibility to have any weapons); and I tell you, a soldier prancing around in a SECTOPOD armor feels just AWESOME. Or generally suits of armor with built-in weapons which modders would certainly appreciate... (Terminator Suits? One hand free, the other has a Power Fist :) )
And even less important suggestion. Would it be possible for an armor to have a list of *disabled* inventory sections? Ex. if a guy has a formal suit, he shouldn't be able to use backpack. :)
Oh and there is a certain... bug? Despite the hand having 2x3 size, it can hold an object of any size. Should this be disabled? What do you think? I am not sure myself, they're pros and cons here.
One more! Weapons doing direct Morale damage (with that, I could finally make a properly working incendiary), treating (110-Bravery) as Resistance. So ex. a flamethrower deals 200 Morale damage, completely panicking anyone of Bravery 60 or less, but doing only 20 morale damage to a 100 Bravery guy. Ofc this base resistance is further multiplied by standard fire res (so a Power Armored guy is completely immune, but if we dropped Reaper to 100 Bravery, with his 170% fire weakness, he'd suffer 34 morale damage, instead of 20)...
-
Could you send me a battlescape save file, where performance of OpenXcom extended (with default vision range) lesser than in regular OpenXcom?
I used the default vision range as I didn't know that I actually could increase the vision range :D
Seriously, the mod needs a readme at least, I was rather dumbfounded when I extracted the EXE and could not find a documentation. :-[ Luckily I had downloaded the corresponding Openxcom.com-link site so i could apply the zombiImmune setting to an armor I had made, but then I ran into the performance problems. It is not as pronounced laggy as the Realvision mod (which basically stops for a splitsecond every 2 steps a unit makes) but still enough to make me revert back to the default exe.
-
I confirmed that toolchain I use for creating release build have some bug that causing lower performance than normal.
I'm now working on fixing it.
You people are really, really tempting me to move my mod developement to this Extended version... You'll be catching, if not the best, then at least the largest mod out there :)
Question: are night/day sight ranges already implemented (and hopefully armor-dependant)? I don't want anything as radical as Real Vision, but in my mod (and perhaps others) you're, for example, facing humans, who shouldn't see in the dark any better than you do... Also swicthable personal light! I can actually navigate my soldiers in complete darkness. Naturally this isn't an easy order, because without the flashlight, there should be an option to see the battlefield in some sort of NV... (a simple monochrome filter that's activated by a hotkey and shows all visible tiles as lit-up, even in complete darkness? Alternatively, every unit, enemy or otherwise could simply emit *very* weak light, like strength 10 or below, and the right visibility can be adjusted based on that premise...
Oh yeah and an enhancement suggestion: Afaik Warboy overrode Sup's suggestion that BuiltInWeapons should be tied to armors, not units. Which is a wrong move, because tying them to armors doesn't yield any special problems, BUT allows X-Com soldiers to use 2x2 armor suits! (tested, works, but ofc without the possibility to have any weapons); and I tell you, a soldier prancing around in a SECTOPOD armor feels just AWESOME. Or generally suits of armor with built-in weapons which modders would certainly appreciate... (Terminator Suits? One hand free, the other has a Power Fist :) )
And even less important suggestion. Would it be possible for an armor to have a list of *disabled* inventory sections? Ex. if a guy has a formal suit, he shouldn't be able to use backpack. :)
Oh and there is a certain... bug? Despite the hand having 2x3 size, it can hold an object of any size. Should this be disabled? What do you think? I am not sure myself, they're pros and cons here.
One more! Weapons doing direct Morale damage (with that, I could finally make a properly working incendiary), treating (110-Bravery) as Resistance. So ex. a flamethrower deals 200 Morale damage, completely panicking anyone of Bravery 60 or less, but doing only 20 morale damage to a 100 Bravery guy. Ofc this base resistance is further multiplied by standard fire res (so a Power Armored guy is completely immune, but if we dropped Reaper to 100 Bravery, with his 170% fire weakness, he'd suffer 34 morale damage, instead of 20)...
This is per armor. Without value its use 20 for enemies or 9 for rest.
Fixed weapons for armor can be added. I will look on this in next week. If I don't encounter any roadblocks it will be done.
Disabling inventory parts will be more tricky because it's used in multiple places (AI, auto/pre-battle equip, UI). Right now I say it's on TODO list.
Normal game don't have problems with this because all items have smaller or equal size. What is point in objects bigger than 2x3? Depending on this we could answer if that objects could be hold in hands.
"ToMorale" can be added easily (I will add "ToEnergy" too), but only concerns is what do with current morale loose behavior (final damage to health and wounds)? I think about options "IgnoreMoraleLose" that turn off standard behavior.
-
Good to hear that about the rework! And please: Remember to add some documentation, pleeeeease! ;D
-
find 10 differences:
CXXFLAGS = -Wall -o3 -s `$(SDL_CONFIG) --cflags`
and
CXXFLAGS = -Wall -O3 -s `$(SDL_CONFIG) --cflags`
My release build was without optimization...
Fixed version is uploaded to mod portal.
Good to hear that about the rework! And please: Remember to add some documentation, pleeeeease! ;D
Documentation could be first post in this thread and mod page. I didn't add any documentation because I didn't except anyone for using my mode as standalone. This should be base/additional for bigger mods. In ext build I will add some readme to zip.
-
Question: are night/day sight ranges already implemented (and hopefully armor-dependant)? I don't want anything as radical as Real Vision, but in my mod (and perhaps others) you're, for example, facing humans, who shouldn't see in the dark any better than you do... Also swicthable personal light! I can actually navigate my soldiers in complete darkness. Naturally this isn't an easy order, because without the flashlight, there should be an option to see the battlefield in some sort of NV... (a simple monochrome filter that's activated by a hotkey and shows all visible tiles as lit-up, even in complete darkness? Alternatively, every unit, enemy or otherwise could simply emit *very* weak light, like strength 10 or below, and the right visibility can be adjusted based on that premise...
I have semi working version of this - Glow of units can have different intensity and depends on armor (aliens can glow now), I have a modificable night and day sight ranges dependant on armor. But as a side effect aliens that you control does not glow anymore. I want to make a compatibility option to retain vanilla behaviour if needed. Problem is that I didn't get to work on this for two weeks now...
-
In latest OpenXcom Extended, personal lighting not taken into account when calculating visibility. Therefore personal lighting now just for comfort but not as a part of gameplay.
Looks like it works as expected, but i need feedback.
Attached file contains ruleset:
1. maximum view distance is 22 tiles
2. enemy regular units can see at night up to 19 tiles (and up to 22 if good lighting)
3. enemy terror units can see at night up to 22 tiles
Of course, you can set your own values, but anyway i need your opinion:
How changed behavior of aliens?
Is it works as expected?
-
Hello! Thanks for the excellent work of giving more options to Open X-Com players and modders!
One question: Which version of the "official" Open X-Com executable is the OXC Extended .exe based on? Is it based always on the last nightly build (I see that both versions are not being updated in synchronicity)
Some requests that I would like you to consider:
1) The possibility to add Accuracy, time units and arcingShot values to ammo clips, which when loaded in the weapon, will override the same values present in the weapon ruleset... Example: To mod a rifle with an underbarrel grenade launcher, it would be good to use the TU and Acc from the weapon if using it with its regular bullet ammo magazine, but when replacing that magazine and loading a grenade(s) clip, the weapon should "use" the TU and Acc from the grenade clip ruleset (which, may be it can have less accuracy, less range, but a high angle trajectory and more HE power than the bullet magazine).
2) Add a system of weapon types (similar to the excellent system added to craft in OpenXcom Extended) for armor suits... This way we can mod heavy infantry weapons that would be only possible to carry and fire when the soldier is using a specific armor suit type. An example: it's not possible for a regular soldier to hold and fire a minigun type machine gun, because of its eneormous recoil forces, but if the soldier is wearing a power suit, this suit can handle such a weapon.
Example: a) Add to armors a "weapon hardpoint" stat, this would have a numerical value...
b) This hardpoint value will be checked against a new "weapon type" stat, or even without needing to add any new stats, to the weapon weight value. If the weapon weight (or type)
value is lower or equal to the armor suit hardpoint value, this weapon is compatible, if the weight/type number of the weapon is higher, that weapon would not be able to be used by
troops wearing that armor suit.
I think such additions will give more flexibility and tactical options, and will not invalidate any current options available to the modders and gamers.
Thanks for your attention!
-
last version is based on Nightly from 2014-10-02, I don't updated because master branch only get some code used by TFTD. Overall when I create new build I sync with master branch.
1) Possible but will require lot of boilerplate code for handling all of properties. I will think about this.
2) Right now I consider adding fixed weapons to armors, this will give most of this functionality (armors with very big guns). It will have limitations too but it will require less coding because most of functionality is already in game.
-
Yankes: Thanks for taking your time for reading my suggestions. Do as you see fit...
Anyway, I think that the weapon slot is a more flexible approach to the theme of "armor specific weapons"... I hope you find sometime the way to implement that... am not in a hurry... I am very grateful with what you give the community with your work!
-
Example: a) Add to armors a "weapon hardpoint" stat, this would have a numerical value...
b) This hardpoint value will be checked against a new "weapon type" stat, or even without needing to add any new stats, to the weapon weight value. If the weapon weight (or type)
value is lower or equal to the armor suit hardpoint value, this weapon is compatible, if the weight/type number of the weapon is higher, that weapon would not be able to be used by
troops wearing that armor suit.
I think such additions will give more flexibility and tactical options, and will not invalidate any current options available to the modders and gamers.
I think it isn't really needed, you can do the same thing with current possibilities, it just requires some analysis and a lot of balancing (ex. add a non-fixed weapon, but make it extremely heavy, while at the same time giving the armor supposed to carry it similarly huge strength bonus/negative weight). Fixed weapons are mostly needed for 2x2 armor suits or other special-purpose ;)
-
Yes, but that approach leaves the way open for the player to load a lot of other different things in place of that weapon... I think that if it is no very complicated to code in, this would be a nice addition.
-
Hmm... this idea, after some refinement could be used to implement shields and other stat-changing items that won't be removable during the mission (as the possibility to make them removeable would require a ton of extra coding and would be very bug-friendly). So perhaps this could be it, but the "hardpoint" thing would have to be thought over; ex. defining it for every armor seems suboptimal. So I agree there is space where it could be implemented for the benefit of mankind, but how exactly and when, it's up to the creators of the Extended I guess :)
-
from irc:
[..] would it be hard to make a function "drop primed grenade on 'unload'-button to un-prime grenade for 50%? of primecosts" ?
[..]
<SupSuper>i dunno, technically it's easy to code, [..]
<SupSuper>maybe suggest it to openxcom extended
<FalkoO>ok
<SupSuper>at least dragging to unload is probably something you can't do accidentally
-
Extending the abilities for modding is always good, because you allow and provide
more options for creative work. I suspect that many of OXXT (OpenXcom eXTended)
innovations will be added to main OXC sooner or later. ;)
-
from irc:
[..] would it be hard to make a function "drop primed grenade on 'unload'-button to un-prime grenade for 50%? of primecosts" ?
[..]
<SupSuper>i dunno, technically it's easy to code, [..]
<SupSuper>maybe suggest it to openxcom extended
<FalkoO>ok
<SupSuper>at least dragging to unload is probably something you can't do accidentally
I will think about this. This probably will be easy to do.
Extending the abilities for modding is always good, because you allow and provide
more options for creative work. I suspect that many of OXXT (OpenXcom eXTended)
innovations will be added to main OXC sooner or later. ;)
Probably later ;P Its because my primary goal is create mod platform not obey original rules. I already made some changes that should no be in basic OXC.
Example of this is how I handle unconscious unit under explosion, In my version explosion must kill unit first before it can remove body.
-
Example of this is how I handle unconscious unit under explosion, In my version explosion must kill unit first before it can remove body.
That's the best thing I heard this week. :)
-
That's the best thing I heard this week. :)
That's actually there for a long time, which brings me back to my old request: Can you PLEASE give us a detailed readme along with the exe? Hoe EXACTLY do i set up the different parameters e.g. the damageboni, hoew EXACTLY does the entry in the rul look like? Do I need to add the word damagebonus BEFORE I add the other boni?
This exe is of NO use without documentation.
Example (copied from the Modportal):
damageBonus: #used by ammo nad psi-amp strength: 0.1 #default value 1.0 if `strengthApplied: true` psi: 0.0 #bonus equal `psiSkill*psiStrength` psiSkill: 0.5 psiStrength: 1.0
What is a costious unit btw?
Anyway
does the correct entry look like this:
-damageBonus: Strength: 0.5
or does it look like this
damagebonus:
Strength: 0.5
or does it look like
damagebonus: 0.5
Can I combine the boni?
PLEASE POST A README!
-
I remember that, simply I didn't do any new release yet to include it ;P In next version I will do it (that will be today or tomorrow).
You copied it wrong way, without line breaks and spaces its useless.
Proper rul should look like:
- type: STR_RIFLE_CLIP
size: 0.1
costBuy: 200
costSell: 150
weight: 3
bigSprite: 2
floorSprite: 2
hitSound: 22
hitAnimation: 0
power: 30
damageType: 1
damageAlter: #property added by mod
FixRadius: 5
SmokeThreshold: 6
ToEnergy: 1
ToTime: 0
ToHealth: 0
ToMorale: 1
damageBonus: #property added by mod
strength: 0.6
psi: 0.3
clipSize: 20
battleType: 2
Remember spaces and letter case matter.
damage bonuses from unit stats are additive, if you add more than one then it will add all values.
"What is a costious unit btw?" unconscious unit == stunned unit ("uncostius" text is typo).
-
New version is ready.
Damage can now affect TU (Flashbang :D), Energy, Morale (with bravery resistance) and can you can ignore default morale lose form dmg.
TU Throw and Prime cost in % for items.
Fixed weapons for armors.
-
Gee, wonderful! You guys rock! :) *happy*
-
I will think about this. This probably will be easy to do.
Probably later ;P Its because my primary goal is create mod platform not obey original rules. I already made some changes that should no be in basic OXC.
Example of this is how I handle unconscious unit under explosion, In my version explosion must kill unit first before it can remove body.
The reverse could be cool too. Explosions being able to cause body/equipment destruction on living soldiers.
-
The reverse could be cool too. Explosions being able to cause body/equipment destruction on living soldiers.
Definitely - it'd make "nuke"-type weapons more balanced and realistic (Blaster but also literal nukes), by destroying all the loot. Right now a Blaster can be used safely, since a single explosion, no matter how powerful, can only kill an unit and the damage doesn't carry over to the corpse/equipment.
-
Excellent idea, Dioxine! You are one creative person.
Some feedback after testing the exe:
You converted me. Now I no longer care about any official exes (and other exes) anymore, THIS is the way to go.
Dioxine and very other megamod-maker: Switch to this exe, it adds so many possibilities.
And best off all: you can just add one more ntiny rulset with all the Extended- changes and leave the rest of your mods unaltered, that's what I made in my personal mod combination.
One of the coolest (and easy to miss) changes is the ability to make a weapon wound enemies, I simply added those to the shotguns and similar weapons. Also great: You can add a morale damge bonus to e.g. Incendiary weapons, I'm burning, help meeeeee. ;D Ther zombie-proof armor you always wanted? here you go. Tired of your Enforcer-robots turning into Zombies after Chryssalid-attacks? Just use this exe and make their armour immune. Ever wanted a dual-wielding armor with integrated weapons? and and and.....
wow.
Really, I do not know what to say, this is just plain awesome. and everything works so far! Have to test the ALTSPRITE feature today, I added a prined graphic to my Naymore mod for that...
Anyway, a BIG thanks to Yankes and everyone else participating in this!
-
You converted me. Now I no longer care about any official exes (and other exes) anymore, THIS is the way to go.
Dioxine and very other megamod-maker: Switch to this exe, it adds so many possibilities.
Anyway, a BIG thanks to Yankes and everyone else participating in this!
I agree. But I owe something to those users who won't want to switch, so I'll maintain compatibility with basic OXCom up until a full "demo" version of my mod is done.
And indeed, praise to Yankes, redv (even though communicating with redv is harder than with aliens themselves, he's doing great work) and others :)
-
Thanks for that civilian :)
Definitely - it'd make "nuke"-type weapons more balanced and realistic (Blaster but also literal nukes), by destroying all the loot. Right now a Blaster can be used safely, since a single explosion, no matter how powerful, can only kill an unit and the damage doesn't carry over to the corpse/equipment.
I didnt do that only because I tried sneak in to master branch. Now I can revisit that code and alter it more.
Any suggestion how it should work exactly? One way of handling it is apply all over kill damage multiplied by "ToItem" to corpse and items. If damage is grater than durability of item then item is removed and corpse not spawn.
Another changes I plane to add is that fire & smoke affect stunned units.
-
Thanks for that civilian :)
I didnt do that only because I tried sneak in to master branch. Now I can revisit that code and alter it more.
Any suggestion how it should work exactly? One way of handling it is apply all over kill damage multiplied by "ToItem" to corpse and items. If damage is grater than durability of item then item is removed and corpse not spawn.
Another changes I plane to add is that fire & smoke affect stunned units.
Seems like a logical approach, and in-line with the spirit of the game. A little side idea - possibility to disintegrate the body with a severe overkill with a non-HE weapon? Say for non HE damage, (overkill damage-50) is applied to the corpse (but not their equipment).
Fire and smoke should DEFINITELY affect stunned units. The fact that it is not happening is counter-intuitive.
EDIT:
Could you guys perhaps look into repairing this whole hard-coded mess with corpse/live alien recovery? Like, un-chaining corpse/live specimen recovery from research topics so the game won't be no longer crashing if some artificial requirements are not met (like, if there is no STR_NEWALIEN_AUTOPSY topic, corpse recovery results in a crash and so on), or not catching aliens at all if their research isn't unlocked yet?
-
Just tested the ALTSPRITE features and the dual-wielding personal armor concept and both work fine! :)
This is so awesome! *happy*
And the craftweapon types work fine, too. I split my weapons into three teirs (eras) and it worked w/o the slightest problem, really good work!
One thing that surprised me (and scared the shit out of me) was the damage that the alien PSI attacks do by default. But it was as easy as adding tthree lines of code to my ruleset and the problem was corrected.
The default setting makes alien psi VERY deadly. No range limit, no ammo limit, NO defense possibility and worst of all: they do not need to see you (if you don't use the LOS option)... I swear that was one scary mission before I could go back to base and edit the rul file ;D
The scariest mission I played in several years actually.
Talking about features: After trying the REALVISION exe some weeks ago, would it make sense to add a VisibilityatDay entry as well? I am still not sure about this. The REALVISION exe was quite a performance hog on my PC... the game basically stopped each step a unit made so...
*Update: tested most, maybe all damagemodifiers and they work! I even managed to make a Stasis-Grenade, removing all the TUs from the hit unit, impressive work redv and Yankes.
-
Just tested the ALTSPRITE features and the dual-wielding personal armor concept and both work fine! :)
Do you happen to have graphics for unconscious units (no blood)?
On a separate note, I am thinking of a possibility to add random damage to the battlescape prior to the battle, especially on crash sites (much like the UFO Power Source explosion, but smaller and in random places, to represent falling debris). Would this be possible?
-
Sorry, no unit graphics, I tested the Primed Grenade feature with a custom icon.
Yankes, I found a bug, PM'ed you about it. Will be offline for some days, so i can not report for that time. :-\
Btw, is it possible to add one thing that I really miss when modding X-Com: An exclusion function for researches? e.g. If you research this weapon theme you will be unable to research another one, forcing you to make decisions e.g. should I go for Laser or Gauss or Heat-Ray this time? This would give the player a reason to play another campaign, testing all the weapons by themselves and not all at once...
And it would unclog the research selection screen... :)
CU soon-ish...
-
Obliterate!
https://www.youtube.com/watch?v=MnKh1nU4XZU
-
Obliterate!
https://www.youtube.com/watch?v=MnKh1nU4XZU
Wow. Intended for certain classes of weapons?
-
Right now it's only based on damage dealt to unit. Threshold now is half of max hp. If negative hp move past it, unit don't leave corpse behind.
-
So in theory, even mundane weapons might be able to obliterate something?
-
Yes if it done enough damage in final hit.
-
Uppps economy crisis. No body no money XD
Enviado desde mi LG-D802 mediante Tapatalk
-
Very nice! Does it use custom animation frames for each death as in a modder would have to add three extra death frames per unit sprite sheet or is it an engine effect?
-
Engine effect. You don't need add anything. Funny thing this is that I don't know why it behave that way :D I excepted it should made all colors turn black but it instead made all transparent. My overall goal was crate same effect but I didn't except it will work without creating special function doing this.
-
New version is ready.
Main change is overkill damage. Damage can now pass to negative values, if negative damage will be greater than half of max hp then unit evaporate and don't leave corpse or spawn new unit. Items can be destroyed then too.
This can be turn off in damage type by property "IgnoreOverKill", this is turn off by AP and MELEE damage.
-
Awesome! :) Downloaded it atm, my free weekend is ruined now ;D
edit: tested it the whole day and night and it works like a charm! That overkill feature is so cool. 8)
Oh and nice to see you found the grenade problem thingie and corrected it! ;)
Modder "tip": Regarding the ALTSPRITE function: After a while of testing several things I think that simply adding a tiny yellow X to the graphics works best for me, it is easily doable and visible. That and you do NOT need new graphics which makes things easier and safer in the battlefield. ;)
-
Just realized that the ability of fixed weapons in armor allows for armed civilians. Now they could wield pistols or combat knifes.... :)
*have to test this!*
edit: Doesn't work. :-[ It seems to be a original OpenXcom problem, though.
-
Just realized that the ability of fixed weapons in armor allows for armed civilians. Now they could wield pistols or combat knifes.... :)
*have to test this!*
edit: Doesn't work. :-[ It seems to be a original OpenXcom problem, though.
I recently walked close to that code, and I can confirm that civilians don't load any items. I could add this but there is bigger problem. Civilians don't have any AI to use weapons. This will probably require lot of work to fix it.
Meanwhile I added interaction of stunned unit with fire and no-explosive weapons. Additionally I fix spawning code of chryssalid, it can now spawn with plasma rifle and don't require special weapon type.
Exe will be ready when I finish small overhaul of psi-weapons, codename "Psionic Storm" :D
-
Hah! Just when I was about to report on the PSI-weapons. I discovered when you edit their additional damage to 0 (because you don`t want the physical damage they do) they also stop working as they should, you can not control/panic any units wit PSI anymore, you have to either have them damage the enemy when you try to panic/control those, or you have a non-working PSI...
I even tried 0.00001 as a damage but that didn`t work either. Same for the alien side. I wondered why none of my troops got ever panicked or controlled through the whole game until I was able to use PSI attacks myself. ;D
A soldier with 100 PSI strength and 84 PSI skill couldn't do anything even when standing right next to the alien.
-
i have simple idea:
- additional stat for weapon that would modify power damage from its ammo from range 0 to N%
sample of usage:
- aliens have 3 weapons pistol, rifle and heavy
- aliens have single clip that match all weapons
- aliens have stronger clip that has better power similar to poison A B C from apocalypse. Each clip has different ammo but there are also 3 different weapons. Normally this would require 9 ammo clips which is somehow redundant
Tom
-
Hah! Just when I was about to report on the PSI-weapons. I discovered when you edit their additional damage to 0 (because you don`t want the physical damage they do) they also stop working as they should, you can not control/panic any units wit PSI anymore, you have to either have them damage the enemy when you try to panic/control those, or you have a non-working PSI...
I even tried 0.00001 as a damage but that didn`t work either. Same for the alien side. I wondered why none of my troops got ever panicked or controlled through the whole game until I was able to use PSI attacks myself. ;D
A soldier with 100 PSI strength and 84 PSI skill couldn't do anything even when standing right next to the alien.
psi weapon don't do damage form power, it's should treat this as bonus to "MC" chance, at least I tried do it in that way. Right now I'm busy and can't check out this now. Probably in next week I will be able find some time to fix it.
-
Ah sorry for my somewhat unclear description: What I mean is: you gave the PSI-weapons a 0.02 damage by default. I wanted to get rid of that so I set the number to 0.0. That`s when they stopped to work.
I did not add an additional bonus, I mereley changed the default (invisible, hard-coded one) to zero.
And yes, take your time, I`m more than happy with the current version. 8)
-
Does OXC Extended support "dual wielding" tanks?
-
Does OXC Extended support "dual wielding" tanks?
two fixed weapon on one tank? It should work.
-
New version is ready.
Updated to recent warboy changes.
I fixed bug with psi amp that deal damage to unit, in long run it will be feature but right now is bug (you still do this if you change psiamp damage type).
Stunned unit can be kill by normal weapon if you hit place where its lay. Fire affect them too.
You can change default alien psi weapon per armor or race (its share slot with melee weapon).
-
Nice changes! I really gotta get around to using your version (but I've had enough issues compiling nightlies, I'm not ready yet for something else...).
Do you think it would be possible to code things such that the alien psi-weapon can be given in the itemlevels?
That would allow mods where the psi-powers vary with time, even within a given race. I want to make a mod where aliens get a few psi-weapons:
- one that requires LoS, so it not a major factor for beginning players fighting sectoids
- one that doesn't, but has a large TU cost for mid game. You can be attacked anywhere/anytime BUT it won't be 10 times a turn.
- one that doesn't require LoS and has a really low TU cost, making psi-powers a real threat (or at least mitigating the waste of TUs it is for aliens when they try to use psi-powers against hand-picked, psi-hardened XCom operatives)
-
Dumb question.
Does the extended exe work as a "launcher" for vanilla exe, or is it "its own exe", replacing vanilla exe (do I need to rename it "openxcom.exe" after deleting vanilla exe?)?
-
@Arthanor right now is build in alien unit, it can't be easy altered by itemlevels. One way to easy fix that is give aliens normal psiamp as weapon and allow alien AI to use it.
@robin this is separate exe with different name, after installing it you can chose which exe to run. Both exe can live together fine.
-
That would be cool. I wish someone could do that :D
-
New shining things:
Armor can have build in regeneration.
You can custom load and unload cost (+ you need pay cost of moving items around inventory).
You can unprime grenade using unload button (I leave requirement for 2 empty hands as feature).
My next goal will be continuation of altering psi weapons.
-
I have a request.
Custom medkit weapons, that is to say I want an item type that allows me to define a ranged weapon with a med kit stim option and be able to give it a melee damage
I want to make "detention equipment" Which is like three items in one with the goal of stunning/ capturing someone. Which would actually be a combination of a few items shown in a 2x3 item area.
-A taser for doing stun damage up to four squares away
-A Syringe for dosing an operative full of Thorazine
-Duct-Tape\zip ties\ blindfold...for flavor :)
-A truncheon for beating them unconscious
How many times have you been like "OK, I really don't want to kill you, but I need you NOT to be taken over by aliens." Thus I want to be able to taze, inject, beat senseless, hog tie and blindfold troublesome operatives.
**edit** new idea came to me about 15 minutes after I posted... no need for a new post!**
I would like a "We can now buy" screen to pop-up if I complete a research project if I can buy something my scientists or engineers didn't think to purchase before.
A few examples...
I would like to be able to research let's say "alien circuitry" from the Xops mod and learn about cool alien circuit designs that I can't replicate, but still gained insight into how the aliens do things and make some breakthroughs. What if I could make inferior knock-offs to use in human equipment and told telecommunications company that they could have the tech if when they fabricate it I can buy it from them?
or
What if my guys discover that the alien abduction equipment is really good for DNA analysis and creating custom drugs for a person almost instantly? I call Merck and they give me bad ass combat drugs with a smile for cluing them in.
or
My scientists discover a way to make Elerium go further by refining it with nuclear waste. I suddenly need to buy nuclear waste and use it to refine Elerium... cuz my engineers said so.
thoughts?
-
Yankes
Please consider following new features:
1) feature (global variable) to penalty players to use two hand weapons and still use grenandes etc ? This is quite simple to implement.
https://openxcom.org/forum/index.php?topic=3174.0
If move item FROM / TO hand and second hand is taken and item is two handed, then double or triple cost to move this item TO or FROM second free hand. This double or triple would be modifier. Default value would be 1.0.
This should be simple to implement but this could broke balance of one - two hands weapons.
2) feature for terrains / biomes that changes its "texture" and "battlescapeID" based on time of year.
https://openxcom.org/forum/index.php?topic=3160.0
What we need is a new field for terrain. Normally there is "terrainID" for terrain. Lets add an array with 12 items that would simulate change of terrain per months. And when EndMonth trigger is run then change terrain behavior based on this array.
terrainID = 3
terrainMatrix = [3,3,3,3,3,3,5,5,5,5,5,5]
So this terrain is "3" in Jan-Jun but is 5 in Jul-Dec. This works both for visual effect and battlescape. Default value would be same as standard terrainID for all months.
This should be tricky to implement i think.
3) feature about obsolete technology which works exactly opposite to required. Below is pseudo code:
https://openxcom.org/forum/index.php?topic=3155.0
item / craft / ufopedia etc is available when:
obsolete tech is not owned
required tech is owned
rest is same as in vanilla
This could be simple to do but without modders adding new feature this is useless.
4) Race specific alien base with its own tilesets defined in race section. I mean you defined only mission or terrain for this race, nothing more. So we can add new alien race like Man in Black to have its own alien base but still standard alien base must be used during battle.
https://openxcom.org/forum/index.php?topic=3162.0
This should be simple to implement but creating new alien race with tileset might be very complex making this feature almost useless without new graphics.
5) option to display before battle REGION and COUNTRY that will be used to score points against based on location on geoscape. In case of no country exist then it will be neutral territory. Also information about current funding or score results for this country would be nice to know if this battle is more or less important.
This should be simple.
6) Add feature to ufo ships to use custom icon on geoscape. Actually all alien ships use same sprite now which is a small red dot. But instead of this custom one could be used with default value of what is no. This sprite would be very small like 3x3 or 5x5 but would help to differentiate small / medium / large UFO on screen if geoscape sprite file is edited.
This should be simple to implement.
7) add new parameter to Terrain or Mission that would allow to simulate "scorched earth" tactics by aliens. This would be implemented by changing parameter from 0 (default) to N number of explosion randomly on battlescape after battlescape is generated and before it is played. There would be 50% for human grenade, 25% for smoke one, 25% for fire grenade explosion. This function could be modified by alien race modification defined on alienRace: level from 25% to 250% with default 100% .
Should be simple to add but could broke a balance a bit.
8 ) add feature that urban objects contains score value just like alien tiles contains alien alloy that could be gathered by x-com after battle is completed. This score would be deducted from mission if lot of human made structures are destroyed during battle if battle is inside country area. Single tile made by human should be counted for -0.1 of score and maybe few tiles like doors / shop selves for -1 score etc. This feature could be used in future to create a missions that actually aliens want to destroy tiles that have a lot of score when destroyed just like they want to hunt civilians. It is already implement to let aliens destroy part of human base during base assault.
This is a lot of work to update tiles, but would be nice to have this to actually save humanity from aliens not just pull down every wall with blaster bomb.
9) add parameter to define percentage chance to execute single ufo trajectory waypoint. Default value is 100% and if below 100% then roll a dice and if above threshold then move to next waypoint.
10) this is cool one :) some mods has very complex research tree. If player does not know what to research then add button to have a "brainstorm with scientist". This would be a special project with a cost of 100 points of no score that would display a popup window what is required to unlock new technology. Just go through the technology tree and choose randomly single technology and display its requirements which have not been researched yet. Still player would need to gather those requirements but at least it would be more obvious what to find. This could be used to add "tutorial" into the game.
PS: I can help you with the code, i am already familiar with oxc structure.
Tom
-
I have a request.
Custom medkit weapons, that is to say I want an item type that allows me to define a ranged weapon with a med kit stim option and be able to give it a melee damage
I want to make "detention equipment" Which is like three items in one with the goal of stunning/ capturing someone. Which would actually be a combination of a few items shown in a 2x3 item area.
-A taser for doing stun damage up to four squares away
-A Syringe for dosing an operative full of Thorazine
-Duct-Tape\zip ties\ blindfold...for flavor :)
-A truncheon for beating them unconscious
How many times have you been like "OK, I really don't want to kill you, but I need you NOT to be taken over by aliens." Thus I want to be able to taze, inject, beat senseless, hog tie and blindfold troublesome operatives.
**edit** new idea came to me about 15 minutes after I posted... no need for a new post!**
I would like a "We can now buy" screen to pop-up if I complete a research project if I can buy something my scientists or engineers didn't think to purchase before.
A few examples...
I would like to be able to research let's say "alien circuitry" from the Xops mod and learn about cool alien circuit designs that I can't replicate, but still gained insight into how the aliens do things and make some breakthroughs. What if I could make inferior knock-offs to use in human equipment and told telecommunications company that they could have the tech if when they fabricate it I can buy it from them?
or
What if my guys discover that the alien abduction equipment is really good for DNA analysis and creating custom drugs for a person almost instantly? I call Merck and they give me bad ass combat drugs with a smile for cluing them in.
or
My scientists discover a way to make Elerium go further by refining it with nuclear waste. I suddenly need to buy nuclear waste and use it to refine Elerium... cuz my engineers said so.
thoughts?
I don't think that mixing item types is good idea, most of this features you request are possible as separate weapons.
Weapon damage can affect "hp", "tu", "energy" and "morale" in positive or negative way. You could create pistol that will kickup stunned unit form ground simply shooting place where unit lie.
Its probably too much code change for so small functionality.
To next thing, I would prefer don't touch UI at all. To do it properly it would require adding new language strings.
This will cause multiple problems I would prefer avoid. But functionality you require is already implemented (except of UI part).
Availability of items in buy windows can depend on research state.
Yankes
Please consider following new features:
1) feature (global variable) to penalty players to use two hand weapons and still use grenandes etc ? This is quite simple to implement.
https://openxcom.org/forum/index.php?topic=3174.0
If move item FROM / TO hand and second hand is taken and item is two handed, then double or triple cost to move this item TO or FROM second free hand. This double or triple would be modifier. Default value would be 1.0.
This should be simple to implement but this could broke balance of one - two hands weapons.
2) feature for terrains / biomes that changes its "texture" and "battlescapeID" based on time of year.
https://openxcom.org/forum/index.php?topic=3160.0
What we need is a new field for terrain. Normally there is "terrainID" for terrain. Lets add an array with 12 items that would simulate change of terrain per months. And when EndMonth trigger is run then change terrain behavior based on this array.
terrainID = 3
terrainMatrix = [3,3,3,3,3,3,5,5,5,5,5,5]
So this terrain is "3" in Jan-Jun but is 5 in Jul-Dec. This works both for visual effect and battlescape. Default value would be same as standard terrainID for all months.
This should be tricky to implement i think.
3) feature about obsolete technology which works exactly opposite to required. Below is pseudo code:
https://openxcom.org/forum/index.php?topic=3155.0
item / craft / ufopedia etc is available when:
obsolete tech is not owned
required tech is owned
rest is same as in vanilla
This could be simple to do but without modders adding new feature this is useless.
4) Race specific alien base with its own tilesets defined in race section. I mean you defined only mission or terrain for this race, nothing more. So we can add new alien race like Man in Black to have its own alien base but still standard alien base must be used during battle.
https://openxcom.org/forum/index.php?topic=3162.0
This should be simple to implement but creating new alien race with tileset might be very complex making this feature almost useless without new graphics.
5) option to display before battle REGION and COUNTRY that will be used to score points against based on location on geoscape. In case of no country exist then it will be neutral territory. Also information about current funding or score results for this country would be nice to know if this battle is more or less important.
This should be simple.
6) Add feature to ufo ships to use custom icon on geoscape. Actually all alien ships use same sprite now which is a small red dot. But instead of this custom one could be used with default value of what is no. This sprite would be very small like 3x3 or 5x5 but would help to differentiate small / medium / large UFO on screen if geoscape sprite file is edited.
This should be simple to implement.
7) add new parameter to Terrain or Mission that would allow to simulate "scorched earth" tactics by aliens. This would be implemented by changing parameter from 0 (default) to N number of explosion randomly on battlescape after battlescape is generated and before it is played. There would be 50% for human grenade, 25% for smoke one, 25% for fire grenade explosion. This function could be modified by alien race modification defined on alienRace: level from 25% to 250% with default 100% .
Should be simple to add but could broke a balance a bit.
8 ) add feature that urban objects contains score value just like alien tiles contains alien alloy that could be gathered by x-com after battle is completed. This score would be deducted from mission if lot of human made structures are destroyed during battle if battle is inside country area. Single tile made by human should be counted for -0.1 of score and maybe few tiles like doors / shop selves for -1 score etc. This feature could be used in future to create a missions that actually aliens want to destroy tiles that have a lot of score when destroyed just like they want to hunt civilians. It is already implement to let aliens destroy part of human base during base assault.
This is a lot of work to update tiles, but would be nice to have this to actually save humanity from aliens not just pull down every wall with blaster bomb.
9) add parameter to define percentage chance to execute single ufo trajectory waypoint. Default value is 100% and if below 100% then roll a dice and if above threshold then move to next waypoint.
10) this is cool one :) some mods has very complex research tree. If player does not know what to research then add button to have a "brainstorm with scientist". This would be a special project with a cost of 100 points of no score that would display a popup window what is required to unlock new technology. Just go through the technology tree and choose randomly single technology and display its requirements which have not been researched yet. Still player would need to gather those requirements but at least it would be more obvious what to find. This could be used to add "tutorial" into the game.
PS: I can help you with the code, i am already familiar with oxc structure.
Tom
1) I think it could complicate too much inventory management, but if you could create clean implementation of this I can merge it to my branch (it could be defined per weapon, because some weapons could be harder to handle).
2) Interesting idea, but I have problem with transition form one state to another. I have some possible solutions for this but all will be probably very complex.
3) Can be done.
4) I didn't touch that code region jet.
5) I prefer avoid UI stuff.
6) Interesting idea, It could be simply implemented by two YAML arrays of pixel colors. I think it could be expand to human crafts too.
7) & 8 ) Can be done, but I would prefer focusing on something different.
9) Can be done.
10) Again its require change in UI.
-
To next thing, I would prefer don't touch UI at all. To do it properly it would require adding new language strings.
This will cause multiple problems I would prefer avoid. But functionality you require is already implemented (except of UI part).
Availability of items in buy windows can depend on research state.
Please provide a working example so I may replicate it.
-HH
-
Armor can have build in regeneration.
Alien armors too?
-
Please provide a working example so I may replicate it.
-HH
from first post:
items:
- type: STR_PISTOL
requiresBuy: #what tech is requare for item be visible in buy window.
- STR_PSI_AMP
You can buy basic pistol only if you research psi amp.
Alien armors too?
armors data are share between solder and aliens, if it possible for humans it is possible for aliens (in 99% cases).
-
Thanks... My weekend is shot thanks to you... ;D
-
1) is it possible to set required technology to USE item in battlescape and to BUILD item by engineers as two separate technologies ?
if not can we add this ?
2) Does aliens consider effective chance to hit when using different accuracy modifiers like aimRange, snapRange etc ? I found that aliens try to shoot using shotgun outside max range and using sniper rifle inside min range. In both cases this cripples alien tactics a lot.
Would be nice to add simple check what should be current accuracy and theoretical accuracy in few closest nodes. In case accuracy is low try to move to another node first before fire. This would work both for min and max Range. This would be cheating for aliens but would simulate proper usage of weapons based on their range. This could be turn on / off as option just like SneakyAI.
3) what about option to auto buy items if they are not available to refuel / reload crafts ? It is still pain in the arse to go to base to buy single stingray missile because it lacks. This would require flag to item autoBuy and if player has money and there is enough store in the base then instead of display window "not enough" then just buy it.
4) would be nice to have feature to CREATE ITEM on the field where bullet hits terrain. Item would be created AFTER explosion if any exist. I can imagine a flare launcher for example but there are more examples. This is already implemented in create map block so shouldn't be problem.
5) would be nice to have feature to CREATE ITEM on field that unit have left during movement. This is already implemented for one alien terror unit but i think is not configurable for other units.
6) feature based on global variable with default value of 0, that simulates Half-life time of Elerium-115. Every start of month player is loosing N% of its elerium-115 cargo just like decay of radioactive isotopes. So value of 0.1 would mean loss of 10%. Script could be very simple, just add in newMonth trigger check of alien fuel item and deduct N% from it. With default value of 0 this will not harm standard game.
7) acceleration based dogfights. Once again global parameters that control this aspect of the game. It defines percentage change of default speed based on difference of acceleration between UFO and x-com craft. Default value is 0.0.
Avenger with acceleration of 10 is fighting battleship with acceleration of 5. Default speed of UFO during dogfight is 4 / -2. In case of our parameter is set to 0.05 then we have 1.25 * 4 and 0.75 * -2 in the game.
-
1) Yes, it's in basic OXC
2) This probably should be fix in basic OXC
3) This will require UI changes, and this is more as gameplay improvements than mod (This could be sneak in to basic OXC).
4) & 5) And item will do what? This will require additional changes too to have any interesting gameplay effect.
6) This should be more per item type, corpses and aliens could "decay" too. But I don't think that will be so easy to implements. Do you remember monthly payment exploit in original ufo?
-
3) An auto-resupply would promote lazy management. Also, the game can't really delay the rearming : When the missing clip arrives 2 days later, how can the game put it in the right pocket of the right soldier in the right craft ?
-
3) An auto-resupply would promote lazy management. Also, the game can't really delay the rearming : When the missing clip arrives 2 days later, how can the game put it in the right pocket of the right soldier in the right craft ?
I don't know.... maybe biscuit making? no no no that's not right.... Programming! that's the word!
:)
-
I mean, how do you handle the conflict when the ship is transferred in a different base, the soldier is assigned to a different ship, or already re-equipped differently ?
-
i just proposed a solution to a common problem
i am not saying its simple to implement or if it does cause more problems then it solves :)
For example i just make a test how acceleration impact dogfight and it works great from tactics point of view but on the other hand completely change airbone warfare and force to create new balance for both x-com crafts and alien ufos.
-
i wrote custom images support for ufos for land / fly / crash states. What do you think about those images ? Can someone interested made better version with assumption that each sprite should not be larger then 5x5 for example ?
Thanks
-
Can I assign a custom icon based upon mission type/ufo type?
For example. In my MiB mod there's a custom mission type called "STR_MIB_BASE" (which employs a custom ufo type "STR_MIB_BASE_LANDING"). Can I assign a custom icon to one of them, so that, on the geoscape, this mission are visually differentiated from the regular ufo ground site?
(The ability to differentiate visually -thus making them immediately recognizable- custom missions form regular ufo ground/crash sites, would be quite useful I'd say).
-
Can I assign a custom icon based upon mission type/ufo type?
For example. In my MiB mod there's a custom mission type called "STR_MIB_BASE" (which employs a custom ufo type "STR_MIB_BASE_LANDING"). Can I assign a custom icon to one of them, so that, on the geoscape, this mission are visually differentiated from the regular ufo ground site?
(The ability to differentiate visually -thus making them immediately recognizable- custom missions form regular ufo ground/crash sites, would be quite useful I'd say).
So far no, i just implemented my idea from previous post, which is custom ID for UFO crashed / landed / flying and for x-com crafts
But this is very nice idea to have mission types shown on screen if they are known.
Problem is not technical one but graphical one. I think we do not want to have 10x10 sprites as game is designed for 320x200. Can you design all those graphics in 5x5 area ? If yes, i will do it.
-
Another simple idea regarding base defense:
1) Let defenses facilities have number of shots per wave with default value of 1. Each is calculated separately but can be weaker then original. Grav shield works as usual. Main reason is to differentiate different buildings as standard ones are very similar to each other. Expected value of damage would be the same. Now buildings differs mainly by sound as they are not even shown on base defense screen.
2) Would be nice to have information about damage done to alien ship in percentage, not just info about hit / miss.
3) When mission starts and UFO is damaged then kill proportional number of aliens based on damage. 10% of destroyed hull would mean 10% of killed alien units during battlescape. They can be just killed after mission is generated with bodies exist on the battlescape. This could be configurable by a flag / option "Lethal base defenses" as a bool.
4) Set delay between weapons are fired per facility as for now this delay is hardcoded to be 250 or 333 ms.
5) Let facilities consume ammo if defined. If no ammo is available in stores then add message "No ammo". Default value would be no ammo is required.
2a) If percentage information about UFO is impossible then at least create a more advanced UFO status that could be displayed in future on other screens. Now its just DESTROYED / CRUSHED / LANDED / FLYING.
100-90% no damage (at least we know that UFO is tough)
70-90% light damage (at least we know we done some damage to UFO)
50-70% medium damage (at least we know that it is closed to shot down UFO)
below 50% -> normally is crushed but here would be heavily damaged until destroyed
I know this base defense is very very very small part of the game but on the other hand all those customizations are very simple to implement in single file.
Other thing is would be nice to have a flag for an item that says "IS DESIGNED TO BE THROWN". This would reduce range or / and arc of thrown items that are not designed to do it by some percentage. By default all items are designed to be thrown so no modifier is applied. For example grenade has weight of 3 and high explosive of 8, but the second one never was designed to be thrown, which means for purpose of throwing we should treat its weight not as 8 but as 12 for example.
-
i wrote custom images support for ufos for land / fly / crash states. What do you think about those images ? Can someone interested made better version with assumption that each sprite should not be larger then 5x5 for example ?
Thanks
I can draw you some. I think you should go larger than 5x5 though. Anything smaller than 9x9 is difficult to see in the higher resolutions, and the originals are already 3x3 so might as well make a worthwhile change.
-
(https://i.imgur.com/uxHYXbm.png)
Here I have the 9 geoscape icons I could think of rendered in 9x9 resolution. I made three versions:
1.) standard high-resolution
2.) classic low-resolution (built for high resolution setting)
3.) stylized (courtesy of my mediocre art skills)
-
nice, but idea was to create different icon per x-com craft and alien UFO including different images for crashed / landed and flying states :) Using just different icons is possible even without this customization in vanilla game.
-
I thin is better to stick to small graphic 3x3 or max 5x5. Another thing is to use different shapes not size to represent different crafts.
Something like that:
>small scout (3x3)
#
>medium scout (3x3)
#
# #
>large scout (3x3)
#
# #
#
>somthing diffrent (3x3)
###
# #
#
>biggest alien craft (5x5)
# # #
# #
#
-
nice, but idea was to create different icon per x-com craft and alien UFO including different images for crashed / landed and flying states :) Using just different icons is possible even without this customization in vanilla game.
Ah, I guess I misunderstood.
Howabout this:
(https://i.imgur.com/n3Laa8j.png)
I made most of them 5x5, but a few are different:
small scout: 3x3
medium scout: 4x4
supply ship/terror ship: 7x5
battleship: 7x7
I think you can tell which is which. I made inverted crash sites because those look more like the familiar X and also like something destroyed, but then I made non-inverted versions for better recognition so you can use whichever you like better.
-
actually if craft / ufo is not 3x3 or 5x5 then it will be drawn not in the middle of sprite, this will look strange when combine with line that shows craft path.
-
Well it's a bit difficult to make convincing icons that small. Here's some icons to represent the five UFO sizes (along with the X-Com craft from last time):
(https://i.imgur.com/HGctHBB.png)
This leaves the very small at 1x1 but if you can add transparency, you can make it a 3x3. Or if you leave it 1x1 it should still display approximately correctly.
-
Another simple idea regarding base defense:
100-90% no damage (at least we know that UFO is tough)
70-90% light damage (at least we know we done some damage to UFO)
50-70% medium damage (at least we know that it is closed to shot down UFO)
below 50% -> normally is crushed but here would be heavily damaged until destroyed
I know this base defense is very very very small part of the game but on the other hand all those customizations are very simple to implement in single file.
I think this is a nice idea. I'd go a step further and make it so that partially damaged UFOs drop fewer alive troops into your base. Or perhaps some of the times you get attacked, they use a smaller ship. Without any update like this, base defense facilities are useless until you have enough to shoot down a ship, which means that missile and laser defense are pretty much useless altogether.
Perhaps your base should get attacked much earlier in the game and more frequently, by small craft. With a missile defense or two, you could knock the smallest ones out of the sky and focus only on those that matter.
-
another small thing
unit aggression level current options:
0 = mostly passive
1 = balanced
2 = mostly aggresive
what about adding this:
-1 = total passive, does not move at all
0 = mostly passive
1 = balanced
2 = mostly aggresive
3 = total aggressive, always try to move to enemy at all cost and energy
This would be nice to have for static x-com tower defense units or suicide / berserk alien units.
-
you can already do that. those are just the vanilla values.
-
sorry Warboy1982 i think i need to check sources first before posting :)
on the other side, even when i am tech person i do not want to know how the sausage is made not kill all the fun from playing the game :)
-
hah!
-
is it possible to merge extended version into vanilla with additional flag that turns features on / off just like other advanced features (not mods) like UFO extender ?
and why not ?
-
It will be hard, I change many thing to made my stuff work, and another thing is that Warboy didn't like to maintain code that go in opposite direction that goal of OXC.
This separation is positive because I could go further than basic codebase would allow. Another thing is if I f*** up and destabilize code then only my mod would be abandon. If it was master branch then that could kill whole project, because every one depend on that its work properly.
-
wow, that's a really good rationale.
-
Thanks for detailed explanation about extended version.
I wonder can we then create "external version" that main goal would be NOT adding more functionality to the source code but move hardcoded stuff to the ruleset so moders could change it. This would be then integrated to vanilla version without break down compatibility. This also would need to have fresh documentation updated on regular bases in the wiki.
Try to rename STR_BATTLESHIP to something and it will break game on retaliation mission for example. Instead of this other ship could be used or even a list of ships to pick one randomly. Battleship is very strong and have big crew. Imagine terror ship that is easy to destroy but has very large crew during attack. This small change would actually bring value to the game to use low tier defense facilities once again.
Tom
-
Now back to extended version.... feel free to implement it or. I just post ideas that might have nice value to moders.
In "UFO Trajectories" there are waypoints defined as [zone, altitude, speed]
Altitude means:
0 - Ground
1 - Very Low
2 - Low
3 - High
4 - Very High
Would be nice to have also
-1 - Force crash of UFO just like it was shot down, as this might be useful. Something similar was implemented in Ufo Extender i think... force some Scouts to crash randomly.
5 - leave Earth orbit and ends this mission without score for alien. I mean not just this UFO but all future UFOs from this mission.
Would be nice to have also one more parameter [zone, altitude, speed, chanceToSkip] with default value of 0. For example harvest mission could land once, twice or never. That would enhance player experience even in vanilla game.
-
New version uploaded.
3 changes:
Option for Ufo2000 damage type (you can damage armor even with weak shoots).
Bonus to Accuracy/Damage/Melee hit chance be based on most of unit basic stats.
Psi-amp can now cause direct damage, you can crate fireball, pyrokinetic or psistorm attack (Alien could do it too).
-
Psi-Amp MK2 ready :)
New update (one drawback its based on 10-01-2015 nightly, in next week I will update it to recent version)
All items can now consume unit energy when used, all attacks type have separate property similar to TU cost.
MC and Panic and special psi attack can have different cost (in TU and Energy). You can change basic bonus to psi attack per type.
Throw can have accuracy, and now require healthy hand to throw.
Is possible to turn of MC or Panic attack form Psi-amp.
All items can have (or not) psi skill requirement.
-
Psi-Amp MK2 ready :)
New update (one drawback its based on 10-01-2015 nightly, in next week I will update it to recent version)
All items can now consume unit energy when used, all attacks type have separate property similar to TU cost.
MC and Panic and special psi attack can have different cost (in TU and Energy). You can change basic bonus to psi attack per type.
Throw can have accuracy, and now require healthy hand to throw.
Is possible to turn of MC or Panic attack form Psi-amp.
All items can have (or not) psi skill requirement.
I just tried it and seems to be crashing when psi is used either by aliens or by xcom. This is with last version. You can test it using base defense mode battle.
-
Ok I find some bugs, I will fix them.
[ps]
I find only bug with doors, psi attacks work fine, what version of OXC did you use for base? Remember that I did not yet update it to latest nightly.
Do you add some custom ruleset that could break my mod?
-
Is possible I may have upgraded over the latest nightly then to extended :/
lemme try again
-
Extended version is up to date with nightly now (2015-02-15).
btw tollworkout, do you have still this bug?
-
is working fine NO more problems. i tried all types of default psionics i tied mind controling debug base defense terror missions with mods etc . works fine. :D
-
good :)
-
Another update
Version based on 2015-02-22 nightly.
Armor can change overkill damage threshold.
Stats bonus can calculate polynomial from values. This will allow for no linear relation between bonus and basic stat value.
Right now supported is square and cube of value.
Stats bonus can access curret hp, energy, tu and morale.
Tou can add penalty for low morale to accuracy.
-
yankes can you upload you binary to the forum seems mods is down for time being. I wanted to test out this ruleset i was thinking of building based on your changes.
-
https://www.mediafire.com/download/c66j0nop2sm7gx8/OpenXcomEx.zip
-
thank you sir
-
Small update with recent SupSuper changes to regions.
[PS]
My next goal will be requirements for research and production based on available buildings in base.
This will allow for research to require special building like "physic laboratories" present in base to start research plasma weapons.
-
yankes you should make a custom training facility that turns item X into item Y for ex can turn soldiers into mecs or can turn soldiers into better soldiers or turns live aliens into soldiers etc.
-
This is bit out of scope of my extended version, I try focus on altering original game functionality and de-hardcoding properties.
I add new functionality only if its very local and don't require changes in may places.
That you propose would require merging handling of items and solders (if I want reuse manufacture code).
Another thing is UI, I prefer don't change or add new because its will require new text with translations and I try avoid this parts.
-
This is bit out of scope of my extended version, I try focus on altering original game functionality and de-hardcoding properties.
I add new functionality only if its very local and don't require changes in may places.
That you propose would require merging handling of items and solders (if I want reuse manufacture code).
Another thing is UI, I prefer don't change or add new because its will require new text with translations and I try avoid this parts.
okay :)
-
Hy Yankes!
Whit OXE I can finally trash my own armors during battle tanks to your damageAlter property.
I love your work! :D
I'm reading the pedia at https://www.ufopaedia.org/index.php?title=OBDATA.DAT#Grenades (https://www.ufopaedia.org/index.php?title=OBDATA.DAT#Grenades)
(setting a pre-primed bomb under the UFO Power Source), but I was unable to replicate this
behaviour. There is a way to set some kind of timed auto-destruction in battlescape?
If not, may you be interested in adding one to OXE?
I also have a second request (I'm a greedy person :P)
Can be possible for a weapon to inflict random damage to the user?
What I have in mind is a possibility for psi-amp of doing 1 or 2 hp damage to my own soldier,
but this can also be used for a 1/1000 chance for a weapons to explode OR for an object to
inflict negative damage (healing) the user.
(healthUse, similar to the energyUse property you add to items ruleset)
well, my 2 cents anyway.
Thanks for your time and work!
-
I'm reading the pedia at https://www.ufopaedia.org/index.php?title=OBDATA.DAT#Grenades (https://www.ufopaedia.org/index.php?title=OBDATA.DAT#Grenades)
(setting a pre-primed bomb under the UFO Power Source), but I was unable to replicate this
behaviour. There is a way to set some kind of timed auto-destruction in battlescape?
If not, may you be interested in adding one to OXE?
You read wrong ufopaedia article :> Hack form UFO don't work in OpenXcom, its have its own set of hacks :)
And about implementation, its depend on required functionality (how exactly it should behave), if is only one "if" change in code then I will do it.
If it require lot of changes I will probably pass. Right now I will give it 70% chance to be implement.
I also have a second request (I'm a greedy person :P)
Can be possible for a weapon to inflict random damage to the user?
What I have in mind is a possibility for psi-amp of doing 1 or 2 hp damage to my own soldier,
but this can also be used for a 1/1000 chance for a weapons to explode OR for an object to
inflict negative damage (healing) the user.
(healthUse, similar to the energyUse property you add to items ruleset)
Only thing that prevent me form doing it is error message when you don't have enough hp to use item.
To do it properly I should add string in all languages that are supported by OpenXcom. This is a lot of work that I prefer avoid.
Only way I see doing it is throw all responsibility onto modders to provide require texts if they use it, but this is lazy solution.
Aside of that, I except that in some day I will do this when I add `energyUse`. Most of code was refactored to support `healthUse` and `moraleUse`,
but because previous problem I didn't move that far.
If I did add this, cost would be flat cost. It would work exactly like current `energyUse`. Every use would reduce your `hp` by some value like `3` or `42` with no random.
-
tank you for the quick response!
What I tried to do is add a custom alien grenade in terrains.rul (elerium in UBASE is added
this way), on top of the elerium, and then messing around whit the item properties: battleType: 2 (Ammo), clipSize: 25 (turns left), meleePower: 25 (also turns left) as described on the Pedia.
I was thinking that the rulesets was used the same way as OBDATA.DAT is used on original game.
My fault :-[
In short, what I ask you (if you are willing to do it) is to add a way to insert a pre-primed bomb
in the battlescape. Then modders can place this item via terrains.rul.
Citing the Pedia for possible usage:
One practical application of this is to create exploding elerium pods that will explode after a pre-set number of turns
Set the damage to strength to something insignificant like 1 to let them wink out of existence (for data disk autodestruction after x turns).
Regarding second request: flat cost would be a great improvement already ;)
If you are just worried about localized messages, why don't use some dull pre-made string
like STR_DISABLED: "Disabled"?
-
If this "grenade" is one time use and you can't bring it to fight then I could do it.
I need first check how best is to handle this. I would prefer avoid situations when its spawn in base defense mission (because you get some) and start exploding obliterating your facilities. Another thing is if we allow aliens equip this too?
Overall I will think about this but meanwhile I need do some different work like updating my branch to official one. This will take some work, because Warboy change lot of code that I change in my branch too.
And for messages, this fall in lazy category too ;P
-
The ability to spawn a primed grenade (or other explosive) could be cool.
The previously mentioned exploding power sources could turn the game into a rush to eliminate aliens on a craft UFO before the self-destruct countdown runs out, which is such a classic from sci-fi that it really deserves to be doable. Sectoid Leader to his Engineer: "We are being overrun! Set the Elerium Engine to overload!!"; "Overload in 15 minutes, Sir!"
Or set the radius to one and just make it even harder to get Elerium out of crash sites..
Interesting, in a nasty, masochistic way!
-
New version available
Killer feature is that buildings can now have dependency chain. You can require that to build one building you need have two other available.
Same with research and manufacture, you need specific buildings in base to starts projects.
Some examples:
To do alien autopsy you need have special building Prosectorium in that base.
You can manufacture E-115 but to do that you need build LHC in your base that will drain lot of power bills :)
Only limitation is that you need only one building of that type to benefice from it.
Rest of changes added in this version is change of handling throwing ad hitting using twohanded weapons, now they have penalty like while shooting.
Another change is prime and throw action can be configure to use flat TU costs.
-
wonderful new possibilities... Thank you.
For my part, I just started learning how to mod and I don't think I will use more than 5% of the freedom offered by OXE.
New buildings are a call for longer and longer games and unlike items or armors, they need talented modders for new maps and new routes. Out of my reach. But I will wait for new resources to stole :)
Can I pester you a little about "lazy solutions?" ::)
Referring to the previous posts on "healthUse" and "moraleUse":
what if the soldier that don't have enough hp to use item will simply be knocked down stunned (attack not performed)? Is this reasonable?
Ok I will not open the matter anymore, I swear!
Thank you for your work!
-
Can I pester you a little about "lazy solutions?" ::)
Referring to the previous posts on "healthUse" and "moraleUse":
what if the soldier that don't have enough hp to use item will simply be knocked down stunned (attack not performed)? Is this reasonable?
Ok I will not open the matter anymore, I swear!
Thank you for your work!
This will complicate code a lot, it's because I need add handing of suicide after every place where is spend resource.
If you really want it, I will add this (when I will have some free time) but all burden of providing messages (even in English) will be on you and other people that want use it.
-
You need to stop tempting me Yankes. :) So if a facility that grants research or manufacturing items is removed, does the project still stay in the list?
-
i got this badass openxcm extended idea i been thinking about i m gonna do it one day. is just a simple but COOL mod . i gotta re-read the main page to make sure is possible.
-
You need to stop tempting me Yankes. :) So if a facility that grants research or manufacturing items is removed, does the project still stay in the list?
Its removed, only exception is if you now working on that, then you can't remove facility.
-
This will complicate code a lot, it's because I need add handing of suicide after every place where is spend resource.
If you really want it, I will add this (when I will have some free time) but all burden of providing messages (even in English) will be on you and other people that want use it.
If you feel this change will make OXE less than perfect, then don't do it!
If you do, I will use, I you don't, no problem.
I was only suggesting ideas, I don't want to force your hand.
-
Hmm... if this hasn't been implemented yet, I have an idea that could add to the complexity of weapons:
- "Dropoff" of explosion. Afaik, currently the explosive power drops by 10 per every tile travelled. It'd be great to be able to edit this value via ammo/grenade entry, so you could have large explosions without a "sharp kill zone edge" (as simply cutting the blast radius works if you want to achieve smaller explosion). An ideal would be an option to make the explosion lose % of initial power with inversed square root, but that might be a bit confusing and maybe needless :)
Btw, do airborne Incendiary explosions work in OXCom Extended? In the normal build, hitting an airborne target with Incendiary simply does nothing. Is there as simple solution to this problem? An ideal would be the fire to "drop down", so perhaps Incendiaries should set the target on fire + cause an incendiary explosion on the ground, with the power reduced by the altitude difference...
-
Would it be possible to make a med-kit item that targets the user?
Sure hope that after completing TFTD development team would consider integrating all those goodies into a main branch. Keep up the good work.
-
Hmm... if this hasn't been implemented yet, I have an idea that could add to the complexity of weapons:
- "Dropoff" of explosion. Afaik, currently the explosive power drops by 10 per every tile travelled. It'd be great to be able to edit this value via ammo/grenade entry, so you could have large explosions without a "sharp kill zone edge" (as simply cutting the blast radius works if you want to achieve smaller explosion).
I had plans to do it but I didn't do it because I get distracted by something else.
An ideal would be an option to make the explosion lose % of initial power with inversed square root, but that might be a bit confusing and maybe needless :)
My todo list is to long for now, I will stick to current logic with maybe custom "dropoff".
Btw, do airborne Incendiary explosions work in OXCom Extended? In the normal build, hitting an airborne target with Incendiary simply does nothing. Is there as simple solution to this problem? An ideal would be the fire to "drop down", so perhaps Incendiaries should set the target on fire + cause an incendiary explosion on the ground, with the power reduced by the altitude difference...
do you mean lack of fire? It can't spawn on empty tiles, but it still should do damage to targets (flat 5-10).
Would it be possible to make a med-kit item that targets the user?
Sure hope that after completing TFTD development team would consider integrating all those goodies into a main branch. Keep up the good work.
In theory can be done.
Integrating is pain in a**. Right now I facing lot of work to update with master branch, it's because Warboy move some code that I heavy altered in my branch.
I will need to redone most of my code or throw away Warboy changes.
-
Yankes, I downloaded Extended while toying with a re-balance mod since Open Xcom doesn't support many damage types having a blast, but I can not get it to work. Here is an example of how I tried it.
- STR_HEAVY_PLASMA_CLIP
size: 0.3
costSell: 9590
weight: 3
bigSprite: 25
floorSprite: 33
hitSound: 19
hitAnimation: 46
power: 115
damageType: 5
clipSize: 12
battleType: 2
recoveryPoints: 1
FixRadius: 1
RadiusEffectiveness: 1.0
-
Yankes, I downloaded Extended while toying with a re-balance mod since Open Xcom doesn't support many damage types having a blast, but I can not get it to work. Here is an example of how I tried it.
- STR_HEAVY_PLASMA_CLIP
size: 0.3
costSell: 9590
weight: 3
bigSprite: 25
floorSprite: 33
hitSound: 19
hitAnimation: 46
power: 115
damageType: 5
clipSize: 12
battleType: 2
recoveryPoints: 1
FixRadius: 1
RadiusEffectiveness: 1.0
You forget `damageAlter:`
Proper item should look like:
- STR_HEAVY_PLASMA_CLIP
size: 0.3
costSell: 9590
weight: 3
bigSprite: 25
floorSprite: 33
hitSound: 19
hitAnimation: 0 #LOOKOUT! when weapon have explosion, this require value from big explosion sprites.
power: 115
damageType: 5
clipSize: 12
battleType: 2
recoveryPoints: 1
damageAlter:
FixRadius: 1
RadiusEffectiveness: 1.0
[PS]
I updated my branch to recent nightly.
-
Thanks for the help Yankes, and I am very grateful for Extended. It will make so much possible! :)
Is there any way to define at what range powerRangeReduction begins? If not, any plans to? Would be very helpful!
-
Its always start form square 1, is possible to change it but right now I have lot of different things/requests to do and this would wait long time until I would do it.
My current plans is finish that I have now and after that I you still interested in that feature I could add this.
-
Small update for linux fans.
I made experimental version for ubuntu. I hope it will work on other machines, at least its work on my VM :D
-
Its always start form square 1, is possible to change it but right now I have lot of different things/requests to do and this would wait long time until I would do it.
My current plans is finish that I have now and after that I you still interested in that feature I could add this.
Totally understandable, I can wait. Being able to set the range at which power will begin dropping off will be crucial for what I want to do. Thanks for all your hard work :)
By the way, would you ever release a version of Extended without the changes to gameplay it implements? I love the extended capabilities for modding, but don't agree with some of the changes. Thanks.
-
You mean overkill damage? Or something else?
I can easy remove it (if you mean overkill), I only leave this because I very like that some damage types for default are more "explosive" than others.
-
Yeah, and really anything that changes gameplay like TU cost of reloading and what-not. It's not that I'm against many of the changes (which are cool), it's that Extended offers modders a lot of possibilities to tweak the game to their ideals. That's what's really awesome about it and drew me to it. Hardcoding your own mods into it will turn a lot of people off to modding with it.
I think gamechanges like these should have a true/false flag so people can use what they wish and still be able to take advantage of Extended's possibilities. With more mods made using Extended's capabilities, hopefully we could see those capabilities folded into OXC.
-
Yankes, I wanted to help you out, and since I can't code, I've fixed the readme file: removed spelling mistakes, fixed the grammar and made the text a bit clearer. The file is attached.
Issues:
flatHunderd: 0.0 #const bonus equal 100.
Is this correct? Shouldn't it be flatHundred instead of flatHunderd?
This part:
ResistType: 1 #what resist on unit use, and if is fire or smoke it spawn that, same values like `damageType`.
Sorry, I have no idea what it means and how to fix it. Can you give the Polish equivalent?
-
Yeah, and really anything that changes gameplay like TU cost of reloading and what-not. It's not that I'm against many of the changes (which are cool), it's that Extended offers modders a lot of possibilities to tweak the game to their ideals. That's what's really awesome about it and drew me to it. Hardcoding your own mods into it will turn a lot of people off to modding with it.
I think gamechanges like these should have a true/false flag so people can use what they wish and still be able to take advantage of Extended's possibilities. With more mods made using Extended's capabilities, hopefully we could see those capabilities folded into OXC.
Question for other people who use my mod, do you don't have nothing against for reverting default behavior of overkill to default like in OXC (overkill is when using hi damaging explosives & plasma damage, enemy "explode" without corpse left behind)? You can restore it after that by turning switch `IgnoreOverKill: false` in your weapon.
Yankes, I wanted to help you out, and since I can't code, I've fixed the readme file: removed spelling mistakes, fixed the grammar and made the text a bit clearer. The file is attached.
Issues:
flatHunderd: 0.0 #const bonus equal 100.
Is this correct? Shouldn't it be flatHundred instead of flatHunderd?
This part:
ResistType: 1 #what resist on unit use, and if is fire or smoke it spawn that, same values like `damageType`.
Sorry, I have no idea what it means and how to fix it. Can you give the Polish equivalent?
1 yes
2 this is what damage resistance in armor is used when you do damage form that weapon.
Polish: Angielski to trudna jezyka :D Ogolnie to ten stat sluzy do wybierania ktory rezist z armoru uzywamy podczas obliczania redukcji obrazen.
`damageType` ustawia to oraz tez inne staty ataku, moza powiedziec ze sluzy do ladowania wartosci domyslnych, ten stat zmienia to jedno tylko.
[ps]
btw thanks for fixes, I will apply them in next update.
-
1 yes
Yes hundred or yes hunderd? :P
2 this is what damage resistance in armor is used when you do damage form that weapon.
Polish: Angielski to trudna jezyka :D Ogolnie to ten stat sluzy do wybierania ktory rezist z armoru uzywamy podczas obliczania redukcji obrazen.
`damageType` ustawia to oraz tez inne staty ataku, moza powiedziec ze sluzy do ladowania wartosci domyslnych, ten stat zmienia to jedno tylko.
OK, now it's clear. Thanks!
[ps]
btw thanks for fixes, I will apply them in next update.
No problem. I'll post the update when the hundred/hunderd thing is resolved.
-
https://en.wikipedia.org/wiki/100_%28number%29 ;P
-
Why thank you, good sir. :)
-
Yankes, have you considered adding additional ranks for XCom soldiers? I was looking at the rank list yesterday and thought that it would be nice to have some additional ranks to fill the gaps:
(https://www.ufopaedia.org/images/4/4c/XCom1_rank6_Commander.GIF) Commander
(https://www.ufopaedia.org/images/c/c3/XCom1_rank5_Colonel.GIF) Colonel
(https://www.ufopaedia.org/images/a/a6/XCom1_rank4_Captain.GIF) Major (insignia is the current one of Captain)
(https://www.openxcom.com/content/modimages/JCLYCDSQ040920150629.gif) Captain
(https://www.openxcom.com/content/modimages/NEISYHFN040920150629.gif) Lieutenant
(https://www.ufopaedia.org/images/4/47/XCom1_rank3_Sergeant.GIF) Sergeant
(https://www.openxcom.com/content/modimages/ZFCWCJEV040920150629.gif) Corporal
(https://www.ufopaedia.org/images/9/9b/XCom1_rank2_Squaddie.GIF) Squaddie
(https://www.ufopaedia.org/images/6/60/XCom1_rank1_Rookie.GIF) Rookie
This would require some change to the .EXE for the promotion requirements.
-
Yankes, have you considered adding additional ranks for XCom soldiers? I was looking at the rank list yesterday and thought that it would be nice to have some additional ranks to fill the gaps:
(https://www.ufopaedia.org/images/4/4c/XCom1_rank6_Commander.GIF) Commander
(https://www.ufopaedia.org/images/c/c3/XCom1_rank5_Colonel.GIF) Colonel
(https://www.ufopaedia.org/images/a/a6/XCom1_rank4_Captain.GIF) Major (insignia is the current one of Captain)
(https://www.openxcom.com/content/modimages/JCLYCDSQ040920150629.gif) Captain
(https://www.openxcom.com/content/modimages/NEISYHFN040920150629.gif) Lieutenant
(https://www.ufopaedia.org/images/4/47/XCom1_rank3_Sergeant.GIF) Sergeant
(https://www.openxcom.com/content/modimages/ZFCWCJEV040920150629.gif) Corporal
(https://www.ufopaedia.org/images/9/9b/XCom1_rank2_Squaddie.GIF) Squaddie
(https://www.ufopaedia.org/images/6/60/XCom1_rank1_Rookie.GIF) Rookie
This would require some change to the .EXE for the promotion requirements.
I once though about hijacking those to implement portraits for agents.
-
Pretty sweet those ranks!
-
I made those with some quick copy/paste.
I wish there was a better rank insignia for Commander. I never figured what the current one means, I assume it's a skull but it is weird looking.
-
The badges where likely made when the enemy was still unknown so they just made a weird-looking skull to represent an alien skull. If a skull is symbol of death, that would mean "alien death" :P
-
50% skull, 50% mushroom cloud, 100% badass.
-
Just to complete the derailment of this topic, the Commander's rank often strikes me a bit overly phallic.
-
Just to complete the derailment of this topic, the Commander's rank often strikes me a bit overly phallic.
Well then I wouldn't stare too much at the Colonel one if I were you..
-
Just to complete the derailment of this topic, the Commander's rank often strikes me a bit overly phallic.
Wait until you see the General or Marshal ones...
-
(https://www.ufopaedia.org/images/4/4c/XCom1_rank6_Commander.GIF) Commander
(https://www.ufopaedia.org/images/c/c3/XCom1_rank5_Colonel.GIF) Colonel
The commander one looks like Rio Jesus with fly-like eyes and a hoodie.
The colonel one looks like Irokese Harry Potter about to cast Avada Kedavra with both hands simultaneously.
No, I am not intoxicated.
-
Wait until you see the General or Marshal ones...
Good grief... I'm not sure I want to see that :)
-
Yankes, have you considered adding additional ranks for XCom soldiers? I was looking at the rank list yesterday and thought that it would be nice to have some additional ranks to fill the gaps:
This would require some change to the .EXE for the promotion requirements.
Hard to say, I didn't touch this code to say if it will be hard or easy to do. Only one thing I recall that could be problematic is morale bonuses given by ranks.
I can put it on "far" todo list because right now I have some things planed.
BTW
Today or tomorrow I will publish new version, two main features will be physical training options (based on old WarBoy patch) and control over weapon turn restriction for aliens (contributed by redv).
-
Which Nightly will this new version be equivalent to?
-
31.03, I postpone merging recent changes from master branch. Do you want newer version?
-
No, actually I hoped for precisely that one :)
-
Ok, new version is up.
changes:
Option for training rooms.
You can fully configure turn delay of alien weapon usage (global per weapon type/each weapon).
You can rename weapon slots in geoscape craft info (this is per craft).
Changed moment when current tu/energy bonus is calculated to weapon bonuses. Now is always: Spend Resources -> Calculate bonuses -> Apply damage
Previously when you do reaction shoot, game spend all resources for all shoots before firing any bullet. And normal shooting spend resources after firing bullet.
btw Solarius Scorch, when next time when you want fix my grammar mistaken, please edit this file:
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/Extended.txt
This is master file that I use to generate readme.txt, first post in this tread and Mod page description.
Merging manually readme.txt with that file is very easy to mess up and I did it already couple of times now.
[ps]
I forget mention one important change, I turn off default overkill damage because it was outstanding compare to normal OXC.
-
Likely dumb question:
why there are two files, OpenXcomEx.zip, OpenXcomExElf.zip, for the same version (1.6) ?
-
elf as name suggest is linux "exe" :D
-
So Yankes,
Have you thought about enhancing the civilian AI a bit in your version of OXC?
See thread where I apparently caused a bit of a ruckus: https://openxcom.org/forum/index.php/topic,3553.0.html (https://openxcom.org/forum/index.php/topic,3553.0.html)
-
So Yankes,
Have you thought about enhancing the civilian AI a bit in your version of OXC?
See thread where I apparently caused a bit of a ruckus: https://openxcom.org/forum/index.php/topic,3553.0.html (https://openxcom.org/forum/index.php/topic,3553.0.html)
One thing that I once consider was give them alien AI (of course with changing who they consider as enemy) to allow them use weapons. Overall I made changes to AI but that was only small tweaks without changing overall logic. To made them smart would require lot more changes than that.
I don't know how to do it, I prefer doing change that I know how it should work before I start coding.
Last thing this don't align with goal of my branch that is increase modding capacity.
[branch progress]
Implemented new feature in my branch, now items/weapons can spend your HP, Morale and do stun damage when you use it. This required breaking change with old version because I removed old way of defining energy cost of use.
probably today or tomorrow will be new release.
[todo]
preprimed alien grenades
armor custom melee dodge and psi def
multiple inventory paperdolls
valid target specification for medkit & psiamp (special use attak)
[far todo]
range power reduction threshold
splash power reduction
more ranks
-
I don't know how to do it, I prefer doing change that I know how it should work before I start coding.
Last thing this don't align with goal of my branch that is increase modding capacity.
That's fine. I was wondering if you had thoughts about it. Of course, making the AI modular in the code, you could create "personalities" for Aliens and civilians that can be assigned at the "mod" level for certain mission types.
[branch progress]
Implemented new feature in my branch, now items/weapons can spend your HP, Morale and do stun damage when you use it. This required breaking change with old version because I removed old way of defining energy cost of use.
probably today or tomorrow will be new release.
Sounds really cool, btw. That would make one more careful about using certain items or weapons and could put a different spin on things.
-
This might seem obvious, but new ranks would also require un-hardcoding rank requirements and bonuses... and here's an idea:
Most people would probably want for the new ranks to work as old Sergeant+ ranks (ie. just more officer ranks). How about allowing for an alternate option: a soldier can be given an officer rank, as normal (depending on the number of soldiers/officers), but he can also advance in non-officer rank (like, from squaddie to veteran squaddie, to elite squaddie), ex. based on the number kills*missions - this would allow to see the approx quality of a soldier at a first glance - frankly, I don't like "squaddies forever" syndrome which happens when there is no place for new officers anymore. Naturally, as soon as any officer's post opens, such veteran/elite squaddie can be promoted as normal. This would basically require breaking up the ranks into 2 categories: soldier ranks (based on experience) and officer ranks (based mostly on the total number of XCom soldiers).
-
you can almost copy/paste AlienBAIState into CivilianBAIState and change all the faction checks to make them target aliens, or you can give civilians an AlienBAIState and put in extra "if" statements to handle the difference. personally i'd go for the first option to avoid confusion.
-
you can almost copy/paste AlienBAIState into CivilianBAIState and change all the faction checks to make them target aliens, or you can give civilians an AlienBAIState and put in extra "if" statements to handle the difference. personally i'd go for the first option to avoid confusion.
Cool. I might go poke around then :)
-
This would basically require breaking up the ranks into 2 categories: soldier ranks (based on experience) and officer ranks (based mostly on the total number of XCom soldiers).
So basically like most militaries have -> non-commissioned officers (private first class (squaddie), to corporal, then all the way to master sergeant or higher depending on what military you model like sergeant major of the army) and commissioned officers (lieutenant to commander or general).
Would the morale affects be granular from top to bottom or would their be some overlap like a high level vet NCO has the same morale affect as a low ranking CO? Thematically, I could see the second part of the question being more the case, because your people would get more attached to a long time vet who isn't commissioned (sergeant major) and gets killed versus some lieutenant fresh out of officer's school getting dropped right off the skyranger ramp.
I do like the idea of more ranks for thematic sake, just not sure how much it will affect the gameplay overall.
-
New version ready
Still based on 31/03/2015
New features are new cost for item/weapon use.
costAimed:
#cost of Aimed attack.
time: 2 #time units cost, can be in %. Alias of `tuAimed`.
energy: 0 #energy unit cost.
morale: 10 #morale points cost.
health: 1 #health points cost.
stun: 2 #stun damage applied by atack use.
every `tuSomething` from oxc have now corresponding `costSomething`. Compared to previous version where only weapons handle it. Now all item types can use it.
I added threshold of when start applying power range reduction.
Explosion now have customizable reduction of power per tile.
btw custom ranks have big road block. when you try go back from OXCE to OXC after changing numbers of ranks game will crash or alt least be heavy bugged.
I prefer features that can easy fall back to original ones without big fuss. I don't know if this feature is worth breaking this forward compatibility with basic version.
-
All good news.
Yankes, would it be possible to un-hardcode the race that defends Cydonia on the surface? (Normally Sectoids.)
I'd like to make that final mission a bit harder, with special defensive crew.
-
un-hardcoding Cydonia is required by TFTD. I can made patch for normal OXC that will do it.
-
... it's not hard coded in the slightest, that was removed months ago (around the same time as mapscripts)
-
Done :D
-
btw custom ranks have big road block. when you try go back from OXCE to OXC after changing numbers of ranks game will crash or alt least be heavy bugged.
I prefer features that can easy fall back to original ones without big fuss. I don't know if this feature is worth breaking this forward compatibility with basic version.
I don't think it's worth it then, personally.
-
I don't think it's worth it then, personally.
But after some thoughts I can see light in tunnel. Simply don't touch ranks and its logic at all, but introduce new sub ranks. Something like you propose for Sergeant.
Every rank could have 1 or more sub ranks. This would be a lot of more compatible with basic version because solders rank will be still valid value after version downgrade. Only conceptual problem I see is how to best handle promotion of hi subrank to next normal rank. Do lowest subrank in next rank is better or worse than largest subrank in previous rank.
-
But after some thoughts I can see light in tunnel. Simply don't touch ranks and its logic at all, but introduce new sub ranks. Something like you propose for Sergeant.
Every rank could have 1 or more sub ranks. This would be a lot of more compatible with basic version because solders rank will be still valid value after version downgrade. Only conceptual problem I see is how to best handle promotion of hi subrank to next normal rank. Do lowest subrank in next rank is better or worse than largest subrank in previous rank.
That seems like a perfect solution! This could actually permit for basically unlimited number of ranks.
Hmm... if the problem is a conceptual one, it's a safe bet to leave it to the modders to decide (each rank has 'outgoing' rank which can be defined in the ruleset, by default Rank 1 highest goes to Rank 2 lowest. This is a list, so if there is more than single outgoing, the game checks prerequisites - like officer post availability and/or number of kills*missions? If more than one next rank satisfies the preqs, chooses randomly).
-
So something like this: https://docs.google.com/spreadsheets/d/1rgHZaZYI7_WQ1-x_vTAmYcYCRpW2VFjPA3-Zfng3_bY/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1rgHZaZYI7_WQ1-x_vTAmYcYCRpW2VFjPA3-Zfng3_bY/edit?usp=sharing) ?
This is just a reference for a starting point for OXC ranks mapped to OXC Extended sub ranks. I based it on U.S. Army, because it's what I know more. I'm certainly not tied to the nationality for the ranks, since X-COM is a international military op.
-
Yankes, while this is a bit bold, there's a feature that I would like to see in the game, and that desire grows every day.
We can now have any ships perform special missions (like Terror or Retaliation), but they all will deploy exactly the same crew, because STR_TERROR_MISSION and STR_BASE_DEFENSE aren't related to the ship that drops them. This pretty much kills the concept, since we can't have multiple crews for the job - the landing party is always the same.
Now, what I would like to propose is to ignore deployments like STR_TERROR_MISSION and STR_BASE_DEFENSE and use the same crew as the ship's. This would allow you much more freedom, for example to design several threat levels for alien missions. Besides, why would the landing party use different equipment than what they had on board? (Not that the difference was significant at any point.)
-
Now, what I would like to propose is to ignore deployments like STR_TERROR_MISSION and STR_BASE_DEFENSE and use the same crew as the ship's. This would allow you much more freedom, for example to design several threat levels for alien missions. Besides, why would the landing party use different equipment than what they had on board? (Not that the difference was significant at any point.)
Yeah I'd second that - separate mission/ufo deployment loadout just makes you copy-paste stuff, and there's little practical use for it.
-
Simply you want flag "ignoreMissionDeploy" in craft? :)
-
Simply you want flag "ignoreMissionDeploy" in craft? :)
Maybe, I don't know the code. :) But yeah, I think so.
-
This will be probably easy to do. I will put it on my TODO list :)
-
This will be probably easy to do. I will put it on my TODO list :)
Cool. :) Though please leave the old option open in case someone wants it.
Actually, I would like to have yet another request: assigning equipment by race.
For example:
(not actual code, I don't have the files here)
ship: STR_TERROR_SHIP
rank: alien rank 5
equipment:
- STR_HEAVY_PLASMA
- STR_HEAVY_PLASMA_CLIP
- STR_HEAVY_PLASMA_CLIP
- STR_ALIEN_GRENADE
rank: alien rank 5
race: STR_SECTOID
equipment:
- STR_PLASMA_RIFLE
- STR_PLASMA_RIFLE_CLIP
- STR_PLASMA_RIFLE_CLIP
- STR_ALIEN_GRENADE
So this particular alien is armed with a Heavy Plasma, as long as it's not a Sectoid - in this case, he gets a Plasma Rifle instead.
This mechanics can be used for example to eliminate Sectoids with heavy weapons (like some people envisage them), but my main objective is to allow non-alien enemies to have their own specific weapons in general missions like Retaliation, for example Men in Black using firearms.
-
New version is ready
Update to recent nightly.
I made Solarius Scorch request first because it had biggest `gameplay impact`/`lines of code` ratio :)
Now every ufo have two new properties:
ufos:
- type: STR_UFO_TYPE
craftCustomDeploy: STR_BATTLESHIP
missionCustomDeploy: STR_TERROR_MISSION_AND_BASE_RAID
raceBonus: #bonus stats per race.
STR_SECTOID: #name of race that bonus apply.
craftCustomDeploy: STR_BATTLESHIP_SECTOID #override for race
missionCustomDeploy: STR_TERROR_MISSION_SECTOID #override for race
`craftCustomDeploy` is used when you attack ufo do determine what weapons aliens have (use data form `data` node in aliens deployments).
`missionCustomDeploy` is used when that ufo start mission. All mission will use it (terror/base defense).
I added option to change weapon deploy in alien bases too:
alienRaces:
- id: STR_SECTOID
baseCustomDeploy: STR_ALIEN_BASE_ASSAULT_SECTOID
Right now you can't override map generation data only weapons/units. Is possible to do it but for now it will skip it.
Another thing is next stage of mission will use only data from mission definition deploy. I had hard time with way is correct/better, ufo data always override alien deploy or next stage deploy is fixed.
-
Thank you, thank you, thank you!
-
You better should answer my dilemma with second stage missions ;P
-
You better should answer my dilemma with second stage missions ;P
I don't have strong opinions on two-stage missions. More modding options is always good, but I personally don't think it's very urgent.
-
Just tried v1.8 of OPXCE on my current game involving "ufo redux" but the same thing happens when I had tried v1.7 of OPXCE. The game freezes during the hidden movement phase after my first turn and won't reach the start of my second turn. Any idea what's going on here? I was looking forward to trying the craft 4 weapon loadout, training room facility and my own mod acid bomb. Thanks in advance.
-
If you switch to normal version every thing work fine? If yes then its my fault. What version of Redux you use?
-
redux version 0.5
-
I find source of bug, today I will probably make new version.
-
Fixed version is ready, SIMON can you test that is every thing right? I could not test your save because of 20+ mods you have :D
[ps]
I updated to recent nightly too.
-
I've given v1.8a a test run there on my current game and seems to run okay as I was able to do a sectoid/floater medium scout except for the base screens, they look pixelled, see attachments. Probably something very minor. Wud it be something to do with options I've enabled? One final point I wud like to know is when u get psionic training does that mean there wud be a choice of 4 buttons in the soldier screen ie: memorial, training, psionic and cancel. Still originally based off nightly of 2015-04-18 1150.
-
I updated to 21.04.2015 It have some big refactoring that could break palettes.
And about buttons, yes 4 buttons will appear.
-
Just tested there with latest nightly (21 April) and everything seems grand but since I'm in the middle of doing the merc base atm, I'll start playing my current game fr OPXCE 1.8a and nightly 2015-04-21 after I hopefully complete the mission. Thanks again for all ur help, the soldier screen with 4 buttons looks excellent.
-
Thoroughly enjoying this addition to my current game and I was wondering, as I have checked everywhere I can think of, what exactly are the increases that your troops get from the training room mod, is there somewhere I can read up on what a troop gets every month to what stat?
-
Change of stats is not tracked.
-
New version ready.
Changes:
Options for customizing retaliation mission after shooting down ufo.
Options for adding custom dodge chance or unit psi defence.
Right now you can easy dodge attack from behind, I was thinking about some penalty for that.
One example of this would be linear drop of you dodge when attack direction is closer to back, e.g.:
dodge
Front: 100
75
Side: 50
25
Back: 0
Or less linear
dodge
Front: 100
100
Side: 75
50
Back: 0
Or something completely different?
-
Yeah, definitely should be penalized. Actually, it should only work against enemies the unit can see. (Except melee maybe.) (Actually, maybe it would be best to allow dodge an attack coming from outside the seen area, since we can always set it to 0 anyway.)
-
dodge
Front: 100
80
Side: 70
50
Back: 33
Unless all fights take place in an airless vacuum then noise would still give a hint of danger.
Your chances of dodging are low, since you know neither the trajectory, speed nor the exact direction of the attack, but it's still there.
-
I'm not convinced by the mechanism, because it mostly works against the AI which will not take it into account as well as the player.
-
New version ready.
Changes:
Options for customizing retaliation mission after shooting down ufo.
Options for adding custom dodge chance or unit psi defence.
Right now you can easy dodge attack from behind, I was thinking about some penalty for that.
One example of this would be linear drop of you dodge when attack direction is closer to back, e.g.:
dodge
Front: 100
75
Side: 50
25
Back: 0
Or less linear
dodge
Front: 100
100
Side: 75
50
Back: 0
Or something completely different?
How does this "dodge mechanic" work?
Has a unit the chance to make a potential hit go missing instead?
-
How does this "dodge mechanic" work?
Has a unit the chance to make a potential hit go missing instead?
From weapon hit chance you subtract dodge chance. Final value determine if hit was successful.
Logic is simple but probably enough for turn based strategy.
-
A more complicated dodging system would have the unit walk a step away as the shot flies towards it, the direction of the step being the closest tile where there is no line of fire to the shooter if such exists - otherwise a random direction that is not parallel to the shot trajectory.
But that's just a little, difficult finesse.
-
made some tiles for the training facility.
get them here: https://openxcom.org/forum/index.php/topic,3350.msg43786.html#msg43786
-
Got this result when tried your mod... face color values unchanged from before activating it (and it worked no problem before):
EDIT: Started to work when I've bumped up the spriteFaceColor number. Looks like, in Extended, you can only darken the shade, you cannot lighten it (as it was the case with my ruleset), while in normal OXCom it works both ways (darkening and lightening).
-
Yankes, regarding soldier training on base, would it be possible to have two separate training facilities? Because I would like to have:
- Shooting Range: trains Reactions, Firing Acc, Throwing Acc
- Gym: trains TUs, Stamina, Strength, Melee
(Nothing trains Health and Bravery, you have to do battles for that.)
You can assign your soldiers to the Gym, to the Range, or the Psi Lab, but not more than one at a time.
I can imagine that the ruleset for each building has a list of stats that get upgraded monthly. And in the game, under "Soldiers" screen you get as many buttons as required with that ruleset, labelled "Psi-Lab", "Gym" and "Shooting Range". (Of course there are two separate behaviours with "Training at any time" enabled or not, so unfortunately the code would have to cover both.)
-
Yankes, regarding soldier training on base, would it be possible to have two separate training facilities? Because I would like to have:
- Shooting Range: trains Reactions, Firing Acc, Throwing Acc
- Gym: trains TUs, Stamina, Strength, Melee
(Nothing trains Health and Bravery, you have to do battles for that.)
You can assign your soldiers to the Gym, to the Range, or the Psi Lab, but not more than one at a time.
I can imagine that the ruleset for each building has a list of stats that get upgraded monthly. And in the game, under "Soldiers" screen you get as many buttons as required with that ruleset, labelled "Psi-Lab", "Gym" and "Shooting Range". (Of course there are two separate behaviours with "Training at any time" enabled or not, so unfortunately the code would have to cover both.)
Biggest problem I have with this is UI. Right now is nearly enough place for two buttons and this would require another one. UI required by current training facilities was borderline of what I could add to my branch, because its add completely new screen. If I find way that don't require adding new screens or mess too much with UI, I could do it.
@Dioxine
I looking on this.
-
The only workaround of this "gym problem" I see is:
1. Change "Psi Training" button into "Training" button. It would open up the training menu with as many buttons as required by the mod (one for each facility type); same with end of the month, multiple screen popup.
2. Rely on "r-click a facility" funcionality;
And I don't know how it works for now, but if trainings are mutually exclusive (a soldier can only train at a single facility at a time), this problem would be less pronounced.
Also this is a minor question... but maybe it should be possible to define "training caps" in the soldiers entry (where maxstats etc. are located), because some people (myself included) wouldn't like soldiers to be able to get to the very peak of their ability without ever smelling gunpowder, just with enough time in training. These would be defaulted to the same numbers as statCaps if not defined.
-
The only workaround of this "gym problem" I see is:
1. Change "Psi Training" button into "Training" button. It would open up the training menu with as many buttons as required by the mod (one for each facility type); same with end of the month, multiple screen popup.
2. Rely on "r-click a facility" funcionality;
This was one way I could do it.
And I don't know how it works for now, but if trainings are mutually exclusive (a soldier can only train at a single facility at a time), this problem would be less pronounced.
Also this is a minor question... but maybe it should be possible to define "training caps" in the soldiers entry (where maxstats etc. are located), because some people (myself included) wouldn't like soldiers to be able to get to the very peak of their ability without ever smelling gunpowder, just with enough time in training. These would be defaulted to the same numbers as statCaps if not defined.
When I would add different training facilities then custom caps (or even starting requirements) is basic feature for this.
-
I also thought a single button with a submenu would be best, but I don't know much about the UI and was hesitating to speak up.
Good call with the max stat improvement, too. (I think psi balance would also benefit from this limitation.)
-
That training thing sounds great! Could there be a hospital to "train" HP up back to healthy faster too? It would be nice to be able to unlock a facility that heals soldiers faster once you have research all the alien medical tech (cloning/surgery/observation room).
- Gym: trains TUs, Stamina, Strength, Melee
If the gym trains melee, it should train reactions too. Martial arts are great for reflexes, much better than shooting targets (although I guess you can have moving/popping targets like in MiB but still).
-
That training thing sounds great! Could there be a hospital to "train" HP up back to healthy faster too? It would be nice to be able to unlock a facility that heals soldiers faster once you have research all the alien medical tech (cloning/surgery/observation room).
Not a bad idea. I guess the "training" would be obligatory then. :)
If the gym trains melee, it should train reactions too. Martial arts are great for reflexes, much better than shooting targets (although I guess you can have moving/popping targets like in MiB but still).
Well I don't know, I think it depends on what you're using these Reflexes on. Basically, good shooting reactions should be worked upon on the Shooting Range (think suddenly appearing targets, this kind of stuff), while melee reflexes should be improved in the gym. This game however has only one stat for both uses, so maybe both facilities should train it?
-
If only the gym or the shooting range will improve reactions, it would be more intuitive if the shooting range improved reactions. Reactions are usually used to react while shooting and to duck when aliens shoot at you in game.
In my opinion having both improve reactions might be the best option.
-
Oh.. I did not realize I phrased my comment quite that way.. What I meant to say is that both facilities should do it. If a gym trains melee, then presumably it is a form of combat training which should increase reactions too. A shooting range can have a way to improve reactions as well, but it is more difficult to reproduce a combat situation.. Unless you have a paintball fight, or turn down the laser rifles to play laser tag :D
It is also for a balance reason. Reactions and accuracy are the two stats I value the most. Every thing else is secondary. With good reactions you survive better (shoot things when they show up and don't get shot up when showing up). With good firing accuracy you kill stuff. Training both at the firing range leaves the gym as a really secondary facility.
It might well be more productive the train reactions and firing at the range, then depend on fights to gain the TU/Str/Stam which will be easy to gain by shootings things. As opposed to training TU/Str/Stam in the gym and depend on fights to increase your firing and reactions (both hard to gain if you're not already good). Mods like Piratez which put an emphasis on melee would change that, but anything gun dominated like vanilla is dominated by reactions and firing.
On the hospital: You could have one to which you assign soldiers, with limited spots (since it would take alien tech and lots of money to supply it). Those assigned recover faster, the others recover at the vanilla rate. Really fancy hospitals with cloning tech might even allow you to bring back a soldier from the memorial!
-
It is also for a balance reason. Reactions and accuracy are the two stats I value the most. Every thing else is secondary. With good reactions you survive better (shoot things when they show up and don't get shot up when showing up). With good firing accuracy you kill stuff. Training both at the firing range leaves the gym as a really secondary facility.
I think it depends on your playing style, for example to me that's upside down, since Reactions is a low-priority stat to me (I don't rely on it) and Firing Accuracy is easily trainable. My main concern is TUs/Stamina (Imobility) and Melee (because it's initially very low and cannot be trained without actually hitting stuff in melee, which is dangerous and hard).
Anyway, the exact balance of bonuses can be figured out later, it doesn't really belong in this thread.
On the hospital: You could have one to which you assign soldiers, with limited spots (since it would take alien tech and lots of money to supply it). Those assigned recover faster, the others recover at the vanilla rate. Really fancy hospitals with cloning tech might even allow you to bring back a soldier from the memorial!
That's a bit much, especially considering OXCE allows units to be completely annihilated. :P Vanilla allows body destruction too.
-
If you put cloning tech into the fold it will be too much IMHO. I have played a lot of test runs with save scumming on and used the same batch of soldiers from the beggining ( in all X-COm, TFTD and piratez) reloading after each death. In the end you have a bunch of death machines that their only weakness is the psiweakness some might have. I do not recomend bringing soldiers back like that.
-
@Solarius: That must be true.. Reactions is really important to me especially since it is so hard to get. You can train a high reaction rookie in everything else faster than you can train a sokdier that's good at everything to have good reactions. And reactions will save you, from being reacted to or by firing that warning shot that makes the chryssalid go back into hiding.
On cloning: It all depends on the cost and the timing. Not loosing any soldier allows them to train in each fight which makes them much better than a soldier who would die and be resurrected months later after cloning is invented and their cloning process completed.
There's a lot of tuning too. How long for xcom to make a full grown human? 6 months? How efficient is cloning? If you retrieve 50% of stats it's useless, so maybe.. 75%? I think it could be an interesting feature and take advantage of existing alien tech, but of course it needs tweaking.
-
I just think necromancy is creepy. :P
-
Oh.. I did not realize I phrased my comment quite that way.. What I meant to say is that both facilities should do it.
*SNIP*
On the hospital: You could have one to which you assign soldiers, with limited spots (since it would take alien tech and lots of money to supply it). Those assigned recover faster, the others recover at the vanilla rate. Really fancy hospitals with cloning tech might even allow you to bring back a soldier from the memorial!
I would say that all of these things are good features. Not necessarily for vanilla XCOM, but they are good features to have available for not-entirely-XCOM things.
-
On cloning: It all depends on the cost and the timing. Not loosing any soldier allows them to train in each fight which makes them much better than a soldier who would die and be resurrected months later after cloning is invented and their cloning process completed.
There's a lot of tuning too. How long for xcom to make a full grown human? 6 months? How efficient is cloning? If you retrieve 50% of stats it's useless, so maybe.. 75%? I think it could be an interesting feature and take advantage of existing alien tech, but of course it needs tweaking.
If we take out the probability of one shot death (for the arguements shake), having a soldier that was alive from day 1 and was active in most missions with an average time spent in med bay and (again for the shake of the arguement) is not a psi wimp, by the time you will assault cydonia he will be a one man wrecking crew or as close as the game allows it. Now factor this in with multiple soldiers and you will have an army that wrecks face.
Fine tunning might be the answer and actually giving a soldier 50% of his stats back, might be a good option (depending on who died ofc) and actually take care of the abuse (having a god immortal squad) by itself. In my above paradigm you would have a combat fit soldier that is not crazy strong and would eliminate the need to hire new rookies. But repeated deaths would lead to diminishing stats necessiating recruiting (which should be in the game).
I just think necromancy is creepy. :P
Meh consider it like fabricating robots (I am against cloning in RL).
-
Instead of cloning, you could have it as a "regeneration" process that requires the corpse of the fallen soldier, and then limit the number of maximum regenerations to 2 or 3 on the basis that further regeneration would risk severe deterioration of the genetic material.
-
I would say that all of these things are good features. Not necessarily for vanilla XCOM, but they are good features to have available for not-entirely-XCOM things.
In fact, add a weapon flag that lets soldiers apply medikit-like items to themselves onto that.
no this has no relation to "how can you be a pirate if you can't even hold your own rum" what are you talking about
-
I just don't think the revival mechanics hold water. If X-Com had such tech, they'd indeed be producing cheap biorobots en masse (exactly like the aliens do), not clone their fallen comrades. Because this makes no sense whatsoever.
In fact, add a weapon flag that lets soldiers apply medikit-like items to themselves onto that.
That's also a good idea.
Speaking of medikits: I remember long ago that items were supposed to become exhaustible in OXCE, so a used medikit would be lost forever due to depletion just like ammo. (Even more pronounced in Piratez, where your healing items are alcoholic beverages.) Is it in the game, or not?
-
Instead of cloning, you could have it as a "regeneration" process that requires the corpse of the fallen soldier, and then limit the number of maximum regenerations to 2 or 3 on the basis that further regeneration would risk severe deterioration of the genetic material.
I dont think the problem is how one would call it :)
-
Well writing code for this would be banal (all it takes is to retrieve a soldier from the Memorial - you can actually do it quite easily yourself by doctoring a save), but for me an important part of XCom is precisely the fact that the soldiers are mortal. You let them die, they're gone forever, all you can do is visit their graves.
One small improvement request I'd like: armor should be removed from soldiers that are killed & moved to the Memorial. Normally it makes no difference, but if it was a stat-modifying armor, the modifiers stay on a deceased soldier and I think it is inelegant (and in the case of revival/save doctoring, it is required - armor was destroyed, wasn't it, and if you have retrievable armor, it was retrieved, so the revived soldier cannot still have his own "copy" of the armor).
-
I still say resurrection should be a thing, even if it's only passable for a Sword & Sorcery setting where necromancy is a thing.
because having the possibilities there is always good
-
I still say resurrection should be a thing, even if it's only passable for a Sword & Sorcery setting where necromancy is a thing.
because having the possibilities there is always good
Yeah, put this way it's certainly true. But since as of now there is no actual fantasy total conversion, I think it would be best to ask Yankes for stuff that is immediately needed.
-
Yeah, I'm not against in on principle - in some settings it would make sense, plus (I might be wrong) it's not that difficult to add.
Also a bugreport (or rather, inconsistency report):
Extended adds extra cost to weapon reloading (equal to the cost of moving an ammo article from where you have it stuck to an imaginary hand). HOWEVER, this does not work when you use the [R] key for reloading - the game uses base TU cost then.
-
I don't think I will do any healing or resing in my OXCE build. It would require too much UI changes to work properly.
More probably I would add option to configure numbers of day off duty caused by wounds (configured by armor or maybe global too).
And for MediKit I already added option for self heal, it will be available in next build. Its very possible that I will releases it today.
Its depend on this if Dioxine stop throwing new bugs on my :D
-
A minor one: Psi Amp doesn't display "out of range" message when the target is out of range (no buggy behaviour, just no message).
EDIT
Aaaand a major one. This below has happened when I used:
- type: STR_MOLOTOV
size: 0.05
costSell: 50
weight: 3
bigSprite: 195
floorSprite: 201
handSprite: 872
bulletSprite: 17
fireSound: 39
power: 30
damageType: 2
damageAlter:
ToMorale: 30.0
accuracyAimed: 70
costAimed:
time: 45
energy: 6
costThrow:
energy: 6
clipSize: 1
battleType: 1
arcingShot: true
maxRange: 20
bulletSpeed: -2
attraction: 10
listOrder: 4200
(damageAlter was the modification that caused this)
On the battlescape, the patient is very much alive and even having like 4000+ TUs... :)
-
how you do get this exactly? Using only this weapon and standard solders I can't reproduce this.
-
Hmm, maybe it's the patient? She's susceptible to fire:
(nothing special about the Unit, 30 health, 60 bravery, no specabs or stuff like that)
- type: HUMAN_ARMOR_F4
spriteSheet: HUM_4.PCK
spriteInv: HumanFemale4InventoryImage
spriteFaceGroup: 6
spriteFaceColor: [94, 94, 96, 96, 97, 160, 162, 163]
corpseBattle:
- STR_HUMAN_4_CORPSE_BATTLE
corpseGeo: STR_GOVT_CORPSE
frontArmor: 5
sideArmor: 5
rearArmor: 5
underArmor: 5
damageModifier:
- 1.0
- 1.0
- 1.5
- 1.0
- 0.8
- 1.0
- 1.0
- 1.0
- 1.0
- 4.0
loftempsSet: [ 2 ]
This was a result of a direct hit. Some of the other patients died normally, though. ALSO: I was using the debug mode, and the debug mode sometimes produces funny results lately.
-
btw Psi-amp work fine for me. If you used debug do your solders relay see alien? Units still must obey LOS even if you see everything.
-
New version 2.0:
Update to recent nightly
Breaking change: Psi-Amp use now weapon dropoff and aimRange for attack chance.
Breaking change: Drop support for Regeneration stat in armor.
Inventory screens can now have up to 128 backgrounds.
Unit sprites recolors can now support up to 128 values.
Option for custom change of TU, HP, Energy, Morale or Stun after next turn based on unit stats.
New stat bonus based on stun level of unit.
Option for changing fuse type in granades and flare.
Option for pre-priming granades on map spawn.
Option for dodge chance based on direction of attack.
Oprion for bonus morale recovery when using medkit.
Option for self heal using medikit.
For now I used all primary ideas for changes. I have still some secondary things like custom ranks or custom training facilities.
But for now I open for request. Criteria are simple keep is simple and do not touch UI or Translations :>
-
Ooooh, pick mine, pick mine!
I was disappointed that each craft weapon slot only supports one item type. I was expecting a list, so for example you could have one slot that only takes guns, another that takes either guns or radar enhancement, and a third one that takes everything. That's how I balanced everything in the FMP Extended project, but now I see it's not viable.
So, is it possible to have such lists for each craft weapon slot?
-
This is good that you pick my idea :D Only question I have on with side add this list. Weapon slot can accept multiple weapon types or weapon can have fit in multiple weapon types slots.
-
This is good that you pick my idea :D Only question I have on with side add this list. Weapon slot can accept multiple weapon types or weapon can have fit in multiple weapon types slots.
I don't think a weapon belonging in more than one category is necessary for my purposes, though I can't speak for the entire community. Here's how I'd like to organize the weapons into types:
Cannon: Cannon, Alloy Cannon, Gauss Cannon, Rail Cannon
Beam: Laser Cannon, Plasma Cannon
Light Rocket: Stingray, Stormlance
Heavy Rocket: Avalanche, Fusion Ball
Electronics: Radar Extension (radar range), Radar Res Processor (radar chance), Targeter (bonus accuracy, bonus damage)
Afterburners: Afterburners (bonus acceleration and speed)
Shield: Graviton Shield (20 armor)
Fuel Tank (bonus fuel)
Thrusters (bonus dodge +10%)
And here's the actual table for various planes:
(https://i.imgur.com/mmixVQv.png)
So some slots have a specified item type, some are unspecified, and some (most) have several specified types.
I see no reason to give an item several types, but well, it wouldn't change anything - but it's unnecessary, since you can control it from the slot end.
-
I don't think a weapon belonging in more than one category is necessary for my purposes, though I can't speak for the entire community. Here's how I'd like to organize the weapons into types:
Cannon: Cannon, Alloy Cannon, Gauss Cannon, Rail Cannon
Beam: Laser Cannon, Plasma Cannon
Light Rocket: Stingray, Stormlance
Heavy Rocket: Avalanche, Fusion Ball
Electronics: Radar Extension (radar range), Radar Res Processor (radar chance), Targeter (bonus accuracy, bonus damage)
Afterburners: Afterburners (bonus acceleration and speed)
Shield: Graviton Shield (20 armor)
Fuel Tank (bonus fuel)
Thrusters (bonus dodge +10%)
And here's the actual table for various planes:
(https://i.imgur.com/mmixVQv.png)
So some slots have a specified item type, some are unspecified, and some (most) have several specified types.
I see no reason to give an item several types, but well, it wouldn't change anything - but it's unnecessary, since you can control it from the slot end.
If this grow up. Here have a big big big game....
-
Quick question: Is "the gym" just a feature in the base or do you actually have to make something to enable it?
-
Quick question: Is "the gym" just a feature in the base or do you actually have to make something to enable it?
In my vision, it's a building. And the Range is a building too.
Yes, I know, they take up space. So does the Psi-Lab. But you don't have to use either. And maybe they should have more capacity than 10; I think 20 people should be able to fit into a Psi-Lab, judging from the bettlescape map, and the same is realistic for the other two.
-
Solarius Scorch in next version I will add this.
Bloax "the gym" currently work like psi lab. You need create building that have training slots.
-
Bloax "the gym" currently work like psi lab. You need create building that have training slots.
Is this building pre-defined or do you have to mod it in yourself?
(These things would be quite easy to answer if I didn't want to run the game for the first time on camera.)
-
You need make it yourself, example is available on mod portal: https://www.openxcom.com/mod/oxce-mods
Only problems is that mod is incompatible with current OXC and I need update them to new mod format.
-
For now I used all primary ideas for changes. I have still some secondary things like custom ranks or custom training facilities.
But for now I open for request. Criteria are simple keep is simple and do not touch UI or Translations :>
The possibilities of this modification are really awesome.
Since you asked for ideas/suggestions, here are some of my favorites.
1. Make it possible to attack terrain with melee weapons, for example walls. The best would be using the target cursor as for ranged attacks.
2. Allow for two different hit animations for melee weapons dependent on hit or miss. For the sound this is already possible.
3. For special abilities like 'explosion on death' or 'infectious chryssalid attack' define a chance that the special ability takes effect. For example tanks could have a 50% chance of exploding on death.
4. Holded items could modify stats/armor. For example a holded shield could give front armor bonus.
5. Building facilities could consume items from storage. For example building a Gravshield could be possible only if you spend a 'grav module' and 'elerium'.
6. Make it possible to add 32/24 bit images to ufopedia/inventory screen. I know it is not possible for battlescape/geoscape because of shading/lighting problem. However this is not the case for ufopedia/inventory. Even if only ufopedia would accept 32 bit images, modding would be much easier.
-
The possibilities of this modification are really awesome.
Since you asked for ideas/suggestions, here are some of my favorites.
1. Make it possible to attack terrain with melee weapons, for example walls. The best would be using the target cursor as for ranged attacks.
2. Allow for two different hit animations for melee weapons dependent on hit or miss. For the sound this is already possible.
3. For special abilities like 'explosion on death' or 'infectious chryssalid attack' define a chance that the special ability takes effect. For example tanks could have a 50% chance of exploding on death.
4. Holded items could modify stats/armor. For example a holded shield could give front armor bonus.
5. Building facilities could consume items from storage. For example building a Gravshield could be possible only if you spend a 'grav module' and 'elerium'.
6. Make it possible to add 32/24 bit images to ufopedia/inventory screen. I know it is not possible for battlescape/geoscape because of shading/lighting problem. However this is not the case for ufopedia/inventory. Even if only ufopedia would accept 32 bit images, modding would be much easier.
From this list only 4 and 6 don't fit my goals, first require too much code to work properly or it will be too limited to be worth doing it and second is too fundamental to be change by my branch. Rest of list look interesting and easy to do. At some point whey will be added to my branch.
-
It would seem like you have broken the ability to use the blaster launcher, all it does is play the sound and eat up the time units - but not fire the actual missile.
-
I will check out this.
-
Bug fix version based on 2015-05-17 nightly is ready.
Fixed reload button cost.
Baster Luncher rocket don't disappear after first waypoint.
Stun regeneration work properly.
-
Awesome project! It really has opened up a lot of potential.
One bug I have noticed is that accuracyMultiplier does not function at the moment. damageBonus is functioning correctly it seems, but accuracyMultiplier or throwMultiplier will not provide any bonus when given any input. A soldier with a firing accuracy of 70, Psi Skill of 50, and an accuracyMultiplier/throwMultiplier of psiSkill: 1.0 has 70 accuracy.
I've noticed this on 2.0, and it's happening on 2.0A.
-
Code looks fine, test too. Can you show me your .rul? Maybe you made some error there.
-
accuracyMultiplier works correctly, I have tested it pretty extensively by now. Just notice there is an error in the mod description, it reads:
accuracyMultipler
instead of
accuracyMultiplier
(same goes for throwMultiplier etc). If you use the latter, the code works.
Also remember to set firing: 0.0 if you plan to base ranged weapon accuracy on another stat.
-
This is the object I was testing accuracyMultiplier on. I've tried psiSkill, throwing, and flatHundred values, and again on throwMultiplier. I've tried this with both UFO Extender accuracy on and off.
- type: STR_PSI_AMP_PYR
requires:
- STR_PSI_AMP
size: 0.1
costSell: 194700
weight: 10
bigSprite: 92
floorSprite: 32
handSprite: 88
bulletSprite: 7
fireSound: 19
hitSound: 0
hitAnimation: 0
power: 20
damageBonus:
psiStrength: 1.0
damageType: 2
arcingShot: true
accuracySnap: 100
accuracyMultipler:
psiSkill: 1.0
costSnap:
time: 25
morale: 10
stun: 1
snapRange: 200
clipSize: -1
battleType: 1
twoHanded: true
invWidth: 1
invHeight: 3
psiRequired: true
Edit: I copied the wording in the documentation and used Multipler, thanks for catching that. I can't believe I overlooked it so many times. Sorry for not noticing it earlier.
-
Yup, you have it spelled wrongly as Multipler
-
Sorry for confusion. I will fix readme in next version.
-
training rooms were designed as a replication of apocalypse's mechanic. if this is no longer the case, please remove my mod from circulation.
-
training rooms were designed as a replication of apocalypse's mechanic. if this is no longer the case, please remove my mod from circulation.
It's not really my business, but since Yankes hasn't responded yet, can you please specify what is the offensive part? Is it code, or resources, or something else?
The only reason I'm asking is because I'd like to use this feature at some point soon, and would like to know ahead what will happen with it.
-
If I understand Warboy intend if I change code and his mod start behave differently I should stop publishing this mod. If I change code but mod still work as intended then every thing can stay as today. Did I understood this correctly, Warboy?
-
You need make it yourself, example is available on mod portal: https://www.openxcom.com/mod/oxce-mods
Only problems is that mod is incompatible with current OXC and I need update them to new mod format.
Far as I can see the Training Facilities mod works just fine, though it is maybe a bit overpowered.
-
you are, of course, free to do as you please with your build, including the code i gave you. i have no jurisdiction over that, and to suggest otherwise would be absurd. i'm simply saying if the functionality is changing, then the mod no longer represents what i intended, and as such i would like it taken down.
-
I'd suggest leaving Warboy's Apoc-style Training Room functionality intact, and making an alternate functionality apart from it when/if such a thing is needed, in part because I think many people would be interested in Apoc-style training rooms without any extras.
Before saying more on that issue I need to test it in the first place - I have no slightest idea how big the skill increases are, especially since XCom:UFO uses a vastly different timescale compared to Apoc (I wouldn't mind a link to the relevant code!) :)
-
https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training (https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training)
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643 (https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643)
the code is practically verbatim.
-
Thanks, it is really simple to understand. Any tweaking would probably entail:
1. possibility to customize the speed of training (circa +20 on first month all stats on a rookie might be just too much for longer campaign mods);
2. possibility to customize caps maybe (get statTrainingCaps, defaulted to statCaps if undefined) - if a modder wants the peak skills to be accessible only through combat experience. Still, the effectiveness of the training facility is really low once you're close to the maximum.
2. possibility to customize training facilities (any training facility has a list of stats that are trained there, defaulted to all if undefined)
-
https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training (https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training)
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643 (https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643)
the code is practically verbatim.
(Maybe you're already taking this into account in your code) Apocalypse cityscape is "organized" in weeks rather than months. Everything is (or seems, to me) synched to that shorter time-frame, compared to UFO: one day in Apoc is (or seems) a more significant (and, potentially, events plentiful) time span than a day in UFO.
So having training gain rate set the same as Apocalypse's, might be too much for UFO.
It should be tested. I understand though that this is not the priority right now.
-
So I noticed the Training Facilities mod was updated in the OXCE mods pack. Uh, what was changed? Was it just the file structure?
Anyway, I'm no coder and I just play and mod XCOM for fun, but I've been using the Training Facilities with Extended 2.0 and it is quite potent. After about two months soldiers who have stayed in training that whole time are pushing high 50's to 60's strength. Another two months and they've got 60 health, 70 time units, 70/80 accuracy, and 70 strength. Melee and throwing accuracy are getting into 60/70's too. Pretty much everything but bravery and reactions is uber.
Now I've never played apocalypse, but I think some kind of cap on what the training facility does would be appropriate.
Like either providing a fixed, flat increase to each stat or raising all stats to a hard limit. Like you know, in the first option soldiers get 15 time units, 20 energy, 10 health, 10 reactions, 10 accuracy, ect...
Or cap health at 40, strength at 35, reactions at 50 (so that those really low types can be average), and such.
-
Only file structure. Overall I have plans to add more control over stats of training facilities.
-
Only file structure. Overall I have plans to add more control over stats of training facilities.
Well I look forward to it! I used UFO Extender back in the day and was very happy with it. I started using it with Open XCOM mainly because of the AWACS mod and I loved how it combined with the Hyper-Wave Decoder not being 100% reliable.
Having to take a proactive approach to find and attack UFO's makes the game play a lot better than just sitting back passively and waiting for them to fly over you.
-
New bug fix version with update to recent nightly.
Its fix reload bug and some UI issues with crafts.
-
A thousand thanks, Yankes.
-
New version 2.1:
Craft can now have up to 4 different wepon type per slot.
Oprion for overriding shape of alien base.
Option for setting chance of special effect of item.
Moving can trigger all close proxy not only one.
Corpse explosion now can have bonus based on unit stats.
Grenades now can explode at once without destroying each others.
-
Splendid Yankes, great news again.
Now, I have another thing in mind that would be very handy for the Piratez mod (not so much for the vanilla X-Com, but maybe a bit). You see, it's a bit awkward to see 10 "enemies" being civilian passengers running around the ship, so you need to kill/stun them all to win.
The solution I propose is something I call "surrender mechanics". It is simple: whenever all remaining enemies are panicked, you win the battle automatically (just like when they're all mind-controlled).
---===---
And one more, completely unrelated, thing. In the Xcomutil, there was a "fix" for how the clips are recovered: for every clip there was a percentage chance of how likely it is to be recovered based on how much of it was depleted - so a full clip was always recovered, an empty clip was always recovered, a half-empty clip had 50% chance of being recovered, and a 10% full clip had 10% chance for being recovered, and so on. I really liked that system, since in the current one you hesitate whether to fire your special weapon (which you only have one of) because you know that even if you only fire one bullet, the entire clip will be wasted. Which is not very much fun. So I thought if we could, eh, have it the Xcomutil way. :)
-
haha! That's an interesting idea. I just suggested reducing the size of some clips to alleviate the problem of "fire once, lose whole clip" in Piratez. That would be an alternative that's interesting. With OpenXCom counting bullets, it is much less of an issue for your main guns, but it is still really annoying for those guns you only carry 1-2 of and only fire 1-2 times.
Maybe it could be: Count bullets, get remainder of Bullets/Clipsize, give an additional clip back remainder/Clipsize*100% of the time? That's an easy step to add at the end of the current bullet counting instead of entirely replacing it. (One day I'll learn to code in C++! If only for these super easy things!)
That way if you fire 25% of the shots from two clips, you get one back for sure, with a 50% chance of the other. It is slightly different than 75% of keeping each (which gives you 56% of keeping both, 38% of keeping one, 6% of losing both). The results average up the same (average amount lost being either 0.5, or 0.38+2*0.6=0.5). It just makes the odds a bit more reliable (you know you keep one, you are more likely to lose one, and you won't lose two). Of course, if you only have one clip then it's exactly the same :P
-
I think that Arthanor way is better. Only last half empty clip will be recover with random chance. Only thing I dislike in that that you could have miracle and use two bullet clip for 4 shoots in 4 battles. Or have 100 bullet clip and lost it after only one shoot. This more psychical problems than gameplay problem because in long run clip usage will be average.
Simple current system with fixed clip size will always create glitch with weapon that have limited ammo.
How about system where we count bullets not clips?
-
I think that Arthanor way is better. Only last half empty clip will be recover with random chance. Only thing I dislike in that that you could have miracle and use two bullet clip for 4 shoots in 4 battles. Or have 100 bullet clip and lost it after only one shoot. This more psychical problems than gameplay problem because in long run clip usage will be average.
Yeah, neither system is perfect. With this, we could at least escape the "fire once, lose everything" problem, but I don't know if it's best.
How about system where we count bullets not clips?
What happens with the "loose" bullets? You get one semi-full clip?
-
I thought I had read that OpenXCom already counts bullets. I think it does something like this after the battle:
1- Count all bullets left in all clips of a given type, call that n1
2- Divide n1 by the capacity of the clip, call that n2
3- Round n2 down to the lower integer, call that n3
4- Give back n3 clips to the geoscape.
An example of this would be having 4 heavy plasma clips and you fired 28 shots. At the end of the battle you have n1 = 112 shots left (4*35-28). Divide 112 by 35, n2 = 3.2, so you are given back n3 = 3 heavy plasma clips back (ignoring whatever was recovered and any extra you brought). That's 3*35 = 105 shots. The remaining 7 shots are lost since we only track full clips. You didn't lost all your clips, but you lost something.
Unfortunately, this method does not help if you used only one clip of a given kind and the enemy has none (a situation that happens relatively often with special weapons in mods like Piratez or the FMP). In that case, n2 is always smaller than one, so n3 is always 0, so firing one single shot always takes away your whole magazine.
Over time, you lose out on a ridiculous number of shots, way, way more than you fired. For that reason, I tend to limit my use of special weapons (ex.: my 2 flamethrower soldiers use exactly 1 tank's worth of shots between them if possible, certainly never more. So I lose 1 tank/battle. If they fired a tiny bit more, I'd lose 2. If they fire less than a full tank's worth, some shots are wasted and I lost a tank any ways).
My suggestion is to add a "step 3.5", which would be:
3.5- Take n4 = n2-n3. Pick a number between 0 and 1. If that number is smaller than n4, add one to n3.
In the above example, n4 = n2-n3 = 0.2. So you would have a 20% chance to get an extra clip back. At first, this sounds like 20% chance of cheating (you fired all those shots for free!), but it is only "compensation" for all those extra shots you lose when you roll above n4.
This solution will never have a miracle (it is always at most 1 clip away from the exact answer) and works well if you had only one clip and only fired a few shots. Most of the time you fired for free, but once in a while you lose the whole clip, meaning that on average you lose exactly the number of shots you should.
-
I mean different counting, you don't store clips but bullets. You use one bullet, you have 1 bullet less in base.
-
How would you load a gun then? Loading crafts with 56 bullets for weapon A, 34 for weapon B, 512 for your 6 weapon Cs would be tedious too.
I think the method I described above converges to the same answer as tracking bullets over time, but at the same time keeps the logistics at the clip level. Applying the % to every clip would too, but then you have more deviation per battle instead of being at most 1 clip away from the answer each battle.
-
How would you load a gun then? Loading crafts with 56 bullets for weapon A, 34 for weapon B, 512 for your 6 weapon Cs would be tedious too.
Simple. After the battle do this:
1) Count the bullets of the same clips and create a sum etc the 30 bullets per rifle clip, lets say we have 4 clips in the craft inventory so that would be 120 bullets.
This will be counted weanever a clip enters the stores or craft inventory and stored somewhere in the memory of the game (not a programmer here).
2) After the battle the game would count bullets remaining and assing them to clips according to their storage. Lets say we used 50 bullets. We had a tottal of 120 pre battle, that means 120-50 =70 bullets. 70 Bullets mean 2 and 1/3rd clip.
3)So in other words we have two clips remaining.
"Oh and whats the difference oh mighty smartass Pilot00 from the system we use now?" Simple. We used those 50 bullets from all the clips we had on hand, and got two full clips back. If we used the vanilla system we wouldnt get anything back. Think of it the way they do clip refills in the army, they gather the bullets remaining and repackage them. So you dont have magically missing clips or magically appearing clips (with % values).
"And what will happen to the 1/3rd clip remaining Pilot00?Wont this magically be lost?"
Well we can remove the random factor by making it as such: 1/3rd of the clip remaining = lost clip.
2/3rds remaining = full clip.
After all in most modern rifles the first few rounds (in peace time at least) are just the casing (I Dont know the english word).
"But its not peace smartass". I know we can all pretend those "wasted bullets" are the trajectory rounds each mag has in.
Ok I am done arguing with myself. Confused you enough?
IDK If its possible from a code perspective.
-
Right now its vague idea, I didn't check code to see what is possible and simplest to do.
Point is simple, outside battle item is 1 bullets. You load craft using e.g. 100 bullets. When battle begins all bullets are split to clips. If you lack bullets to fill clip, last one will be partial empty.
In battle you shoot 58 bullets. After battle left over bullets (in our case 42) are count up and return to base.
In that system only way to louse bullet is shoot it or drop clip behind.
-
@pilot: As I described earlier, I am pretty sure that OpenXCom already has a system that does pretty much exactly what you describe, except it rounds everything down (so in your example, 2/3 of a clip is also 0 clip). It does it by counting bullets, but you never have to manage bullets.
The issue with your rounding, is if I have, say, a HMG and only ever fire 1/3 of bullets, then that mag lasts forever. You can't do systematic rounding as that creates bias. Either the OpenXCom way (rounding down) which loses you clips, or other ways (yours is ~fair but exploitable; always rounding up would be abusive). That's why I was suggesting bullet counting for clips, with the last # of bullets/clip size determining the odds of getting an extra clip. This way you get back the right number ±1, but it isn't biased.
@Yankes: I still think loading a craft with 512 bullets for your 6 guns is tedious, even if there would be no impact in battlescape. If you don't want half-empty clips, you have to be like: So I have 6 rifles, I want an extra clip per soldiers, each take 35 bullets. How many bullets is that? (12*35 = ..? *Pulls out calculator*) It's math I can do, or anyone past primary school can. But it's not math I would want to do routinely for a game (and I'd rather lose clips than do it ;)).
Maybe the game could track bullets, but only display full clips both in the base and in geoscape? So when you get in the craft equip/buy/sell screens, the game knows you have 600 bullets, so it tells you that you have 20 clips of 30 bullets. Coming back, you have 560 bullets, it tells you that you have 18 clips (18*30 = 540). Go on another mission and spend 35 bullets, you now have 525 bullets and it displays 17 clips. Buy 3 more clips, and 90 bullets and you have 615 bullets, displayed as 20 clips. That requires a lot of converting on the fly though.. so probably a lot of code change.
-
I could be possible. But you will loose information about not full clips. Each solution have some drawback.
-
All three of us actually say the same thing with different words and a small dissagreement on the % of the bullets gained or lost, so we are all correct :D
-
And what about the surrender mechanic? Because it was kind of my main request of the two. :)
-
That one's a good idea and we all agree on it. Boring! :P
I'll have to take a dig at the debrieff state to implement something bullet wise. It seems like an easy project to start coding in c++ with since it's such a simple modification.
-
I'll have to take a dig at the debrieff state to implement something bullet wise. It seems like an easy project to start coding in c++ with since it's such a simple modification.
What would you like to be listed?
Because I would like to every gained item be listed (not just alloys, elerium and unresearched artefacts).
-
And what about the surrender mechanic? Because it was kind of my main request of the two. :)
Autowinning/capturing 5+ ( I had streaks of more) aliens because they panicked, seems a bit counter intuitive. Especially on the large and convulted maps that you cant reach them in time and can (theoritically) grab their guns back and regroup.
Now if you can add a computation to compare numbers, such as 2 to 1 or 3 to 1 ratios (x-com vs alien) then maybe. Then again the aliens from a lore stand point wont be the surrendering types...
-
I think the surrendering mechanic was suggested more for Piratez, where the civilian crews (ex.: GOs, hostesses and engineers) might surrender to avoid getting killed. The more fighty types probably have good enough bravery that they'd hold on and not panic, meaning the crew wouldn't surrender any ways.
@Solarius: I wasn't actually going to change the listing. Listing everything might be too much. Maybe something like: Weapons, ammunitions, grenades and equipment categories, where individual weapons are lumped together. Then anything fancier (Alien food and such) listed individually? I don't know how to do that though.
I was just going to look at the clip computations, which are in the debrief state as well. I have noticed that it affects my gameplay in a way I don't like (I try not to shoot special weapons, which defeats the coolness of having them; or if I shoot it once, then I might as well empty the clip, which also feels stupid) so it would be good to fix it.
I found where the game calculates the returns. It gets the # of shots/clip size, rounded down, and gives that many clips back to you (so if you use multiples of the same weapons, it mostly works: You only lose a number of clips that total the number of shots fired + 1 extra if it's not exact).
It should be within my means to add a line or two that takes however many shots remain after filling clips and divides by clipsize. Roll a number between 0-1, if it is lower than (shots left/clipsize), you get an extra clip. That way you can use your special weapons and will only lose the clip once in a while, in a way that should average out to spending exactly the right amount of shots.
-
I think the surrendering mechanic was suggested more for Piratez, where the civilian crews (ex.: GOs, hostesses and engineers) might surrender to avoid getting killed. The more fighty types probably have good enough bravery that they'd hold on and not panic, meaning the crew wouldn't surrender any ways.
Yeah, it was mostly about Piratez, but seeing as vanilla aliens are way less likely to panic en masse I don't think it would have much of an impact on the game anyway.
@Solarius: I wasn't actually going to change the listing. Listing everything might be too much. Maybe something like: Weapons, ammunitions, grenades and equipment categories, where individual weapons are lumped together. Then anything fancier (Alien food and such) listed individually? I don't know how to do that though.
In vanilla, there's not that much stuff to recover, it's mostly something like:
Plasma Pistol: 1
Plasma Rifle: 5
Heavy Plasma: 2
Alien Grenade: 5
Mind Probe: 1
Maybe a bit more with really big UFOs, but nothing overwhelming.
For Piratez it would be more, but it's also more vital information.
-
The issue is that it would list all of your gear that it recovered too:
Rocket Launcher: 2
Large Rockets: 2
Laser Pistols: 2
Laser Rifles: 8
Heavy Laser: 4
Plasma Pistol: 1
Plasma Pistol clip: 1
Plasma Rifle: 5
Plasma Rifle clip: 12
Heavy Plasma: 2
Heavy Plasma clip: 3
Alien Grenade: 5
MediKits: 8
Grenades: 4
Electro-flares: 18
Smoke grenades: 5
Mind Probe: 1
[...]
which quickly grows into a list that's so long it's useless. If you subtract what you brought, you would get:
Pistol clip: -2
Rifle clip: -4
Large rockets: -3
or something, which is interesting in its own right, to know what you need to replace, but you already get that message when it fails to refill the craft. And you don't really need to keep track of used equipment every mission provided it is there to be replenished. Unless there is an "owner" flag to items, which identifies if it was brought in by aliens or XCom.. But even then, if I bring 10 heavy plasma clips, spend 5 and recover 8 from the aliens, what should it display? Recovered 8 or recovered 3?
It's a good idea, but implementing it in a way that's informative but not cluttered is difficult.
-
Good point. But I don't think we need an "owner" flag, as long as the game remembers what you brought and subtracts one list from the other - a bit like you described, just without displaying the negative values.
-
But saying nothing about negative values is kind of misleading. Substract what you brought and not display zeros could work.. I don't know.. and it is certainly beyond my abilities any ways.
-
But saying nothing about negative values is kind of misleading. Substract what you brought and not display zeros could work.. I don't know.. and it is certainly beyond my abilities any ways.
Worry not, you're still better than me. :) It's more about design than coding right now.
-
I think the surrendering mechanic was suggested more for Piratez, where the civilian crews (ex.: GOs, hostesses and engineers) might surrender to avoid getting killed. The more fighty types probably have good enough bravery that they'd hold on and not panic, meaning the crew wouldn't surrender any ways.
I think I could add option for race that can surrender when panicked.
-
I think I could add option for race that can surrender when panicked.
Yeah that would be better to work as an optional as in Psi capture.
-
Adding a boolean "surrenders" line is fine too. Probably best, even though it'll be a pain to add it everywhere. :)
-
New bugfix version (with recent nightly) ready.
I fixed two bug with berserker, first one that prevent unit form shooting and second that allow use of not researched weapons while berserkerking.
-
I should probably start a campaign on this, now that my Piratez is not working. This mod is compatible with the FMP right?
-
I should probably start a campaign on this, now that my Piratez is not working. This mod is compatible with the FMP right?
It definitely should be, but the FMP doesn't use the options that OXCE enables. Yet.
So the experience should be the same as vanilla exe really.
-
It definitely should be, but the FMP doesn't use the options that OXCE enables. Yet.
So the experience should be the same as vanilla exe really.
Eh...Drat, back to the drawing bord then... :(
-
It definitely should be, but the FMP doesn't use the options that OXCE enables. Yet.
So the experience should be the same as vanilla exe really.
When a versión compatible.
Enviado desde mi ECOO E04 3GB mediante Tapatalk
-
Just a HUGE thanks for this exe-mod! It is incredible what you made here, the training facilities and the ability to self-heal (medi-pack) and all the other things, this is heaven for us modders! :) I really like the facilties-requirement-thing, it makes chosing different equipment pathes possible ingame, build a laser-lab for laser weapons and a gauss-lab for gauss etc... wow!
fwiw, the readme needs an update (the part about regen when use for items is still in it)
-
Just a HUGE thanks for this exe-mod! It is incredible what you made here, the training facilities and the ability to self-heal (medi-pack) and all the other things, this is heaven for us modders! :) I really like the facilties-requirement-thing, it makes chosing different equipment pathes possible ingame, build a laser-lab for laser weapons and a gauss-lab for gauss etc... wow!
fwiw, the readme needs an update (the part about regen when use for items is still in it)
could you be more precise what line in readme need fixing?
-
What I meant is the fact that you dropped the support/feature of regenerating armor stats per turn, but the entries still appear in the armor section of your readme. :)
Sorry for the late answer, was busy actually playing OpenXcom with your awesome Exe! ;D
-
I drop support for old version. In place of it I added new one with different behavior (in "recovery" node). Hence I added warning about it.
Maybe I need rephrase it to be more clearly.
-
The old "Regeneration" feature is completely useless compared to the new "Recovery" which allows you full control over the recovery of stamina, health, morale, whatever, basing it on whatever formula you want, in any combination.
-
The old "Regeneration" feature is completely useless compared to the new "Recovery" which allows you full control over the recovery of stamina, health, morale, whatever, basing it on whatever formula you want, in any combination.
Gee, thanks, Dioxine amd Yankes, will test the new feature right away! And sorry for having been confused :)
-
Hey Yankes. I've been having a discussion in the PirateZ extended thread about Spy Glasses.
This would be a nerfed mind probe giving Race and Rank only.
However, I've come to realize that it wouldn't be possible unless the Mind Probe values could be externalized. Meaning, a "probe" type item could give varying degrees of information according to how it would be defined in the ruleset.
Is that something that you would consider adding to your build?
-
Seems too much effort for (very) questionable benefit to me...
Maybe just display the race (and possibly rank, although I don't like that at all, also not in FMP... you shouldn't know what rank which individual is!) as text somewhere near the alien (resp. piratez human/hybrid) when holding a certain hotkey, or toggle.
Nah... after writing this, it's still a stupid idea... the sprites should really be enough to recognize the race... but that's just my opinion.
-
The idea being exactly that: Help people learn what the sprites are to allow them to recignize the units later. It's a tool to help on a first playthrough. But I think it is possible to come with a LoS required and high enough TU mind probe where giving away stats isn't that big of a deal any ways. It's not like people heavily abuse mind probes in vanilla...
Another feature request for you Yankes:
1- The ability to define multiple inventory layouts (ie the "boxes" in which you put items). Currently you can modify that through ruleset, but there is still only one layout for all.
2- The ability to link different layouts to different armors. This way you could have a mule outfit with a huge backpack, a ninja outfit with barely any storage, a pirate outfit with a 3 tiles scabbard for a sword, etc.
-
I probably give some love to mind probe because I didn't change it at all in my Extended version.
And for custom inventory, this would be problematic because lot of code depends on/use this (like AI, inventory templates, equipping units).
This would require more work that is worth.
I thinking about resurrecting my old branch: https://openxcom.org/forum/index.php/topic,2059.0.html
This could give couple of things:
1) Recolor of corpses and bigobj for unit.
2) Simple unit animations and fully customizable recoloring.
3) Large access to game logic by mods in long run.
Do you are interesting in that functionality? This would require some work but at least most of hardest thing are done in that branch.
But if nobody would use it, it would better if I spend my time on more useful things.
-
And for custom inventory, this would be problematic because lot of code depends on/use this (like AI, inventory templates, equipping units).
This would require more work that is worth.
If you keep the customization to player armor that would leave the AI alone. It's not like they really use the inventory much so tweaking it would be weird. As for templates and default equipment, save which inventory layout is used: if it's different, equip nothing. It's the player's responsability to re-equip a soldier if they change armors (which they probably would any ways, since armors tends to define roles).
I thinking about resurrecting my old branch: https://openxcom.org/forum/index.php/topic,2059.0.html
This could give couple of things:
1) Recolor of corpses and bigobj for unit.
2) Simple unit animations and fully customizable recoloring.
3) Large access to game logic by mods in long run.
Do you are interesting in that functionality? This would require some work but at least most of hardest thing are done in that branch.
But if nobody would use it, it would better if I spend my time on more useful things.
#1 and 2 are beyond me, #3 sounds like a very interesting thing, depending on what actually can be tweaked. It could potentially turn OpenXCom into a game engine instead of a game.
-
And for custom inventory, this would be problematic because lot of code depends on/use this (like AI, inventory templates, equipping units).
This would require more work that is worth.
I think it can be done much simpler. Allow for custom-placement of fixed weapons? (built-in weapons). That way a modder can simply block some of the inventory space with blanks or whatever. He'd just make the biggest as the default and block off excess space everywhere else.
-
Good morning:
I hope not mistaken, and post in the right place:
I have some doubt about the use of some of the instructions OpenXcom Extended. Can not get to work, or have the effect, I think they have to produce, in my mods.
For example:
craftWeapons:
- Type: STR_CRAFTWEAPON_TYPE #default config ...
weaponType: 1 #default value 0.
stats: #added to craft's stats.
FuelMax: 0 #additive bonus stats to craft.
damageMax: 0 #additive bonus stats to craft.
Speedmax: 0 #additive bonus stats to craft.
accel: 0 #additive bonus stats to craft.
Radarrange: 0 #additive bonus stats to craft.
radarChance: 0 #additive bonus stats to craft.
sightRange: 0 #additive bonus stats to craft.
hitBonus: 0 #bonus percentage chance to hit all weapons. Range [0, 100].
avoidBonus: 0 #bonus percentage to craft dodge chance. Range [0, 100].
powerBonus: 0 percentage #bonus damage to all weapons. Range [0, 100].
armor: 0 #amount of blocked damage per hit
I managed to run, the armor, but the rest of statistics, I can not make you join the ship, where the weapons are.
Nor have I accomplished, I go this:
facilities:
- Type: STR_SOME_FACILITY
provideBaseFunc: [A] #List of custom IDs That Provide for bulding esta base.
requiresBaseFunc: [] That #List of custom IDs are require to build esta building in base.
manufacture:
- Type: STR_SOME_MANUFACTURE
requiresBaseFunc: [A, C]
Finally, is there any way that taking over an object, you add health, energy, etc., and then to leave, statistics soldier, returning to its previous state?
If anyone can make, a simple list, especially of the first issues to understand how they work, very grateful in advance. Sorry for the length of my question.
-
3) Large access to game logic by mods in long run.
I hope this means what I think it means.
And I think about the teleport device from UNIMOD.
What is UNIMOD? It's a big-ass mod for UFO: Extraterrestials. It added much, much stuff and made the game actually enjoyable, and ambitious.
What is a teleport device? It's a rare alien artifact added in UNIMOD that worked via throwing. When thrown, it disappeared on impact, and the user was teleported to the same location (with teleport in hand again). It was surprisingly non-cheaty, too.
Now, to implement it in Openxcom, one would have to write a script that would be then linked to a grenade, instead of doing damage. But it seems to be a bit too far-fetched for OXCE... Or am I wrong? ;)
-
@Alinare
I have tested all these functions and they work flawlessly (well, extra fuel has trouble with non-standard fuel). Can you paste your code here? Else there is no telling what's wrong.
-
I hope this means what I think it means.
And I think about the teleport device from UNIMOD.
What is UNIMOD? It's a big-ass mod for UFO: Extraterrestials. It added much, much stuff and made the game actually enjoyable, and ambitious.
What is a teleport device? It's a rare alien artifact added in UNIMOD that worked via throwing. When thrown, it disappeared on impact, and the user was teleported to the same location (with teleport in hand again). It was surprisingly non-cheaty, too.
Now, to implement it in Openxcom, one would have to write a script that would be then linked to a grenade, instead of doing damage. But it seems to be a bit too far-fetched for OXCE... Or am I wrong? ;)
Yes, that could be possible :> but probably not on first batch. It will take some time to expose all internals of OXC to script engine.
I think it can be done much simpler. Allow for custom-placement of fixed weapons? (built-in weapons). That way a modder can simply block some of the inventory space with blanks or whatever. He'd just make the biggest as the default and block off excess space everywhere else.
I think if we stick only to disabling then prober way to do it is add option to armor than using hacks. This have one good property that even if I f*** up game will still run fine only with some glitch. It would be possible to change this property without breaking saves.
Arthanor if you think that option in armor for disabling whole inventory part like backpack or belt then I can do it.
@alinare
Could you say exactly what you want to achieve? And as Dioxine said without your ruleset file I can't help you because I don't know what did wrong.
Overall to use properly Extended version you need understood how basic OpenXcom ruleset works without it is impossible even to understood Extended documentation.
-
Hi:
Thank you for answering me so soon. I copied some of my mods listed. I do not get to apply these instructions, either, am I, who do not understand how they work. Here I refer you some examples. Sorry for the extension.
facilities:
- Type: STR_NUCLEAR_DEFENSES
provideBaseFunc:
- STR_LIVING_ROOMS
spriteShape: 3
spriteFacility: 300
buildCost: 500000
Buildtime: 30
monthlyCost: 50000
personnel: 50
workshops: 100
defense: 800
HitRatio: 60
fireSound 5
hitSound 10
mapName: XBASS_21
ufopaedia:
- Id: STR_NUCLEAR_DEFENSES
type_id: 6
section: STR_BASE_FACILITIES
text: STR_NUCLEAR_DEFENSES_UFOPEDIA
listOrder: 6990
extraStrings:
- Type: en-US
strings:
STR_NUCLEAR_DEFENSES: "Nuclear Missile Defenses"
STR_NUCLEAR_DEFENSES_UFOPEDIA: "Nuclear missiles, have maintained a tense peace During the recent and long Decades of the Cold War Between the two superpowers Nuclear deterrence prevented us the world again embroiled in another devastating world war, This Time, It Would Have Been With the nuclear.. exception of World War II, nuclear weapons Have never been tested in battle, and less against goals came from outer space, so do not know how They will behave. Each silo has a provision of ten missiles Renewed That will be as soon as will be fired. "
extraSprites:
- Type: BASEBITS.PCK
files:
300: Resources / Mod / Facilities / Basebits / Nuclear_Defenses.png
Hello. This example, a nuclear installation defenses. So I thought understand the ProvideBaseFunc: it is a prerequisite for building the facility, but I can not apply.
Another example of a component:
items:
- Type: Retropropulsor
size: 0.1
costSell: 10000
research:
- Name: Retropropulsor
requiresBaseFunc:
- STR_QUANTUM_LABORATORY
cost: 5000
points: 50
dependencies:
- STR_ELERIUM_115
- STR_PARTICLE_MICROACCELERATION
- STR_ANTIMATTER_CONTAINMENT
- STR_ALIEN_POWER_SYSTEMS
- STR_ALIEN_GRAVITY_GENERATOR
- STR_SECTOID_NAVIGATOR
- STR_SECTOID_ENGINEER
- STR_EXALT_MEDIC
- STR_ALIEN_ALLOYS
- Data Disc
- Ragnite
- Miniaturization
manufacture:
- Name: Retropropulsor
requiresBaseFunc:
- STR_NUCLEAR_DEFENSES
category: STR_EQUIPMENT
requires:
- Retropropulsor
space: 20
time: 150
cost: 8000
requiredItems:
STR_ELERIUM_115 5
Ragnite 12
STR_ALIEN_ALLOYS 10
ufopaedia:
- Id: Retropropulsor
type_id 7
section: STR_WEAPONS_AND_EQUIPMENT
requires:
- Retropropulsor
image_id: UP220.SPK
text: The retropulsor That is a drive unit runs on a mixture of ragnite and elerium-115, developing a huge new lift, capable of lifting the heaviest loads force.
text_width: 143
If I have not misunderstood - in manufacturing-that line, what it does is, you have to build a deteminada easily, or produce something concrete, so that the object is made.
As for the weapons of the ships, another example:
craftWeapons:
- Type: EXOCET
stats:
damageMax: 0
sprite: 1
sound: 5
damage: 200
range: 70
accuracy: 95
reloadCautious: 4
reloadStandard 10
reloadAggressive: 16
ammoMax: 1
rearmRate: 1
launcher: EXOCET LAUNCHER
clip: EXOCET MISSILES
projectileType: 1
projectileSpeed 5
items:
- Type: EXOCET LAUNCHER
size: 1
costBuy: 70000
costSell: 30000
transferTime: 200
weight: 3
bigSprite: 2
- Type: EXOCET MISSILES
size: 0.1
costBuy: 80000
costSell: 40000
transferTime: 74
clipSize: 1
ufopaedia:
- Id: EXOCET
type_id: 2
section: STR_XCOM_CRAFT_ARMAMENT
image_id: UP087.SPK
text: This is a weapon of the type "fire and forget" that Makes its way to the target near the crest of the waves, About 10 m. When approaching the target, it May drop to 3 m, in contrast, rise Rapidly to avoid the missile systems and precipitate on the target.
target.
In this case, the maximum damage of the missile, not add me to the other weapons of the ship. The same happens with the speed, and other statistics.
And, and I abused your patience, I ask another question, if possible:
armors:
- Type: HEROIC KNIGHT ARMOR
spritesheet: XCOM_B.PCK
spriteInv: MAN_B
corpseItem: STR_CORPSE_HEROIC KNIGHT ARMOR
storeItem: HEROIC KNIGHT ARMOR
weight: 25
stats:
stamina: 30
reactions 10
firing: 15
bravery 10
health: 10
strength: 5
firing accuracy: 6
recovery:
health: 12
frontArmor: 120
sideArmor: 90
rearArmor: 90
underarmor: 70
damageModifier:
- 1.0
- 1.0
- 0.0
- 1.0
- 1.0
- 1.0
- 1.0
- 1.0
- 0.6
- 0.0
loftempsSet: [3]
recovery:
health: 30
When I write, the option to recover 30 health every turn, openxcom disables the mod, and if I try to change, no effect.
I fail to understand that meaning, or function, have the letters in the brackets, or are lists of requirements:
requiresBaseFunc: [W, K]
provideBaseFunc [A, C]
I hope I explained well. I am Spanish, and my English, still leaves much to be desired. :)
Congratulations on this wonderful project. The other functions do not know as you call, they go perfectly. I understand for example, as will the tuaimed: cost and can lead, in time, health and other issues.
Greetings, and thanks again.
-
I think if we stick only to disabling then prober way to do it is add option to armor than using hacks. This have one good property that even if I f*** up game will still run fine only with some glitch. It would be possible to change this property without breaking saves.
Arthanor if you think that option in armor for disabling whole inventory part like backpack or belt then I can do it.
The ability to define where fixed weapons go would be awesome. It would allow equipment to start in hands where it can be used instead of in belt/backpack for HWPs, and to block off certain slots for certain armors. Just have to mod the basic inventory to have every possible slot and block them as needed. Works for me :D
-
"provideBaseFunc" - this is list of functionality that facility give to base, say for example "A". This can be any text.
facilities:
- Type: STR_NUCLEAR_DEFENSES
provideBaseFunc: [A, ThisCanBeAnyText ]
"requiresBaseFunc" - this is what is require in base to use.
facilities:
- Type: STR_NUCLEAR_DEFENSES_MK2
requiresBaseFunc: [ A ] #this will case that better version of nuclear defenses can only build if you have at least one normal version that provide base function "A".
for craft weapons. "damageMax" mean HP of craft not weapon damage. Over all all "stats" in craft weapon are copy of craft rules.
If you want that weapon boos damage you should use "powerBonus".
Lastly recovery have different syntax:
armors:
- Type: HEROIC KNIGHT ARMOR
recovery:
health:
flatOne: 30 #this give +30 hp per turn
bravery: 0.5 #this give hp bonus equal half of unit bravery
if unit have 60 bravery then it will regen (30 + 60 * 0.5) = 60 hp per turn.
Maybe I should add simpler syntax that you try use as alternative to current one.
-
Maybe I should add simpler syntax that you try use as alternative to current one.
Nooo! If you add a simpler syntax I won't be able to understand it! :)
-
https://www.openxcom.com/mod/openxcom-extended
It is working now, sorry for the inconvenience. All is good now :)
-
thanks for fixing this :)
-
Thank you so much. All works perfectly. Great job. :)
-
New version 2.2:
Option for custom sound and animation for miss attack and psi weapons.
S*** I hit message length limit in first post :/ I need think how best handle this now.
-
Awesome! 8)
One minor thing though:
I could not get the recovery thing to work, the game exe complained about an operator working on a scalar or something.
My setup looked like this:
armors:
...
-STR_JustSomething_quick
-recovery:
health: 10.0
...
Sorry I do not have the full text I typed this from memory... :P
-
You're missing one step here. You have specified the recovery rate, but not what you want to be recovered. The code should look like this:
recovery:
stun:
health: 0.1
stamina:
health: 0.1
It means, line by line:
- Recovery procedure initiation
- I want Stun to be recovered each turn.
- The rate should be 10% of soldier's Health stat.
- I also want Stamina to be recovered.
- At the same rate.
If you want a fixed rate of ten, you can use:
flatHundred: 0.1 (instead of Health)
-
Oh, ok, now I see! Many thanks for the explanation. :)
edit one day later: Ooooooh it works! Now my Universal Soldiers can automatically heal ;D ;D
Again: Many thanks for this exe, it is just awesome!
-
Btw, now after seeing and liking the new training facilities: What about Med-Bays? :)
Warboy released (some years ago) an OpenXcom version that had those (along with armed police-civilians). Just halving the required time to heal a unit would be awesome, it doesn't need to be an instantaneous recovery.
Apart from that: I just realized that your exe replaced the original openxcom exe releases for me. I no longer check the nightlies, only your mod. :)
-
right now I don't have any plans to do medbays.
-
Seems the retaliation against melee attacks got disabled in OXCom somewhere along the way (ie melee attacks do not provoke opportunity fire anymore). Is it posible to re-enable it?
-
Probably yes, Warboy comment it out and I can simply revert it. But question is how manage it. Made it always enable/Global toggle/Per weapon toggle?
-
In my opinion it makes no sense when melee attacks can't be retaliated against, so I'd re-enable it across the board. I can't imagine anyone not wanting this... but then again, maybe someone would? It feels like a cheat.
-
Why was it changed? I think I remember stun rods not triggering reactions in UFO (miss, miss, step aside and die was pretty common..) Did melee not trigger reaction in TftD either? Can't remember that one..
If it didn't in TftD, that would be a case of "staying true to the original" (however unrealistic), and maybe global toggle would be warranted. I can't really think of a situation where weapon toggle really makes sense.
-
New Version 2.3:
Option for defining percent of all action cost stats. Old use of `flatPrime` and `flatThrow` is deprecated.
Facilities can now require items to build.
Medikit can now be used without UI and can use `hitSound`.
Today version is sponsored by `sed` command scripts that allow remove multiple lines from text file.
Next version will probably have:
- melee reaction
- fixed weapon visible
- optional research items
After that I have possible plans:
- melee tile attack
- scripts
- flash lights of guns muzzle and explosions
- ammo for all items
- 1 bullet handling
-
I don't know if it's has been fixed already, using 2.2A. Double detonations.
- Sometimes, explosives detonate twice, causing double damage
- Would it be possible to define the number of detonations for an explosive (item-per-item basis)?
-
Making "chain" detonation isn't hard, current game allow queue different explosions, repeating one is not hard.
But what about with that unintended "chain" explosions, can you reproduce it? Or in what circumstance it happened?
Remember that in my version one explosion can't stop another e.g. all proxy can explode when you step on two.
-
Just throw any grenade & end turn, an unintended double detonation is almost certain to happen. I will send you a save.
EDIT: Actually sending a save is pointless, it happens all the time with Piratez. Might be an unexpected side effect of my grenades having 250 armor (ie. being indestructible by their own power).
-
Impossible, if explosion was needed to remove grenade then whole game would loop because second one could not do it either.
I mess up logics some were. Armor only expose this bug.
-
Bug fix version is ready. I add recent commits form master branch, this mean I could add new bugs to it :D
-
The craft weapon screen is somehow buggy and weird now, it is off-center and the weapon names are not where they should be.
Talking about new bugs, the nightly also introduced an off-center mission abort screen text, whixch is now included in your exe. I reported the bug over the wiki.
And thanks for fixing the double explosion thing.
fwiw: melee reaction attacks already work, I saw that in a recent game, was VERY surprised.
-
craft bug caused by:
Bug fix version is ready. I add recent commits form master branch, this mean I could add new bugs to it :D
And for reaction, I didn't touch it jet. Probably another miss merge.
-
I played around with this a bit (ver 2.3a + latest nightly).
Potentially useless feedback (because issues might be my fault):
-- I'm getting only "OpenXcom 1.0" in the main menu screen;
-- Shoot down a custom UFO and it spawned a never-ending wave of retaliation UFOs, even though the specific alien race had "retaliation: false";
-- Terror UFOs keep roaming around but no terror site ever happens.**
Also I can't say if any of this is imputable to OXC, rather than Extended. Was just a quick lazy testing.
** this was my fault.
-
"retaliation: false" only work like basic version. To get no retaliation after shooting down ufo you should use "retaliationAggression: -100".
-
Another thing I noticed is that, when something explodes, the colors get "inverted" for a fraction of a second. Like in the image attached (the image is fake, I recreated the effect because I wasn't able to screenshot it, it's too brief).
Don't know if it is exclusive to the Extended version or not.
-
This should be explosion flash form TFTD, probably another miss merge from my side. In weekend I will try fix all this bugs, and maybe add some new features.
-
I assume this is a bug with Extended - it affects X-Piratez, but not the unmodified game:
Explosion hits are not attributed to the soldier that causes them for training and promotion. They do get credited with kills though. Tested with the Piratez black powder bomb ("direct fire" grenade), grenade launcher, and standard (prime + throw) grenade.
From some other comments it might affect incendiaries as well.
Version is whatever git cloned last weekend, so probably pretty current.
-
I apologize if this is a stupid question, but ...
I've read the posts at the beginning of the thread about Extended. What I haven't quite figured out yet ... does Extended change the OXC game experience in and of itself, or does it only allow mods to do different things than vanilla? So, if I install Extended and play it without any other mods, is it noticeably different from OXC? Impressive list of changes in the first post but they seemed mostly to cater to mod authors.
Thanks for any help.
-
Only minimal changes for normal users, 95% of it is for modders.
-
I had a weird thing where both the medi-kits I equipped couldn't be used.
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.
The unit was "on fire" (little flame burning on the unit) when I first got the message while trying to use the medi-kit.
I had used the medi-kits in the 2 previous missions but I really don't think I emptied them both (also normally an empty medi-kit should still work, just having its values at 0).
(Medkit is not the vanilla medkit, but it is 1:1 in ruleset terms, the difference is the main string, which is "STR_MEDIKIT2", all the rest is exactly the same as vanilla medikit).
-
Happened to me, too, but i had forgotten to set the medikittype. :)
Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.
Ah, one thing: Could explosion sounds be made customizable, too. Right now everything from tiny flame greneades over stunbombs to blaster launchers to modded nukes uses the same sound.... :-\
-
Happened to me, too, but i had forgotten to set the medikittype. :)
Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.
Ah, one thing: Could explosion sounds be made customizable, too. Right now everything from tiny flame greneades over stunbombs to blaster launchers to modded nukes uses the same sound.... :-\
I have the medkit type.
I'm using lots of incendiary weaponry and the damage output seems perfect; and I'm also finally seeing units lighting up in flames with consistent frequency. No issues here.
Well, there are actually two default explosion sounds, one for small explosions and one for big ones. The 'power' value should set which one to use. But of course, custom sounds would be welcome.
-
Yes, the power of an explosion currently sets the sound that's being played. If I remember well, 85 is the first value at which you get the big explosion sound instead of the grenade pop.
I made a suggestion for customizable explosion sounds here (https://openxcom.org/forum/index.php/topic,3712.0.html) but nobody paid attention (or it's already in the works since TftD will have to have underwater explosions too?).
Maybe Yankes can make it happen for OXCE though.. It would be nice especially for flamethrower weapons, where the current explosion sounds don't really make sense.
-
I had a weird thing where both the medi-kits I equipped couldn't be used.
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.
I probably made error in "instant" medikits. This string should be shown only when you run out of charges in it, and medikit is "instant".
Happened to me, too, but i had forgotten to set the medikittype. :)
Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.
Ah, one thing: Could explosion sounds be made customizable, too. Right now everything from tiny flame greneades over stunbombs to blaster launchers to modded nukes uses the same sound.... :-\
I do not touch damages types recently. Behavior should not change.
For big explosion sound, can be done. But first I need squash all bugs reported form last version. I will try finish it today or tomorrow.
-
For big explosion sound, can be done. But first I need squash all bugs reported form last version. I will try finish it today or tomorrow.
As Arthanor mentions, TFTD has underwater explosions and so custom explosion sounds could be already in vanilla "to do" list . Maybe you should check with the devs before coding things twice. /methinks
-
MOOOAAAaar feedback.
1)
I noticed that the very first missile in air combat isn't drawn (shot from xcom crafts). This doesn't seem to happen in vanilla OXC.
2)
Got the attached error message.
For the following custom mission (all the ruleset custom stuff involved):
alienMissions:
- type: STR_CORP_WAREHOUSE
points: 0
objective: 2
spawnZone: 4
[...cut...]
alienDeployments:
- type: STR_CORP_WAREHOUSE_ASSAULT
[ ...cut...]
briefing:
textOffset: -16
background: BACK01.SCR
showTarget: false
markerName: STR_CORP_WAREHOUSE
alienRaces:
- id: STR_NEUTEK
retaliation: false
# OXC Extended options:
retaliationAggression: -100
baseCustomDeploy: STR_CORP_WAREHOUSE_ASSAULT
baseCustomMission: STR_CORP_WAREHOUSE_ASSAULT
-
fwiw: melee reaction attacks already work, I saw that in a recent game, was VERY surprised.
melee reacting to range attack yes, range attack reacting to melee no.
I had a weird thing where both the medi-kits I equipped couldn't be used.
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.
The unit was "on fire" (little flame burning on the unit) when I first got the message while trying to use the medi-kit.
I had used the medi-kits in the 2 previous missions but I really don't think I emptied them both (also normally an empty medi-kit should still work, just having its values at 0).
(Medkit is not the vanilla medkit, but it is 1:1 in ruleset terms, the difference is the main string, which is "STR_MEDIKIT2", all the rest is exactly the same as vanilla medikit).
After checking code, error "STR_NO_USES_LEFT" can only appear if you use new instant medikit and you run out uses.Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.
Did you use "RandomType"? this change how damage is roll.
MOOOAAAaar feedback.
1)
I noticed that the very first missile in air combat isn't drawn (shot from xcom crafts). This doesn't seem to happen in vanilla OXC.
2)
Got the attached error message.
For the following custom mission (all the ruleset custom stuff involved):
1) I can't reproduce it. Can you test it with F8 that will slow animations?
2) This is error with globe mission zones.
Another thing I noticed is that, when something explodes, the colors get "inverted" for a fraction of a second. Like in the image attached (the image is fake, I recreated the effect because I wasn't able to screenshot it, it's too brief).
Don't know if it is exclusive to the Extended version or not.
After looking close on big explosion I didn't find any bug. This you saw was indeed TFTD feature. It made all pixels bright for one frame.
I assume this is a bug with Extended - it affects X-Piratez, but not the unmodified game:
Explosion hits are not attributed to the soldier that causes them for training and promotion. They do get credited with kills though. Tested with the Piratez black powder bomb ("direct fire" grenade), grenade launcher, and standard (prime + throw) grenade.
From some other comments it might affect incendiaries as well.
Version is whatever git cloned last weekend, so probably pretty current.
fixed.
Tomorrow I will publish new version with all the fixes.
-
After checking code, error "STR_NO_USES_LEFT" can only appear if you use new instant medikit and you run out uses.Did you use "RandomType"? this change how damage is roll.
I don't even know what the instant medikit is; and never used "RandomType" anywhere ever. I just switched to Extended, and the -literally- only feature I'm using is the one for overriding the alien base construction. This is the medikit in question, it is the exact copy of the vanilla medikit (changes marked with "**"):
- type: STR_MEDI_KIT2
size: 0.1
costBuy: 3500 **
costSell: 2625 **
weight: 5
bigSprite: 464 **
floorSprite: 464 **
handSprite: 464 **
battleType: 6
invWidth: 1
invHeight: 2
painKiller: 10
heal: 10
stimulant: 10
woundRecovery: 1
healthRecovery: 3
stunRecovery: 4
energyRecovery: 10
tuUse: 10
flatRate: true
1) I can't reproduce it. Can you test it with F8 that will slow animations?
See attached images. Taken with slow animations activated. Left launcher has 2 missiles, right has 1. As you can see, none of them gets drawn at all, you can't see anything flying towards the ufo.
So the issue actually is not that the first missile isn't drawn, but that during the very first seconds of air combat *nothing* (the cannon doesn't seem affected though, only missiles. duh, this is so strange) gets drawn.
-- edit: it also seems, to me, that the "invisible" missiles don't do any damage/never hit the ufo.
In the following days I'm going to switch back to vanilla OXC to test on there.
-
I don't even know what the instant medikit is; and never used "RandomType" anywhere ever. I just switched to Extended, and the -literally- only feature I'm using is the one for overriding the alien base construction. This is the medikit in question, it is the exact copy of the vanilla medikit (changes marked with "**"):
- type: STR_MEDI_KIT2
size: 0.1
costBuy: 3500 **
costSell: 2625 **
weight: 5
bigSprite: 464 **
floorSprite: 464 **
handSprite: 464 **
battleType: 6
invWidth: 1
invHeight: 2
painKiller: 10
heal: 10
stimulant: 10
woundRecovery: 1
healthRecovery: 3
stunRecovery: 4
energyRecovery: 10
tuUse: 10
flatRate: true
See attached images. Taken with slow animations activated. Left launcher has 2 missiles, right has 1. As you can see, none of them gets drawn at all, you can't see anything flying towards the ufo.
So the issue actually is not that the first missile isn't drawn, but that during the very first seconds of air combat *nothing* (the cannon doesn't seem affected though, only missiles. duh, this is so strange) gets drawn.
-- edit: it also seems, to me, that the "invisible" missiles don't do any damage/never hit the ufo.
In the following days I'm going to switch back to vanilla OXC to test on there.
"RandomType": you misquote me, that text was for civilian.
And for medikit, I finally find bug in it, logic was right but I forget to init it in rule object and this get random value. In my test env I always get 0 that was correct value.
For missiles. Do you have same behavior with stock interceptors? It could be caused by rule sets. If I get ruleset that cause this I could easy fix it.
-
I need the simple files without the installer. Can you attach it somewhere?
I would like to try it on android.
-
I need the simple files without the installer. Can you attach it somewhere?
I would like to try it on android.
Its pointless, I support only windows and linux builds. It even impossible to compile it for android because android port is based on custom branch of OXC.
-
Ok
If it have a mappa common and standard I would like to try it.
The nightly for win need just a copy paste to work. The language file in xcom1 mappa don't work on android I don't know why so for that I use the android build language file.
The files are just files...
But it looks like what the android version know that can accept.
I simple need the files...
-
What "files"? Only file I give is one exe. To use it you need use nightly files.
-
Omg I had think it is an installer... Sad...
-
For missiles. Do you have same behavior with stock interceptors? It could be caused by rule sets. If I get ruleset that cause this I could easy fix it.
Found the culprit, it is caused by very low "projectileSpeed" values for craftWeapons.
I'm using "1" and it effectively delays the appearing of the missile. The missile pops up way after the launching sound is played, looking like no missile/missiles launched at all.
You can check it yourself by setting "projectileSpeed: 1" to vanilla missiles.
This is not an OXC Extended thing, but a vanilla OXC thing.
-
Ok new bug fix version ready. I hope I squish all bugs this time :)
-
Thanks a lot for your hard work, Yankes!
And i finally understood the flame damage calculation better and could make the heatray weapons work again. For those interested: Flame weapons do iirc 0-10 random damage for ~3 rounds when a unit is aflame. The ufopedia damage is only used for the area covered, it has no real meaning in terms of damage. So if you want to have a incendiary weapon have e.g. 40 REAL damage you can give it ANY damage value you want, it doesn't matter. However, you can adjust damage dealt by adjusting the TOHEALTH value (in Extended exe only of course) in my example this would mean TOHEALTH 4.0 which is dealt only once when hitting the target. Then you will get some random flame damage (0-10 iirc) for around 3 turns additionally. For a 130 damage flame weapon you would use 13.0 etc. However do not forget the additional random damage, so maybe use a slightly lower value.
And yes, Yankes, you had nothing to do with it, it's a vanilla exe thing. :)
-
I just discovered an interesting use for the requiresbuy function.
I wanted to declutter the research screen a bit, so I made an item with battletype 0 (geoscape only item like alloy and e-115) and gave it requiresbuy -LASERWEAPONS_Something so it would appear only after I could build laserweapons (just an example), then I added a research for this item (needitem:true is important) and made it unlock e.g. Gauss weaponry.
Result: I can now decide if I want to research Gauss weapons by "buying" a let's say RESEARCH CONTRACT GAUSS and only then will the researches appear in the research screen. If not wanted the research screen is emptier and cleaner.
It is even possible to use those "resources" (let's call the item GAUSS WEAPON KNOWLEDGE) in the manufacture list as a resource. That way the purchasable item remains interesting after the first research.
So far I "decluttered" Heatray, Terran plasma, Mass accelaerator and Railgun weaponry and boy does that research screen look tidy now or what! :)
I gave the items a high listorder number (15000+) so they appear at the bottom of the list, this makes the purchase screen also look tidy. I recommend to use UPPERCASE names so the research items are easier to recognize from other items.
I hope this helps someone. Me for one, I am very content with the way it looks/works.
Good work Yankes, your work is really appreciated! 8)
-
I had a similar idea (and even introduced it at some point), but for me, personally, a thing that you want to buy only once and then it does nothing beside cluttering the store would be unacceptable...
Also fire does 5-15 not 0-10 damage afaik. You don't need to use ToHealth either, just change RandomType to 1 for it to calculate initial damage like a normal weapon. You get a more "natural" blast damage propagation that way.
Also if you want items at the bottom of any list, omitting the listOrder altogether works best :)
-
Also fire does 5-15 not 0-10 damage afaik. You don't need to use ToHealth either, just change RandomType to 1 for it to calculate initial damage like a normal weapon. You get a more "natural" blast damage propagation that way.
+1 :>
-
New version 2.4:
Option for defining bonus and damage type for melee in range weapons.
Option for big explosion sound for each items.
Option for showing fixed weapons on unit.
Today version is supported by low hanging fruit.
-
+1 :>
Thanks did that and it works even better now! :)
edit:
The new explosion sounds do add more to the game than I had anticipated. I wonder why Warboy never bothered to change this, it really is a vast improvement without any major rewriting needed...
Oh and thanks so much for the fixed weapons on units howing up now, now the enforcer-like mods are really perfect again. Haven't tested the melee-weapon changes yet, but it should be possible now to make guns with bayonets plausible, isn't it? 8)
-
The new explosion sounds do add more to the game than I had anticipated. I wonder why Warboy never bothered to change this, it really is a vast improvement without any major rewriting needed...
Most of my changes fall in that category, but at some point you need say stop because you will only do only this things not implementing TFTD.
I don't have plan implementing TFTD, therefore I can focus on this things :)
Haven't tested the melee-weapon changes yet, but it should be possible now to make guns with bayonets plausible, isn't it? 8)
That why it was added.
-
Quote from: new_civilian on July 24, 2015, 11:29:08 am
Haven't tested the melee-weapon changes yet, but it should be possible now to make guns with bayonets plausible, isn't it? 8)
That why it was added.
Already working on it :3
-
I've started a new run through of hardmode v0.90 and was hoping to run it off the exe of version 2.4 rather than nightly 2015-07-27-1005 but as soon as I tried to assault the first alienbase (floater) the game crashes to the desktop, works fine off the nightly exe. Is there possibly some sort of conflict/incompatability here as I was looking forward to using the 4 weapons for crafts, training room facility and only sleeping mods.
-
I've started a new run through of hardmode v0.90 and was hoping to run it off the exe of version 2.4 rather than nightly 2015-07-27-1005 but as soon as I tried to assault the first alienbase (floater) the game crashes to the desktop, works fine off the nightly exe. Is there possibly some sort of conflict/incompatability here as I was looking forward to using the 4 weapons for crafts, training room facility and only sleeping mods.
Btw Simon, you should turn off the PSX Static Cydonia Map, since i spawn up to 64 enemy units and i have no clue how that would work out.
They might be incompatible (Hardmode Expansion and PSX stati Cydonia Map). I will also use a customized Script for the last Missions in the future.
Just so you know.
-
Thanks for the tip, will do that now as there is no surprise at the end when you know the brain is upstairs in the t shaped room.
-
Yankes, there was a dogfight error in the original exe which got fixed, you might want to update to include that fix. Right now dogfights are rather one-sided (UFOs do not fire back correctly or only once).
I love the new explosion sound abilty! :)
-
I've started a new run through of hardmode v0.90 and was hoping to run it off the exe of version 2.4 rather than nightly 2015-07-27-1005 but as soon as I tried to assault the first alienbase (floater) the game crashes to the desktop, works fine off the nightly exe. Is there possibly some sort of conflict/incompatability here as I was looking forward to using the 4 weapons for crafts, training room facility and only sleeping mods.
It would be good if I get save that show this bug. Another thing is test if original exe work fine with that save. If it crash it mean that is possible that is not my fault.
[ps]
after grabbing you save from hard mode topic and installing only hm v0.90 I could without problems run this mission. I would need more info to find error there.
-
Just tried it again, using exe of extended v2.4 with everything else from nightly 2015-07-27-1005 but it crashes to desktop before landing site 13.
-
But what mods was enabled? only HM 0.90?
-
No all, 35 in total(xcom1, 4 pre set, 27 user mods and the last 3 are for extended only-see attached) in the order shown. I've upgraded now to nightly 2015-07-31-1149 with hardmode v0.91 but haven't tried with extended or put on the last 3 mods until I heard back from yourself. Does landing site 13 load in for yourself?
-
I find out that OXCE 2.4 is incompatible with nightly you are using (especially nightly past 28th).
Easy way of fixing it is use proper nightly that match extended version.
Today I will prepare new version for 27th nightly.
Newer nightly will be supported by next release. Because 28th have lot of breaking changes I will too do some breaks.
Motto for next release will be: "I heard you like scripts, so I put an script in your script that you can script while you scripting" :)
-
updated version compatible with 27-07-2015 is ready.
-
Is the mod portal down again? I can't download 2.4A for some reason (suddenly a wild error appears).
-
Is the mod portal down again? I can't download 2.4A for some reason (suddenly a wild error appears).
I think it is the same problem as reported by Solarius few days ago (and reproduced by myself in mod Test123).
The download link contains "/" character, which breaks it.
In this case:
Link: https://www.openxcom.com/mod/openxcom-extended/download/34UJ/xAZ
Generated ID: 34UJ/xAZ
Problematic character: /
-
Not sure if the info is still of use, but the old version crashed with the nightly as well because of the default VARS rulefile which made some changes to the Elerium fuel for crafts.
And thanks for always updating, improving and fixing this exe, Yankes. I think you can see how appreciated your work is, from the amount of posts in this thread alone. 8)
-
Not sure if the info is still of use, but the old version crashed with the nightly as well because of the default VARS rulefile which made some changes to the Elerium fuel for crafts.
that was SIMON bug. This was fixed by simply updating to next nightly.
[ps]
I fixed mod portal bug by simply uploading again same file (second time have proper name).
-
Is it possible to make projectiles of particular damage type or of some particular weapon to be unable to destroy terrain?
Its been bugging me for some time - dart rifles and stun guns introduced by mods can destroy fences and grass, and, if its stun damage is set high enough, even brick walls.
Its not anything major, really, but it might be a nice feature.
Someone even might use it to create a line of neutron-beam/microwave emitter/cryo-ray weapons using it.
Actually, now when I think of possibilities - is it possible to make weapons behave like psi-amp and ignore terrain altogether, or up to some particular value (to prevent sniping through UFO hull)? That can make for some scary-scary alien foes as well as some high end imbalanced weapon toys.
And, for sake of competition, it might be required to make non-stun damage type explosions ignore terrain (as in not-destroy, not bypass-altogether). Not sure if it should be tied to damage type or particlual weapon though.
-
Is it possible to make projectiles of particular damage type or of some particular weapon to be unable to destroy terrain?
More than that - the amount of damage done to terrain by any weapon/ammo can be tweaked freely.
-
Yep, what Dioxine said^
I made some "neutron" bomb like grenades for my personal mod, skipping most armor and harming only health, no damage to items or tiles, pretty nice weapon for taking out armored units and can be balanced as well if you do not make them too strong. :)
-
hey yankes. do you support multiple soldier types?
-
right now no.
-
Is your version 2.4A based on borken Nightly or am I doing something wrong? Much of original texts ended up like this (texts added by the mod work normally).
-
on my system doesn't even run says something about can't read or missing folder
-
Make sure you have original UFO files in the /UFO folder, last time I was getting the same error and it took me some time to realize I forgot to copy these files... :)
-
Dioxine do you use correct nightly? To work properly it need be exactly version form that day because previous and next have breaking changes in rulesets.
It could be that. If you can't download correct ruleset you can grab it form github:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended/bin
(This link will be valid until I start working on next release, after that you will need find this files using commit id from ruleset)
-
I'm using the openxcom_git_master_2015_07_27_2340 as your mod page seems to suggest...?
-
Strange, it should work. I can't download this zip because its too old to be show but using rulesets form the repo that should be exactly same work fine.
Another thing is that nether I or Warboy touch languages files or code to possible cause this bug.
Another question is original exe work same or different? Only thing I could suggest now is made clean install.
-
Original exe works the same, with the same bug. No idea what's happening, I'll try it later.
Another issue, with the older build (early July I think, Extended ver. 2.3A) - seems that fixed weapons aren't recovered when a stunned unit comes back to life, at least with the old build I am using... Has this issue been fixed? Just asking because I don't track the bug fixes on daily basis.
EDIT:
the bug isn't appearing when the mod isn't enabled... but mod's strings are all fine...? I think it might be linked to the faux-master status of the mod... maybe I should put ALL of the language file into extraStrings? This would cure the ailment for sure, although it's a ton of work...
-
I don't know, I only recall some Warboy commit about some "sticky" fixed weapons. Personally I didn't encounter this bug or fix it.
-
All right, all I needed to do to properly upgrade to the new version Extended 2.4A was to put the en-US.yml file in mod's /language/ directory. :)
However, as of 27th July Nightly, the missing fixed weapons bug still persists.
-
Make sure you have original UFO files in the /UFO folder, last time I was getting the same error and it took me some time to realize I forgot to copy these files... :)
works fine with regular nightly executable but not with openxcomex executable. although the previous build worked fine.
-
Thank you for the mod, Yankes! Please, may you update the first post, since now i discovered it is avaiable also for linux, along with install istructions for that so? Another useful tip would be to indicate mods that are compatible with it, hopefully ;)
EDIT: once next openxcom stable version will be relased, a dedicated ubuntu PPA for the mod may be also created, don't know...
-
I'm gonna use this for a special project. Been meaning to do this for a while. There are a bunch of things I'd like to be able to use.
When is TFTD modding supported for extended?
My problem was TFTD xcom2 folder can't be read. That's why was giving me can't read folder errors. That's cause TFTD xcom2 is not supported yet in extended.
Also , if you think about it OpenXcom Extended features are probably what X-Com 3 would have had if they had made another game after TFTD.
-
At some point I will merge all changes for master branch. But first I need do some request for AndO3131 and merge my old script branch.
Recently I have lot of distraction and work don't move fast.
-
At some point I will merge all changes for master branch. But first I need do some request for AndO3131 and merge my old script branch.
Recently I have lot of distraction and work don't move fast.
thnak you! <3
edit: formatting
-
Yankes, could you please consider changing how retaliation: false works, so that it prevented retaliation completely? This would improve behaviour of non-alien opponents (cultists, men in black etc.), as they would never travel on alien ships.
-
This already done by another property.
-
This already done by another property.
...my knowledge of your project really has been slipping recently. :)
-
This already done by another property.
Regarding that, could you make a pull request for the respective code into the master branch?
-
Regarding that, could you make a pull request for the respective code into the master branch?
You should ask Warboy first if he is interested in that code. I prefer not wasting my time on things that can be rejected.
-
yankes would it be possible to limit/restrict weapons based on skills?
-
also would it be possible to add stringstats for items ? like researched, cost, damage type, power, aimedAcc, snapAcc, autoAcc, aimedTU, snapTU, autoTU, etc
-
Hmm... it seems that the missionCustomDeploy doesn't use alert, briefing or marker name associated with the new deployment. Would it be possible to include this as well? Ideally only if the new deployment declares any of that (if not, the current behaviour should be enforced, ie. the custom deployment inherits the briefing of the basic deployment).
-
idea was that it only override alien weapon deployment. In theory it could be possible to "inherit" values but it probably will require manually handling all values. And that is thing I prefer avoid.
Another thing is why you need do it? Couldn't you create separate mission that will have different alert, briefing, marker?
-
Well, my knowledge in that area might be outdated... The last time I've tried that, there was no way to tie a specific Objective 3 mission (as in, ufo flights) with a specific Objective 3 ground mission. Both were chosen at random, independently of each other. Has this changed recently? Sorry if I'm asking obvious things, but it's hard to track everything :)
-
Well, my knowledge in that area might be outdated... The last time I've tried that, there was no way to tie a specific Objective 3 mission (as in, ufo flights) with a specific Objective 3 ground mission. Both were chosen at random, independently of each other. Has this changed recently? Sorry if I'm asking obvious things, but it's hard to track everything :)
I need consulting this with code to answer your question. Probably previously it work that way, but I don't know how it work now after Warboy mission script overhead. I will think about some solution for that but this will need wait after I finish (start :>) working on my script engine.
-
From my experience with Piratez, and to a lesser degree also FMP, a big problem is that the AI cannot use weapons with limited range. This is rather sad, since you can't give the AI weapons like flamers or throwing knives and expect them to use them effectively.
I think overcoming this limitation would be fairly doable, though I don't know if it really is. The idea to implement would be:
1. Add one more check whenever an AI attempts to shoot a weapon. It checks if the weapon has limited range or not; if not (like most ranged weapons), then nothing special happens.
2. If the weapon has limited range, then the game checks if the target is in range. If yes, nothing special happens; if not, see point 3.
3. This actually requires some AI coding, but it's more or less the same as for aliens with melee weapons (which work). Essentially, the only difference is that instead of going straight to an adjacent square, the unit checks for distance after each step. If it is within range of the weapon now, it goes back to normal shooting; if not, it makes another step towards the target. Repeat until the unit is in range or it runs out of TUs.
Yankes, do you think it's relatively easy to do?
-
Probably yes, right now game need handle moving unit to right spot that allow clear shoot. Fix your problem would be marking all far places as "unclear".
-
Probably yes, right now game need handle moving unit to right spot that allow clear shoot. Fix your problem would be marking all far places as "unclear".
OK, I'll try to familiarize myself with the code to think about it. I've never coded anything in C++ though, so it's not going to be easy. In other words, I'm counting on you. :P
-
Would it be possible to pull the flashing health bar (indicating Fatal Wounds) into the Extended branch? It seems unlikely to be included in the main build, and a lot of people would really appreciate it...
-
Also, in openxcom extended, saved games are stored in the installation subfolder /user is that right?That is to say C:\openxcomExtended/user\ ?
-
Would it be possible to pull the flashing health bar (indicating Fatal Wounds) into the Extended branch? It seems unlikely to be included in the main build, and a lot of people would really appreciate it...
I prefer keep away (if I can) form altering UI or language data, but because you provide exe you could always alter it by adding this code.
Also, in openxcom extended, saved games are stored in the installation subfolder /user is that right?That is to say C:\openxcomExtended/user\ ?
Saves are stored exactly same way like in normal openxcom. If OXC stored there then OXCE will do too. Another thing is that for default OXC store save in home directory.
-
I prefer keep away (if I can) form altering UI or language data, but because you provide exe you could always alter it by adding this code.
It is probably a stretch, but perhaps this could be done through adding a Boolean to vars.rul? flashingHealth: true enabling the feature, while flashingHealth: false (or nothing) disabling it.
-
It is probably a stretch, but perhaps this could be done through adding a Boolean to vars.rul? flashingHealth: true enabling the feature, while flashingHealth: false (or nothing) disabling it.
This is not problem of "how" but "why". I try keep my goals low and focused. Maybe at some point I would expand it but right now I try keep it to improving mod support. I don't see problems if someone disagree and create Extended^2 version :)
btw I slowly finishing merging master to extended branch. My "vacation" end up with 200+ commits behind master (whole extended version have over 200 unique commits) :/
Probably in this weekend I will release catch up version with all goodies form recent nightlies.
-
This is not problem of "how" but "why". I try keep my goals low and focused. Maybe at some point I would expand it but right now I try keep it to improving mod support. I don't see problems if someone disagree and create Extended^2 version :)
Yeah, I understand it, and that's why I said it was a stretch. Still, I guess I have underestimated how cumbersome this project is, so I guess any extra code will weigh on future updates.
btw I slowly finishing merging master to extended branch. My "vacation" end up with 200+ commits behind master (whole extended version have over 200 unique commits) :/
Probably in this weekend I will release catch up version with all goodies form recent nightlies.
Oh, that would be nifty. Thanks. :)
-
Love your work, Yankes!
Any chance that you might be able to implement something like UFOExtenders "burst" and "full auto" firing modes?
What I mean is, they let you click on multiple points, and then would auto-fire ranging between those points.
In mods now you see a lot of weapons that fire very large numbers of shots in automatic mode (5 shots, even up to 20 shots!) but if you actually want to use these weapons to spray down an area you have to stick them on a rookie with bad aim and hope for the best, because someone with good aim will put all the rounds into the same spot.
If you could add the ability for a weapon to set two points for all the shots in auto mode will be distributed between, that would be great. (Basically, the first shot is aimed at the first point you click, the second 1/(N-1) of the way between the first and second points, the third 2/(N-1) between the first and second points, and so on until the last shot is aimed right at the second point)
That way we could actually use miniguns to shred cover in jungles, and try to kill several aliens that are grouped together with sustained fire.
-
Those firing modes would be very nice, but they certainly don't fall within this mod's objectives.
If someone was to program this, I guess it would use waypoints, a bit similar to the Blaster Launcher's. In the simplest model, the user would place two of them and the game would calculate a straight line between them, then place as many evenly distributed points along it as the number of bullets, then shoot one bullet at each point.
-
Oh? Sorry, I didn't see a statement of objective for the mod, and from the features added I just got the impression that it was about adding modding options. I guess the part where it has interface behavior instead of just back-end behavior is what's out of scope?
-
Those firing modes would be very nice, but they certainly don't fall within this mod's objectives.
If someone was to program this, I guess it would use waypoints, a bit similar to the Blaster Launcher's. In the simplest model, the user would place two of them and the game would calculate a straight line between them, then place as many evenly distributed points along it as the number of bullets, then shoot one bullet at each point.
I degree with "certainly" :> This depend on scope of changes require to made it work. Even your example show possible solution that I could accept (because it reuse available things). Only question is it worth it?
Oh? Sorry, I didn't see a statement of objective for the mod, and from the features added I just got the impression that it was about adding modding options. I guess the part where it has interface behavior instead of just back-end behavior is what's out of scope?
1) increasing mod support
2) keep changes only to code (e.g. don't change original rulesets or add new files)
3) avoiding UI and Language changes (because if I want do it properly it will require violating point 2)
4) prefer changes with large "new game play mechanic" / "new code" ratio
In case of your request only thing that lack is point 4. But this could changed based how it will be implemented.
Right now my answer would be "probably not" / "maybe".
-
Ok, next catch up release will be today or tomorrow. I finished merging and I hope that I don't create new bugs :)
If I will have time I will try fix bugs that was reported from previous version.
Code is already published, I someone do not want wait then is possible to compile it himself.
-
New version ready. Primary change are from master.
I skip some recent commits but it should still work with current nightly.
In next week I plan add skipped commits and some bug fix.
-
Would it be possible to re-introduce vanilla UFO's Waypoint number limit for Blaster-type weapon (a moddable one, of course) that is IMO sorely missing from OXCom? :)
-
Would it be possible to re-introduce vanilla UFO's Waypoint number limit for Blaster-type weapon (a moddable one, of course) that is IMO sorely missing from OXCom? :)
Yeah, and since we're at it, enabling it to be formula? For example, psiStrength/10?
-
After finishing scripting I can add it.
-
Ok first stage (aka merge) is finished.
https://youtu.be/FKzqCOg2DrQ
Next I will refactoring it to improve code. I plan that it will be finished in two weeks.
-
Ok first stage (aka merge) is finished.
https://youtu.be/FKzqCOg2DrQ
Next I will refactoring it to improve code. I plan that it will be finished in two weeks.
Nice colour effect!
And congrats on reaching the milestone.
-
The effect can find many uses, like illuminated sprites when the lights are off... Nice!
-
Where do I put the extender exe. please? Is there then a new way to use mods? I know there is instructions somewhere but ive been looking and cant find them.
Any help much appreciated, thanks:)
-
The effect can find many uses, like illuminated sprites when the lights are off... Nice!
because I forget add shade part to this script :>
Where do I put the extender exe. please? Is there then a new way to use mods? I know there is instructions somewhere but ive been looking and cant find them.
Any help much appreciated, thanks:)
Next to original exe. And to fully use extended version you need have mods that explicitly use functionality from it like Dioxine's X-Piratez.
-
I think an option to have all the sprites fully illuminated regardless of the master light level would be totally cool :3 (you can shoot them normally, anyway... just can't tell who they are even if you soldiers see them... and more importantly, with NV mechanics, you want to turn the flashlights off, and then you can't see your own soldiers...)
-
Yeah! That looks awesome in the dark. Could we have enemies glow red, soldiers blue and civilians green when they are in the dark but spotted. That would be a great UI improvement.
Also, maybe a glowy sprite when something is spotted but not displayed because the ground tile isn't sighted? I hate those cases of "alien in sight but we'll only show you its shade when you put your cursor on it even though it is in broad daylight".
-
I'd rather prefer full color sprite than some blue, red or green approximations... we're not limited by the technology, are we? And even if we were, soldiers should be red and enemies blue, do'h! :)
-
But we already have a colour code established in OpenXCom - for the minimap! Aliens blue, civilians red, your guys yellow. If anything, we should stick with this, otherwise it'll be confusing as hell!
-
Ah.. yeah, Solarius wins the color coding design competition ;) Makes a lot more sense that way.. And I think it'd look cooler for night fights than actual full color sprites, just gives a night vision techy sweep feel.
That being said, full color sprites when the alien is seen but not the tile would be even better, yes. There is no reason not to display an alien that is in sight.
-
Ah thanks. :)
Another idea is, how about, when the user turns off the lights, the entire screen goes monochrome? (The actual colour to be decided.) I mean it's displayed like on day vision, but in shades of just one colour.
-
hum.. that could be cool too. Maybe monochrome very shaded green, with glow effect on units?
-
hum.. that could be cool too. Maybe monochrome very shaded green, with glow effect on units?
Yeah, I agree green would probably be best. As for units glowing, maybe - experiments would be needed. :)
-
Hold Your Horses :> Doing some global recoloring will be painful because you would need do it for all armors.
I don't have plans do custom recoloring for full screen because it will very easy hit performance limit.
Form good news I plan option for switch body parts of sprite using script. You will able change at last dying animation of unit based on look.
-
Hold Your Horses :> Doing some global recoloring will be painful because you would need do it for all armors.
I've made 32 paperdolls for all my armors, I'm not scared :)
-
What about a way of blocking researches when doing another research. e.g. having to actually DECIDE about going for e.g RAILGUNS or going a different techtree. and NOT having both of them. This would make for real decisions and less cluttered manufacture/research screens. :)
and what about the new soldiertypes of the latest nightly? :)
-
Blocking research will be tricky, only way I see that can be do is block other research when you start new research project.
And for solders, right now I'm ignoring what happening in nightlys because I'm doing different things in my branch.
-
Mutually exclusive research paths would be retarded in any sci-fi setting, the science doesn't work that way, but such a function could be really handy if someone wanted to make a sword & sorcery setting... While we're at it, random production results when? :3
-
Falko had a good idea with this. For example, to get either laser or gauss as a early gun:
- Advanced Weaponry research project: getOneFree: Laser Weapons OR Gauss Weapons
-> Player randomly gets one but not the other, representing the scientists making a breakthrough in either one of the fields instead of both at the same time.
If you want to make both eventually available, you can make a "Laser Weapons Gauss unlock" which gives Laser Weapons and has dependencies on having developed the whole Gauss tree, representing the scientists getting another idea for weapons tech after perfecting the first breakthrough.
It's actually quite nice and an interesting way to mix up how the game progresses. You could even make it so that "Advanced Weaponry" unlocks either the pistol or the heavy weapon, making it so you either develop the high power system which needs to be big, or the miniaturized system because you haven't yet figured out a big power source.
-
I like that one, but to have something like that, you'd 'only' need to fix how getOneFree works... (I mean, repair the bug that causes all researches with 'getOneFree' be available w/o prerequisites unless blocked by requiresItem); but I think the bug can be circumvented (research Advanced Weaponry 'lookups' research str_trick_or_treat tech, which is blocked by 'requiresItem' and has 'getOneFree' on Laser Weapons and Gauss weapons).
But this are vagaries of science and the goodness of random, not the kind of moral choice civilian wrote about (don't get morals into my science! shoo! :)
-
Yeah, you're not sitting there as the commander, having to decide which of the two grant proposal to fund, but as you said, that's not really how science works. You don't forget one idea because you pursue another (unless you have a really crappy lab with little archival/note taking).
I guess you could have two scientists with big egos spearheading the two proposals, leading to one just leaving XCom if you don't pick his. Then by the time you complete one research tree, the weapons from the other one become available to buy because the scientists stormed out, got funding from an arms manufacturer and they are now producing it! That'd be cool :D (Yup, I'm a scientists and I think this can happen..!)
-
Speaking about moral choices... XCom morality should boil down to this:
(it's a bit like Bioware morality, but more ethical and much less veiled)
-
That's silly, it's obviously poisonous gas, so you can collect all the pristine alien tech left on the ground.
-
Oh-ho, we have the first adept of the Lightside (Open Hand Style) here :)
(sorry for horrible OT :) )
also @Arthanor, I am relieved that the real science is still alive :)
-
And for solders, right now I'm ignoring what happening in nightlys because I'm doing different things in my branch.
That's understandable, though it'd be interesting if you ad this at some point, as this feature is actually useful for many things.
Also, I'll be using OXCE for my next big project, thank you :)
-
Falko had a good idea with this. For example, to get either laser or gauss as a early gun:
- Advanced Weaponry research project: getOneFree: Laser Weapons OR Gauss Weapons
-> Player randomly gets one but not the other, representing the scientists making a breakthrough in either one of the fields instead of both at the same time.
If you want to make both eventually available, you can make a "Laser Weapons Gauss unlock" which gives Laser Weapons and has dependencies on having developed the whole Gauss tree, representing the scientists getting another idea for weapons tech after perfecting the first breakthrough.
It's actually quite nice and an interesting way to mix up how the game progresses. You could even make it so that "Advanced Weaponry" unlocks either the pistol or the heavy weapon, making it so you either develop the high power system which needs to be big, or the miniaturized system because you haven't yet figured out a big power source.
Thanks, that's a great idea!
Right now I am slowly updating my personal megamod-soup as I was absent for some month, I think I will make use of this^
About the new soldiertypes... After some thinking I realized that they are (surprising to me at the beginning) not really THAT important for my personal mod. If I want good soldiers at the start I might as well edit the default stats, and if I need them later.... well I will have troops trained in the training facilities (Extended-feature only), so basically the new soldiertapes are "only" a tiny improvement. For me, that is. I can see that they are quite useful for other purposes, though.
Anyway, I would understand if you would not add them.
I will only use the Extended exe for my Openxcom gaming. It has too many features that should be in the default exe like editing TUs for several actions.. and it is MUCH more flexible.
TLDR: Thanks, Yankes! :)
-
I think the main advantage of different soldier stats isn't overall quality differences, but different maximum stats and spreads of initial stats.
For example, in XCom: Human generalists and Hybrid psi-specialist that are kind of bad at other stuff for an Apocalypse mod?
For other things: Potentially different mutant strains for Piratez? Normal humans and Space Marines for a 40k mod? Elves, dwarfs, orcs and trolls in a Shadowrun or Fantasy XCom mod? It's a great feature, if someone is willing to put the extra amount of work to make it work (and I don't know how sprites and inventory images would work unless all soldier types look exactly the same..)
-
I agree with what you say.
However, I discovered that my old personal xcom 1 mod (from september btw) no longer works with anything newer than version 2.4, so I will stick to that version from now on. So the new soldier types are irrelevant for me anyway.
-
Yankes, do you think it would be possible to change engineers and scientists from being "special resources" to being "abilities" or "properties" of items or soldiers?
That would mean that we could have soldier/scientists or soldier/engineers (or even scientist/engineers) on one hand, and "capturable" specialists on the other hand.
Would that be possible at all?
-
Yankes, do you think it would be possible to change engineers and scientists from being "special resources" to being "abilities" or "properties" of items or soldiers?
That would mean that we could have soldier/scientists or soldier/engineers (or even scientist/engineers) on one hand, and "capturable" specialists on the other hand.
Would that be possible at all?
You mean like in UFO: Afterlight? Oh God, yes. :)
I can imagine Workshops being loaded like craft... A bit of a hassle, but so much fun!
-
This will be hard, because it will require handling all special cases of each type at once. e.g. when you use items then you need update all labs and factories because you could lost some "work hands".
Another problem is how it will fallback to basic exe, it could require breaking compatibility nightly (right now is still possible to load save without crash).
-
I see. too bad, actually...
what about the possibility to acquire engineers and scientists from other sources, like getting them after successfully completing certain missions?
would that be possible?
perhaps even tied to stuff like survival of certain civilians on the battlescape?
...you know, the old "retrieve the specialist" mission (or, in the case of XPiratez, "capture the specialist")...
-
This should be doable. I could even say that partially I have it in plans because when I add full script support then adding this after mission will be trivial.
-
How about flagging soldiers as 'researchers' and when they are taken out on field missions, when they return, they generate research points?
-
How about flagging soldiers as 'researchers' and when they are taken out on field missions, when they return, they generate research points?
Could be done by carrying a 'research' item into the field to gather data?
Not at all sure what has been conceived so far, but the code can always be fscked with.
-
If you only want that after successful mission one of research topic will grain progress then it will be at some point possible.
-
If you only want that after successful mission one of research topic will grain progress then it will be at some point possible.
That's pretty good. But just spinnning some ideas out there.
-
Hey,
Where can I download the required Nightly (19 sept. for 2.5 OXCE)? I know it's on the Git Hub, but I'm kinda lazy and incompetent regarding that system... Question void if you're planning a new release soon, Yankes :)
-
No new version soon, I'm now around 1/3 done and I need couple of full working days to finish. This mean week or more to do it.
In attachment there is data for version 2.5
-
@Extra soldiers stats (a'la UFO:Afterlight or whatever).
Why not add these stats as userStat1...10 or whatever, the number should be a multiply of the current stats number, so you could see them through multiplied/switchable soldier's stat windows. The gist of things is that a modder would define what these new stats do, how are they named etc. That'd make for a new entity in the ruleset, like 'items' are now. The 2 properties I can think of now would be 'production' and 'science'. The properties would also include how and if the stat grows. (it'd also mean one could tweak how the original stats work; this also reminds me - there should be an option in any weapon to set what skill is trained by firing it, as in, snap, aim & auto). Naturally even without any properties the new stats could be used to influence weapon's damage, armor regen etc.
-
The 2 properties I can think of now would be 'production' and 'science'.
...and 'piloting'...
-
@Extra soldiers stats (a'la UFO:Afterlight or whatever).
Why not add these stats as userStat1...10 or whatever, the number should be a multiply of the current stats number, so you could see them through multiplied/switchable soldier's stat windows. The gist of things is that a modder would define what these new stats do, how are they named etc. That'd make for a new entity in the ruleset, like 'items' are now. The 2 properties I can think of now would be 'production' and 'science'. The properties would also include how and if the stat grows. (it'd also mean one could tweak how the original stats work; this also reminds me - there should be an option in any weapon to set what skill is trained by firing it, as in, snap, aim & auto). Naturally even without any properties the new stats could be used to influence weapon's damage, armor regen etc.
I have some thing like that in my far plans. Most objects in game will have customizable properties not used by game:
armors:
- type: STR_SOMETHING
custom:
XPIRATEZ_MOJO_2: 5
XPIRATEZ_CRAFT_BONUS: 10
OTHER_MOD_WEAPON_MULTIPLER: 100
After that in script that have access to armor you could use this values in any way you want.
-
@Extra soldiers stats (a'la UFO:Afterlight or whatever).
Why not add these stats as userStat1...10 or whatever, the number should be a multiply of the current stats number, so you could see them through multiplied/switchable soldier's stat windows. The gist of things is that a modder would define what these new stats do, how are they named etc. That'd make for a new entity in the ruleset, like 'items' are now. The 2 properties I can think of now would be 'production' and 'science'. The properties would also include how and if the stat grows. (it'd also mean one could tweak how the original stats work; this also reminds me - there should be an option in any weapon to set what skill is trained by firing it, as in, snap, aim & auto). Naturally even without any properties the new stats could be used to influence weapon's damage, armor regen etc.
Oh no I can see where this is all going!
-
Hi, I'm new here, but have been playing OpenXcom and Piratez for a while. Loving every minute. Is there any more documentation for OpenXcom Extended besides the readme and this forum? I have a pretty good idea how to work with it thanks to the .rul files that come with Piratez, but I'm sure there are features I haven't discovered yet. I would like to create a "total conversion" mod in the spirit of piratez, but separate from both piratez and original xcom. Thanks!
-
https://www.openxcom.com/mod/openxcom-extended This is the full documentation, but to understand it fully, you have to learn modding OXCom to at least some degree. Try also this site for normal OXC modding (all of this works in OXCE as well): https://www.ufopaedia.org/index.php?title=Ruleset_Reference_Nightly_%28OpenXcom%29#Map_Scripts
Oh yeah and making a proper Total Conversion takes a year or three, so be prepared :)
-
Hi, I'm new here, but have been playing OpenXcom and Piratez for a while. Loving every minute. Is there any more documentation for OpenXcom Extended besides the readme and this forum? I have a pretty good idea how to work with it thanks to the .rul files that come with Piratez, but I'm sure there are features I haven't discovered yet. I would like to create a "total conversion" mod in the spirit of piratez, but separate from both piratez and original xcom. Thanks!
Readme is complete documentation of Extended version. And as Dioxine said, target demographic is people who know OXC modding and want more that basic version give.
-
https://www.openxcom.com/mod/openxcom-extended This is the full documentation, but to understand it fully, you have to learn modding OXCom to at least some degree. Try also this site for normal OXC modding (all of this works in OXCE as well): https://www.ufopaedia.org/index.php?title=Ruleset_Reference_Nightly_%28OpenXcom%29#Map_Scripts
Oh yeah and making a proper Total Conversion takes a year or three, so be prepared :)
Awesome, thanks for the reply. I have been working with those guides so far, and I think I enjoy modding xcom as much as playing it. Long road ahead, I understand. I can't imagine a project as huge and detailed as Piratez. Kudos, Dioxine!
Time to get at it. I will start a thread here if I ever get something remotely playable.
-
Hmm, add ability to gunMelee and (maybe, if not too difficult) to shoot & be primed to all Battletypes? :)
-
Rookie #1: Incoming! OH MY GOD IT'S A CHRYSSALID!! *runs away screaming*
Rookie #2: *panics and prime whatever he had in his hands, drops it and run*
*Chryssalid steps on a primed medkit, gets exposed to a weird cocktail of all kind of drugs, overdoses and falls in a coma*
Commander: Quartermaster! We need more medkits to take out those aliens. Forget about the grenades, they weren't enough.
-
Hmm, add ability to gunMelee and (maybe, if not too difficult) to shoot & be primed to all Battletypes? :)
At some point melee could be add, I don't recall any big road block that could prevent it. Shooting will be bit harder because psi-amp share stats with weapons, except that you want fireball from psi-amp instead of psistorm :) For priming right now all items can by primed but if it is not grenade it will disappear when time run outs.
Today or tomorrow I will release new bug fix version.
-
Shooting is not important that much, better save shared functionality between objects. But melee'ing with any kind of object, or making it explode, would be awesome. The third - shooting - function is not needed that much, I doubt there would be much sense in shooting Medkits (and it would also raise problems if medkids were made to accept clips :) ) Firestorm-wand can be done already with no trouble, it's just a battleType 1 with a lot of extra code :)
-
eee, melee is already implemented, set melee time cost to value bigger than zero and you should be able hit aliens in head with medikit instead of healing them.
BTW, around hour or more next bug fix verison will be ready.
-
bug fix version 2.5a ready
- consistent craft stats
- stun unit items
- exposion radius based on stats
-
eee, melee is already implemented, set melee time cost to value bigger than zero and you should be able hit aliens in head with medikit instead of healing them.
BTW, around hour or more next bug fix verison will be ready.
Then I was unlucky, since melee didn't work for Psi-Amp, for some reason... I guess I need to try with every object type, since new OXCE is up! :)
EDIT. Succesfully migrated to 2.5. Aircraft equipment finally works in full capacity. Does 2.5A use the same Nightly as 2.5?
-
Yes, and how melee don't work? What happens exactly?
-
The Psi-Amp misses all the time (30 consecutive misses with hit chance = 71%), playing 'failed psi attack' sound while doing that.
The meele code:
meleeType: 7
meleePower: 30
meleeDamage:
strength: 0.3
melee: 0.1
accuracyMelee: 100
meleeMultiplier:
flatHundred: 0.5
melee: 0.5
costMelee:
time: 12
energy: 6
flatMelee:
time: true
EDIT: missed hit sound and anim, but even adding it changes nothing. However, Medikits, Flares & Corpses, when added this code, work as intended - I was clubbing left and right with flares, bottles and fallen enemies :) The only problem - death animation is not always played.
EDIT: would it be possible to remove 'safeguards' that delete all Battletype 0 and 'wrong' Battletype 2 items from enemies inventories? It's kinda impotant, because the enemies carry lots of items like data discs or sth, and I have to make them battletype 10, but this makes them loadable into the craft. Or is it safe to use battletype 11 for these misc items?
-
Another problem found:
meleePower: 20
meleeDamage:
strength: 5.5
If I add such stats to a gun, it seems to only use meleePower, and completely ignore the bonus that it's supposed to get from meleeDamage (ver. 2.5)
-
Sorry, readme f*** up. `meleeDamage` -> `meleeBonus`.
And for psi-amp, I will look on this in code. Probably some special handling of psi attack override melee hits.
-
Thank you, now it works :)
-
Hmm, melee reactions now seem to crash the game (ver. 2.5). Could you look into their code? Does 2.5A run on the same nightly? Might be that specific's Nightly's bug...
-
2.5a use exactly same nightly as 2.5 only difference is bug fix.
Do you have savegame? it would speed up reproducing thins bug on my side.
[ps]
test with basic xcom don't show crash when enemy react with melee. I need more information to fix it.
-
The crash save. Needs piratez 0.96, but you have to install 'em on OXCE 2.5 (the DL package contains 2.4A); just wait a couple of turns, an enemy should go through the door, prompting the crash. Such crashes never happened before...
-
thaks, I will look on this.
[ps]
It looks like problem is with walking sound rather than reaction. It gets value 999 and crash when you see movements of that unit. You can test it by using debug mode and it will crash turn earlier. I will check if its some problems with loading ruleset.
-
Hmm, this unit uses default walking sound. This makes sense, since there was a crash earlier when a power-armor unit just walked into gals' view... But why suddenly the default walking sound would be bugged? Map settings?
EDIT: the problem is caused by moveSound: -1 in armor's entry... While movesounds have been moved from armors to units, or at least doubled. DAMMIT I HATE SUCH CHANGES. Especially since the 'default' -1 just moves it to 999, breaking the game... :/ What's the default number which causes an unit to use normal terrain-dependant walking sounds?
-
Allright, alerts off, seems that removing all movesound:-1 eliminates the bug... now only for a gruelling work of upturning the whole ruleset, to eliminate STR_FLOATER and STR_SNAKEMAN, and turning them to STR_GUILD and STR_CHURCH...
-
Problem is that "-1" should be correctly handled by game as "no sound". I will look on nightly and my branch why this is miss handled.
I didn't jet have time to work with this but most of values from ruleset get mod offset even if it should reference basic sounds.
-
It is possible to make optional "stun damage alteration" option, which make stun damage have same impact on a soldier/creature characteristic as direct health damage?
-
One of the issues with recent nightlies that has been crashing mods:
Hitanimations:
Warboy has updated those and it now affects HE/smoke/incendiary weapons. Before these had no affect whatsoever.
Ensure your hitanimation has an appropriate value if you are using one of these weapons.
See chatlog below.
Cheers, Ivan :D
Thanks for this. I had a similar problem using the older version for Commendations and just realised that I had changed hitAnimation to 26 on a weapon. I will change back to 0.
-
It is possible to make optional "stun damage alteration" option, which make stun damage have same impact on a soldier/creature characteristic as direct health damage?
This is already done.
-
Modsite link for the 2.5A is broken again... can you update your Mediafire backups, as they end on ver. 2.4?
-
Modsite link for the 2.5A is broken again... can you update your Mediafire backups, as they end on ver. 2.4?
ok
[ps]
done
-
new bug fix version ready. Two things was fixed. Handling of melee in psi-amp and loading unit sounds in ruleset.
-
Cool! Now I can make the true magic staff experience, and loading sounds also sound like a great addition to make the game more flavorous :) Is this new version still called 2.5a, since I can't find any newer in the downloads?
-
its on mod portal, now I check links are correct :)
-
Dear Yankes, just downloaded the linux version 2.5b replacing the old 2.4a but i find the statstrings are on by default, but i did not activate them, see screenshots attached. So how i may turn them off?
-
Impossible to have any difference between versions "a" and "b". Another thing is that I don't touch that part of code consciously (some times some miss merges can break some stuff) .
One questions do this name is still calculated or it maybe leftover after mod was disabled? New hired have it too?
-
Impossible to have any difference between versions "a" and "b". Another thing is that I don't touch that part of code consciously (some times some miss merges can break some stuff) .
One questions do this name is still calculated or it maybe leftover after mod was disabled? New hired have it too?
I started a new game with UFO Redux, just to simply try, so it's a very beginning. But i reverted to 2.4 because extended piratez with 2.5b is very crashy so i downgraded to 2.4. Just to let you know, gonna wait next x-piratez version.
-
If you use redux is possible that it give this stat strings.
And another thing xpiratez aren't crashy with 2.5 but incompatible. You need have correct version Extended and xpiratez to work properly.
If I recall correctly lastest version is still on 2.4 but next one will be based on 2.5
-
If you use redux is possible that it give this stat strings.
Probably Hobbes put them in an "hardcoded" way, don't know.
And another thing xpiratez aren't crashy with 2.5 but incompatible. You need have correct version Extended and xpiratez to work properly.
If I recall correctly lastest version is still on 2.4 but next one will be based on 2.5
Yes, but i thought since between 2.4 and 2.5 there are not big differences it might have been worked. Ok, i'll stick with x-piratez default one provided. :) thanks
-
There are big differences, since 2.5 is based on September Nightly and 2.4 on May (I think). So it's a wonder you were even able to launch the game at all.
-
Can I use this to change the base layout to 8x8?
I also want to make 2x4 tanks. It can theoretically be done, they just need to check a few squares next to them for passability when turning.
-
Can I use this to change the base layout to 8x8?
I also want to make 2x4 tanks. It can theoretically be done, they just need to check a few squares next to them for passability when turning.
No and No. Base don't have enough room to add new rooms. Adding scrolling would be overkill. And for tanks, this would need modification in lot of different places. Every part of battlescape would need changes only to support this.
-
No and No. Base don't have enough room to add new rooms. Adding scrolling would be overkill. And for tanks, this would need modification in lot of different places. Every part of battlescape would need changes only to support this.
Why can't the base screen just be put to a higher resolution?
I don't see how the battlescape needs changing unless you mean to prevent the tanks from getting stuck. I don't see a problem with that...player either learns not to get tanks stuck, or learns to free them once they are stuck.
-
Why can't the base screen just be put to a higher resolution?
I don't see how the battlescape needs changing unless you mean to prevent the tanks from getting stuck. I don't see a problem with that...player either learns not to get tanks stuck, or learns to free them once they are stuck.
If you don't see problems, why don't you code it yourself :) Higher res Basescape is NOT supported by the game as of now, and even if it were, you'd have to force higher res on everyone to have larger bases...
Also, non-square units are not supported. Falko once said that it would be theoretically possible to make a 3x3 unit on this engine, but one would have to write a sprite drawing routine for such an unit, at the very least.
@Yankes: question. Does the HitBonus in UFOs replace their normal hit chance, or increases it? Also, what is the default hit chance of UFO weapons? 60%?
-
Why can't the base screen just be put to a higher resolution?
I don't see how the battlescape needs changing unless you mean to prevent the tanks from getting stuck. I don't see a problem with that...player either learns not to get tanks stuck, or learns to free them once they are stuck.
Most of my answer could be Dioxine post. One point about "battlescape needs changing", I except that to do it right it would require rewrite half or battlescape code to made 4x2 units works. AI, Path Finding, Map and Unit rendering. And is big possibility that it will end up as big mess (3x3 would be more possible).
And finally one things that prevent it even if I could made it. This will break backward compatibility with basic version. its still should be possible to load extended save in normal exe, of course without any new functionality form extended version.
-
What if it was counted as a 2x2 for purposes of placement, movement, and hit restrictions, but reserved a couple spots in front of and behind it on the transport, and drew a larger sprite which covers up whatever is on the squares in front of or behind it? It would have some graphical glitches but you could avoid that if you wanted by not driving it next to walls.
Well I'm okay without these, they're not really worth buying anyway. At this point I'm just curious to find some way to do it. I'd really like to see an 8x8 base layout though. I wasn't aware that the base screen can't have its resolution changed.
Is there some way to make an aircraft storage facility that can hold multiple aircraft which are not fueled, and make it so they can be transferred to hangars?
-
Reaver, the base thing has already sort of been implemented by Fenyő here (https://openxcom.org/forum/index.php/topic,2559.msg25857.html#msg25857). I really liked the option too, but it was... not added to the main branch.
You can read more about it in that thread (the video is a good demo of the features), and Fenyő's branch is still up on github (https://github.com/fenyo1/OpenXcom/branches) so one could merge it into their game. Base handling shouldn't interact with much other code, except maybe Yankes' base facility requirements code. I haven't tried to merge it, but eventually will I think. Unless Yankes is willing to merge it into OXCE and literally extend XCom :D
-
the customization of the explosion animation is an extended feature or is it available on vanilla oxc too?
-
vanilla, I only add custom sound.
-
Minor request: would it be possible to add custom point cost for live capture? (I don't even know how this is calculated, to be honest... twice the kill value?)
-
Minor request: would it be possible to add custom point cost for live capture? (I don't even know how this is calculated, to be honest... twice the kill value?)
I see where this is going and I approve.
(https://i.imgur.com/2HibiiX.gif)
-
Minor request: would it be possible to add custom point cost for live capture? (I don't even know how this is calculated, to be honest... twice the kill value?)
I can do it, but only after I finish scripting (and this will take some time).
-
Another minor request:
Do you think you could add a lineto UFOPaedia articles for meee weapons? In the same way it shows:
XShot Acc TUs
it would be really nice to have:
Melee Acc TUs
Would save Dioxine writing all that in the UFOPaedia description.
-
Another minor request:
Do you think you could add a lineto UFOPaedia articles for meee weapons? In the same way it shows:
XShot Acc TUs
it would be really nice to have:
Melee Acc TUs
Would save Dioxine writing all that in the UFOPaedia description.
It will be hard because not enough space for 4th line. Without some sacrifices it is probably impossible.
-
hum.. good point. What about:
If all 3 shots are defined, don't show melee option even if it is there. The weapon is obviously a gun and the modder can add melee info if they want.
If not all 3 shots are defined, you have space, melee info is shown.
That would allow better presentation of the melee info for all purely melee weapons, and most of the hybrid weapons.
Or if not that, then maybe only for weapons that don't have any shot? Currently, only the power of the weapon is shown, and everything else has to be put in the description. Having one line for the stats of melee weapon would improve things to some extent, and make the ufopaedia more uniform.
-
Another possible solution is change font to smaller one or simply allow modder to alter overall layout of page (but not adding new one).
Overall I bit ignored ufopedie, none of my changes are reflected in it.
At some point I should spend some time improving it, but right now I have other things to do.
-
I don't care either way. And what Arthanor proposes might be actually more confusing than helpful - a normal human expects to find one info in one place, not be dazed by information that constantly jumbles around the whole page.
-
Seemed more consistent to me (all the accuracy and TU costs in the same place, instead of melee ones tucked away in the description). That was actually the point of the suggestion. Although granted the "only show if there's place" idea is bit more confusing.
Oh well, there are indeed more important things that could be worked on. Just wanted it to be somewhere in the ToDo list ;) (or quickly done, before the space issue was pointed out).
-
Yankes, it may be bold of me to ask, but what is this scripting you are working on? Because it comes up pretty often from you, like "I'll add this when I get the scripting done", or "Yeah that's interesting, but right now I'm doing scripting". So I naturally got curious about this scripting thing. Is it related to the vanilla mission scripting (or even the same thing), or did you mean something else entirely?
-
"Turing complete" scripting e.g. you will can add any logic you want to game. Instead of adding new properties or special cases in code you could add new things using only ruleset. like "When your commander die you lose game", "Spawn unit after grenade explosion" or mix both "lose game after ANY grenade explosion" (some part of game could be reimplemented using script to allow change it by modders).
Right now I stuck on trying figure out how made it scalable, because its work from long time but would be hard to do lot of things I plan in current state.
Of course I do it in Hard way because I code all my self :). Simpler solution would be drop all my code and add some ready solution for some library.
But that would not be so fun :)
-
OK, I get it, hat's off, man. This is big.
So, how is it going? Can we put you under pressure now? :)
-
Extended version of OpenXcom
Mod version 2.5b
OpenXcom version: Nightly 2015-09-15
OpenXcom commit: 773fd047a42b1efe377fc9d56490fdeae922ffd5
Extended commit: 808f86681feed875d9e0286711ca1f0e40973135
Current working branch:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended
Hi Yankes, I would like to compile my own version of 2.5b... which commit/branch should I use?
a/ commit 808f86681feed875d9e0286711ca1f0e40973135 ... from master branch ? from Nov 27th
b/ or latest commit (a15d6cfc1ab7f13c37043baf437f4edb398ded5f) from https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended branch? from Oct 10th
EDIT: also, both of them seem to contain more than "OpenXcom version: Nightly 2015-09-15"... is there even a third option?
EDIT2: I tried the first option using the same approach as for vanilla, but I get build errors (no compilation errors though)... any idea what's wrong? (windows 7, visual studio 2010)
1>------ Build started: Project: OpenXcom, Configuration: Release Win32 ------
1>Build started 11. 12. 2015 15:08:13.
1>InitializeBuildStatus:
1> Touching "D:\xcom-ext\OpenXcom\src\..\obj\Win32\Release\OpenXcom.unsuccessfulbuild".
1>ClCompile:
1> All outputs are up-to-date.
1> All outputs are up-to-date.
1>ResourceCompile:
1> All outputs are up-to-date.
1>BasescapeState.obj : error LNK2001: unresolved external symbol "public: __thiscall OpenXcom::AllocateTrainingState::AllocateTrainingState(class OpenXcom::Base *)" (??0AllocateTrainingState@OpenXcom@@QAE@PAVBase@1@@Z)
1>AlienBAIState.obj : error LNK2001: unresolved external symbol "public: bool __thiscall OpenXcom::RuleDamageType::isDirect(void)const " (?isDirect@RuleDamageType@OpenXcom@@QBE_NXZ)
1>TileEngine.obj : error LNK2001: unresolved external symbol "public: int __thiscall OpenXcom::RuleDamageType::getRandomDamage(int)const " (?getRandomDamage@RuleDamageType@OpenXcom@@QBEHH@Z)
1>PsiTrainingState.obj : error LNK2001: unresolved external symbol "public: __thiscall OpenXcom::TrainingState::TrainingState(void)" (??0TrainingState@OpenXcom@@QAE@XZ)
1>Armor.obj : error LNK2001: unresolved external symbol "public: int __thiscall OpenXcom::RuleStatBonus::getBonus(class OpenXcom::BattleUnit const *)const " (?getBonus@RuleStatBonus@OpenXcom@@QBEHPBVBattleUnit@2@@Z)
1>Armor.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setStunRecovery(void)" (?setStunRecovery@RuleStatBonus@OpenXcom@@QAEXXZ)
1>Armor.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setEnergyRecovery(void)" (?setEnergyRecovery@RuleStatBonus@OpenXcom@@QAEXXZ)
1>Armor.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setTimeRecovery(void)" (?setTimeRecovery@RuleStatBonus@OpenXcom@@QAEXXZ)
1>Armor.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setPsiDefense(void)" (?setPsiDefense@RuleStatBonus@OpenXcom@@QAEXXZ)
1>Armor.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::load(class YAML::Node const &)" (?load@RuleStatBonus@OpenXcom@@QAEXABVNode@YAML@@@Z)
1>Armor.obj : error LNK2001: unresolved external symbol "public: __thiscall OpenXcom::RuleStatBonus::RuleStatBonus(void)" (??0RuleStatBonus@OpenXcom@@QAE@XZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setFlatHundred(void)" (?setFlatHundred@RuleStatBonus@OpenXcom@@QAEXXZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setStrength(void)" (?setStrength@RuleStatBonus@OpenXcom@@QAEXXZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setPsiAttack(void)" (?setPsiAttack@RuleStatBonus@OpenXcom@@QAEXXZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setThrowing(void)" (?setThrowing@RuleStatBonus@OpenXcom@@QAEXXZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setMelee(void)" (?setMelee@RuleStatBonus@OpenXcom@@QAEXXZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleStatBonus::setFiring(void)" (?setFiring@RuleStatBonus@OpenXcom@@QAEXXZ)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: void __thiscall OpenXcom::RuleDamageType::load(class YAML::Node const &)" (?load@RuleDamageType@OpenXcom@@QAEXABVNode@YAML@@@Z)
1>RuleItem.obj : error LNK2001: unresolved external symbol "public: __thiscall OpenXcom::RuleDamageType::RuleDamageType(void)" (??0RuleDamageType@OpenXcom@@QAE@XZ)
1>D:\xcom-ext\OpenXcom\src\..\bin\Win32\Release\OpenXcom.exe : fatal error LNK1120: 19 unresolved externals
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:26.74
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
-
Hi Meridian,
I've used commit 808f8 from Nov. 27th to compile and then run X-Piratez without issues. Did you try to add something else in there? That's usually where things go wrong..
I have a code version with "manufacturing profit/cost info" and "statistical bullet conservation" added, which works fine. Depending on which feature you are looking for, I could look into making a "custom OXCE code" and publish that on github.
-
808f86 is lasted released version. In OpenXcomExtended branch is working copy of next version.
"OpenXcom version: Nightly 2015-09-15" mean what base nightly is compatible with.
For compile errors, some ".cpp" files aren't added to project files. Chack if you have added "AllocateTrainingState.cpp", "RuleDamageType.cpp" and "RuleStatBonus.cpp".
-
I've used commit 808f8 from Nov. 27th to compile and then run X-Piratez without issues. Did you try to add something else in there? That's usually where things go wrong..
I have a code version with "manufacturing profit/cost info" and "statistical bullet conservation" added, which works fine. Depending on which feature you are looking for, I could look into making a "custom OXCE code" and publish that on github.
No, I haven't added anything yet, just trying to compile 808f8.
After I can compile it, I will try adding the Stat Improvement screen (https://openxcom.org/forum/index.php/topic,2461.msg55882.html#msg55882), the one with empty spaces.
For compile errors, some ".cpp" files aren't added to project files. Chack if you have added "AllocateTrainingState.cpp", "RuleDamageType.cpp" and "RuleStatBonus.cpp".
Yes, the files were missing. I've added them and now I get other strange errors, attached a screenshot. Any idea? It's been a long time since I did C++ last time... :(
-
could you show where in OpenXcom code error is generated? type_traits is standard library and without more information I can't find cause.
-
Here's the entire console output:
1>------ Build started: Project: OpenXcom, Configuration: Release Win32 ------
1>Build started 12. 12. 2015 11:20:36.
1>InitializeBuildStatus:
1> Touching "D:\xcom-ext\OpenXcom\src\..\obj\Win32\Release\OpenXcom.unsuccessfulbuild".
1>ClCompile:
1> All outputs are up-to-date.
1> RuleStatBonus.cpp
1>Mod\RuleStatBonus.cpp(63): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>Mod\RuleStatBonus.cpp(68): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>Mod\RuleStatBonus.cpp(73): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>Mod\RuleStatBonus.cpp(78): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>Mod\RuleStatBonus.cpp(83): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>Mod\RuleStatBonus.cpp(125): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>Mod\RuleStatBonus.cpp(129): warning C4244: 'return' : conversion from 'int' to 'float', possible loss of data
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\type_traits(197): error C2752: 'std::tr1::_Remove_reference<_Ty>' : more than one partial specialization matches the template argument list
1> with
1> [
1> _Ty=float (__cdecl &)(const OpenXcom::BattleUnit *)
1> ]
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtr1common(356): could be 'std::tr1::_Remove_reference<_Ty&&>'
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtr1common(350): or 'std::tr1::_Remove_reference<_Ty&>'
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\type_traits(962) : see reference to class template instantiation 'std::tr1::remove_reference<_Ty>' being compiled
1> with
1> [
1> _Ty=float (__cdecl &)(const OpenXcom::BattleUnit *)
1> ]
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\utility(26) : see reference to class template instantiation 'std::tr1::decay<_Ty>' being compiled
1> with
1> [
1> _Ty=float (__cdecl &)(const OpenXcom::BattleUnit *)
1> ]
1> Mod\RuleStatBonus.cpp(288) : see reference to class template instantiation 'std::tr1::_Unrefwrap<_Type>' being compiled
1> with
1> [
1> _Type=float (__cdecl &)(const OpenXcom::BattleUnit *)
1> ]
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\type_traits(965): error C2528: 'abstract declarator' : pointer to reference is illegal
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\type_traits(349): error C2528: 'type' : pointer to reference is illegal
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\type_traits(967) : see reference to class template instantiation 'std::tr1::add_pointer<_Ty>' being compiled
1> with
1> [
1> _Ty=float (__cdecl &)(const OpenXcom::BattleUnit *)
1> ]
1>Mod\RuleStatBonus.cpp(382): warning C4244: 'return' : conversion from 'float' to 'int', possible loss of data
1>Mod\RuleStatBonus.cpp(384): warning C4244: 'return' : conversion from 'float' to 'int', possible loss of data
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:16.06
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
-
I push on master possible fix.
But I have bad news, next release (3.0 with scripts) will be incompatible with vs2010 because I move to C++11 with code base.
This will require to upgrading to vs2015 community edition.
-
It works, thanks!
After updating I also had to add one more file (TrainingState.h/cpp) and then it was OK.
-
request: would it be possible to make damaging shots deal 10% of their before armor damage to armor, instead of 10% of their after armor damage?
Example:
In XCom...
Shot deals 80 damage, target has 50 armor, target takes 30 damage and target's armor takes 3 damage.
Shot deals 50 damage, target has 50 armor, target takes no damage and target's armor takes no damage.
What I want...
Shot deals 80 damage, target has 50 armor, target takes 30 damage and target's armor takes 8 damage.
Shot deals 50 damage, target has 50 armor, target takes no damage but target's armor takes 5 damage.
-
This was done long time ago: `ToArmorPre`.
-
where can i find the required nightly?
i guess i could take out the files from xpiratez mod.
-
Some posts ago I post it in this thread as zip.
-
laziness triumph.
could anyone point me to what fixing need to be made to port mod to extended?
not asking about advanced extended-only features, just about converting vanilla stuff correctly.
for example i know (as far as i understand) that HWP ammo work in a different way.
vanilla:
- type: STR_TURRET
clipSize: 6
- type: STR_AMMO
clipSize: 6
equals to extended:
- type: STR_TURRET
clipSize: 1
- type: STR_AMMO
clipSize: 6 oops this was wrong actually; they still seem to work differently; maybe because it still uses old nightly as base.
also turning off retaliation for alien races is different afaik.
vanilla:
- retaliation: false
extended:
- retaliationAggression: -100
anything else?
thanks
-
this is two different retaliations. One is responsive for random missions (`retaliation`) second for real retaliation after shooting down ufo (`retaliationAggression`).
-
could anyone point me to what fixing need to be made to port mod to extended?
not asking about advanced extended-only features, just about converting vanilla stuff correctly.
None code-wise but Extended changes some rules (like reloading, or that uncoscious units can be hit and killed, etc, etc), so the mod may require rebalancing :)
-
I'm trying the Linux binaries linked in the first post, and getting segmentation fault (no other errors). What gives?
This is a Linux Mint, and I've got the ubuntu nightly installed via repository. What's the proper way to install the extended version?
-
This repo is probably version 1.0 that should be forgotten. You need proper data from nightly to work with. You can grab it for one of post in that thread (I probably should move it to first post for better visibility).
-
Ehnacement suggestion: a medikit with a flag medikitType 1...3 should display the number of remaining uses in the hand ui, just like a weapon/ammo clip (it won't be misleading, since such a medikit has just a single type of effect anyway, not 2 or 3 like in normal medkits). Not sure if it should display these instead of normal medikit info in the full inventory UI, but just might as well. Hope I managed to make myself understandable...
-
It can be done. When I have some free time I will do it.
-
Ehnacement suggestion: a medikit with a flag medikitType 1...3 should display the number of remaining uses in the hand ui, just like a weapon/ammo clip (it won't be misleading, since such a medikit has just a single type of effect anyway, not 2 or 3 like in normal medkits). Not sure if it should display these instead of normal medikit info in the full inventory UI, but just might as well. Hope I managed to make myself understandable...
@Dioxine: something like this? ...see attached
Btw. you reminded me of a feature I wanted to implement: a BIG FAT warning that you're about to heal/stim the enemy... I've done that too many times by mistake.
It can be done. When I have some free time I will do it.
@Yankes: patch file attached
-
Yeah, just like that :) I thought of limiting it to UI-less medkits only (beer will become one in 0.97C, just like combat drugs), since it looks a bit ugly... but boy, so very useful :)
@About healing the enemy: just don't make it a prompt or you will drive me insane, since I do heal enemies rather often, on purpose :) Maybe some modification of the medical UI so it shows WHOM you're healing (a name shown). Otoh beer's going to be UI-less now... :)
-
Yeah, just like that :) I thought of limiting it to UI-less medkits only (beer will become one in 0.97C, just like combat drugs), since it looks a bit ugly... but boy, so very useful :)
@About healing the enemy: just don't make it a prompt or you will drive me insane, since I do heal enemies rather often, on purpose :) Maybe some modification of the medical UI so it shows WHOM you're healing (a name shown). Otoh beer's going to be UI-less now... :)
1/ Can you send me an example ruleset for UI-less medikit so that I can test it? Or is there something in 0.97b already I can use?
2/ Don't worry, the warning will be non-prompting... something on the medikit GUI which says "Applying to: ENEMY/FRIEND/NEUTRAL/YOURSELF"... not sure about UI-less medikits (I didn't see any yet), maybe I can think of something else... but definitely no prompts, that would drive me crazy too
-
1/ Can you send me an example ruleset for UI-less medikit so that I can test it? Or is there something in 0.97b already I can use?
- type: STR_BEER
size: 0.05
costBuy: 300
costSell: 200
weight: 2
bigSprite: 318
floorSprite: 204
handSprite: 864
hitSound: 120
battleType: 6
medikitType: 2
allowSelfHeal: true
stimulant: 3
stunRecovery: 10
energyRecovery: 20
tuUse: 8
costThrow:
energy: 4
flatRate: true
invWidth: 1
invHeight: 2
listOrder: 4800
Just replace the current one with this, and replace/delete the HitSound since it's a non-existent sound in 0.97B :)
And a more fun item:
- type: STR_CRACK
size: 0.01
requiresBuy:
- STR_CRACK
costBuy: 5000
costSell: 3500
weight: 2
bigSprite: 383
floorSprite: 203
hitSound: 41
battleType: 6
allowSelfHeal: true
medikitType: 3
costUse:
time: 15
energy: -25
morale: -100
health: 15
painKiller: 1
costThrow:
energy: 4
listOrder: 5430
@2: yeah just like you said, but i'd rather see something like: target: {name}, it will be more informative and require less extra strings.
-
I think that some med-kits should be only self use. Instead of current `allowSelfHeal`would be new property:
allowedTargets:
self: true
enemy: false
friend: true
stuned: false
This would be shared with psi-amp. But this would be breaking change. This probably will go with 3.0.
I hope that I could manage finish 3.0 before Christmas (in julian calendar :D) probably hardest part is finish only some details left to do.
-
I hope that I could manage finish 3.0 before Christmas (in julian calendar :D) probably hardest part is finish only some details left to do.
That would be nice. :) I have high hopes for the scripting language. First, I would like to recreate the teleport from the UNIMOD for UFO Extraterrestrials: you throw it, and upon landing it moves you to the place where the teleporter landed. :)
-
I think that some med-kits should be only self use. Instead of current `allowSelfHeal`would be new property:
allowedTargets:
self: true
enemy: false
friend: true
stuned: false
Maybe also:
neutral: false/true ?
-
That would be nice. :) I have high hopes for the scripting language. First, I would like to recreate the teleport from the UNIMOD for UFO Extraterrestrials: you throw it, and upon landing it moves you to the place where the teleporter landed. :)
At some point it will be available, but on humble begging only recoloring and animation (you could change body sprite to another one, e.g. with blood if that part have wounds) will be available. After that in next version I plan exposing more internals of engine to script.
Maybe also:
neutral: false/true ?
Right, this too. It can have some uses over reusing `friend`for them.
-
@2: yeah just like you said, but i'd rather see something like: target: {name}, it will be more informative and require less extra strings.
OK, so the numbers work also with these new types of medikits.
Also, changing the Medikit GUI would be useless for them... so I decided to put the information already on the tooltip.
It will have different colors:
1. enemy = red
2. neutral = orange
3. friend = green
4. yourself = blue (I wanted yellow but couldn't find the color)
Also, there will be additional info if the unit is on the ground (or not).
See screenshots.
What do you think?
-
I'm bit torn. Meridian, you add couple good additions your version, but most of them are UI improvements that I try avoid in my branch.
I think that for today, best solution would be if Dioxine switch to your exe with piratez. I can help you if you want with creating dll less exe similar to my or nightly.
-
I'm bit torn. Meridian, you add couple good additions your version, but most of them are UI improvements that I try avoid in my branch.
I think that for today, best solution would be if Dioxine switch to your exe with piratez. I can help you if you want with creating dll less exe similar to my or nightly.
That's OK.
There is a reason these changes didn't make it to vanilla (yet).
For example some of them change the GUI in a way that doesn't go well with translations (too much stuff)... btw. I didn't even follow the STR_* convention, so that my changes work without any changes in rulesets (only English of course).
The build is basically for my LP only... and for anyone who would like to use the same.
I don't know if Dioxine would want to switch to my build or not... not even sure if that's a good idea or not... hard to say right now.
Anyway, I have one more change for tomorrow and then I will (try to) upload to GitHub.
After that, it would be cool if you could create a single EXE for us.
EDIT:
I found a lot of nice suggestions on the forum, I will wait with publishing before I can sort and implement them
-
The build is basically for my LP only... and for anyone who would like to use the same.
I don't know if Dioxine would want to switch to my build or not... not even sure if that's a good idea or not... hard to say right now.
Not sure myself. I switched to OXCE not only because it's better for modders, but also because it's clean and non-intrusive. While I think most of your additions are very welcome, they're personalized. I might add those as optional 'patch', but the main bugger here is, you either take or leave it. You cannot switch some on and some off, as eg. UFO Extender Accuracy. Whatever I think about your personalized exec (and I really like about 80% of it), enforcing it on everyone, en masse, is not such a great idea. But it's really cool you're doing this. Maybe some reasonably clean and agreeable distribution might be made out of it. Far too soon to decide on everything just yet.
-
I can make some of them optional. Theoretically even all of them.
Which features would you turn off if you had the possibility?
-
Charge available indicator are very useful :D
You could omit digit 0 when useless (003 -> 3)
-
Another simple enhnacement idea, for Manufacturing this time: adding maxEngineers setting to an item manufacture project. It would disallow to throw more Engineers at an item than this setting allows (like Stanisław Lem said, making fun of what he called 'military logic': the fact that a single person needs 200 minutes to dig a hole, doesn't mean that throwing 100 people at this job will result in the hole being dug in 2 minutes; a more likely result is people killing each other with shovels).
Same might be done for research (maxScientists; Lem was talking specifically about research, after all, and using physical work just as an example) - not that important in Piratez, as your number of Scientists is limited any ways, but would be immensely useful for vanilla-enhancement mods, like FMP or X-Ops or Hardmode.
-
Another simple enhnacement idea, for Manufacturing this time: adding maxEngineers setting to an item manufacture project. It would disallow to throw more Engineers at an item than this setting allows
+1
(like Stanisław Lem said, making fun of what he called 'military logic': the fact that a single person needs 200 minutes to dig a hole, doesn't mean that throwing 100 people at this job will result in the hole being dug in 2 minutes; a more likely result is people killing each other with shovels).
Or as I say to our project managers: 9 women cannot give birth to a child in 1 month :D
-
Same might be done for research (maxScientists; Lem was talking specifically about research, after all, and using physical work just as an example) - not that important in Piratez, as your number of Scientists is limited any ways, but would be immensely useful for vanilla-enhancement mods, like FMP or X-Ops or Hardmode.
Actually I think it would be quite useful for Piratez in the context of written documents that need to be read, like The Solar Courier or Govt Documents, or Decrypted Data Disk. I don't think teamwork makes that much sense here.
-
I'm bit torn. Meridian, you add couple good additions your version, but most of them are UI improvements that I try avoid in my branch.
I think that for today, best solution would be if Dioxine switch to your exe with piratez. I can help you if you want with creating dll less exe similar to my or nightly.
I was trying to upload my changes today... but sadly I couldn't even fork your repo Yankes... clicking on fork button only redirected me to my old fork of SupSuper's repo and gave me nothing new.
I then tried connecting, branching, cherry-picking, merging and all that f$%k... only by miracle did I not lose everything! GitHub SUX!!
So, to prevent unwanted accidents, I am posting my work up until now here as ZIP file with 70 patches.
I am not done yet ;-)
EDIT: for anyone who wants to use this... most of my work is PROTOTYPES, not production quality code... there is no support for translation, no support for TFTD, no support for optional features (i.e. turning my stuff on/off), and probably a lot of other "ugliness"... everything is provided "as is"... no guarantees.
-
It bit stupid if fork of my fork create base repo, but we can probably work around this.
If you do it everything correctly, you should have clean fork of OXC without OXCE under:
git remote add MeridianRepo git@github.com:Meridian/OpenXcom.git
Then under two address you can grab my or supsuper changes:
git remote add SupSuperRepo git:https://github.com/SupSuper/OpenXcom.git
git remote add YankesRepo git:https://github.com/Yankes/OpenXcom.git
then you can grab my changes and merge with your master:
git fetch YankesRepo
git merge YanikesRepo/master
Then you can push all changes from your master branch to your repo:
git push MeridianRepo master:Extended
Now you should have new branch (Extended) in your GitHub repo
[ps]
git will ask you for pass each time you try push something, you can avoid this using https://help.github.com/articles/generating-ssh-keys/
-
OK, I think I finally managed to do it properly: https://github.com/MeridianOXC/OpenXcom/tree/oxce2.5b-plus-prototypes
-
Great :)
-
I'm not sure where to go with this suggestion, so I'm putting it here, since it has little meaning for the vanilla.
UFO:Extraterrestrials was a pretty good game. Well, in reality it was sort of bad without a big mod called UNIMOD, but it had some really need UI solutions. I would like to ask if one of them can be implemented.
In UFO:Extraterrestrials there were three "classes" of shooting weapons:
- 1-handed weapons: they work exactly like 1-handed weapons in X-Com - they can be fired with one hand with no penalties and leave the other hand open.
- 1.5-handed weapons: they work exactly like 2-handed weapons in X-Com - they can be used with one hand, leaving the other hand free, but then they receive a penalty.
- 2-handed weapons: no equivalent in X-Com, which is what would be nice to have. Such a weapon, when in hand, blocks both hands - it displays the weapon in hand slot as normal, and a semi-transparent image of the weapon in the other hand slot, to represent this is currently taken.
Why do I want it? Mostly because every time I see a LP with someone firing a Rocket Launcher or a Heavy Flamer with one hand, I feel some of my brain cells die horribly (and probably some kitten somewhere, too). So I would like an option to enforce two-handed weapons to be two-handed, for sanity reasons. Mind you, it's not like I want to do it for rifles and such, only for the really unwieldy weapons.
The way I imagine it is to add a new flag, like blockBothHands: true or whatever. If used, it displays a semi-transparent bigob in the other hand slot and prevents it from being used. If the other hand is already in use, you can't take a blockBothHands weapon and a warning flashes (like with wrong ammo type).
Alternatively, if you think blocking the other hand is too specific or restricting for the X-Com GUI, we can simply disallow firing a blockBothHands weapon when the other hand is occupied, but it could be a little confusing for the player which weapon can be fired and which cannot, without trying it.
-
I think second solution is better because it will allow temporary pickup something else without dropping weapon.
And for current status of my mod. Is very likely that tomorrow I will release new version. It will be still based on old nightly. Next release will be up to date.
-
I think second solution is better because it will allow temporary pickup something else without dropping weapon.
Great, I think so too. But it would require new strings (warning).
And for current status of my mod. Is very likely that tomorrow I will release new version. It will be still based on old nightly. Next release will be up to date.
Oh great! Can't wait.
-
Another small request, if possible... behaviour change for built-in weapons: items with fixedWeapon: true, battle type 0 are never equipped on hand, always in inventory slots, just like they were non-fixed. This can be used to limit carrying space for units.
-
This post is sponsored by this music: https://www.youtube.com/watch?v=JzAektg101M
New version is close to finish, some teaser: https://youtu.be/q0-RwIvLUxw
-
Not sure if it has any practical use, but really looks fun :)
-
Better question is what consequence of this are. That was only trivial test of that everything work as excepted.
-
So I think we are getting into animated sprites with that demo...
- Reaper's head swaying slowly side to side,
- Boomasaurus drooling
- StarGods shimmering...
just some thoughts. I have no idea how to tag the frames for the animations and it makes my brain hurt abit just to think about it. ;)
-
- Reaper's head swaying slowly side to side,
- Boomasaurus drooling
- StarGods shimmering...
- ...Snakemen swaying,
- Mutons flexing,
- Sectoids STILL NOT BLINKING.
:)
-
So I think we are getting into animated sprites with that demo...
- Reaper's head swaying slowly side to side,
- Boomasaurus drooling
- StarGods shimmering...
just some thoughts. I have no idea how to tag the frames for the animations and it makes my brain hurt abit just to think about it. ;)
s*** I thought that nobody will want doing animation for big units and skipped implementing that for them. I need probably add this too,
-
s*** I thought that nobody will want doing animation for big units and skipped implementing that for them. I need probably add this too,
LOL!! Don't do it on my account!! Those were just the first things that came to mind. ;)
-
Better question is what consequence of this are.
Impossible to tell without trying it :)
-
Looks interesting. Could always use more animation options. :)
-
whole week wasted on fighting on different kind of bugs :/
a) my bugs
b) compiler bugs
c) not existing bugs
But I probably squash all of them.
Maybe I manage to release new version in next/this week (depending if you read this today or tomorrow :) ).
Because I don't update to recent nightly and don't introduce breaking changes, I will probably downgrade next release version number to 2.9 .
3.0 will be based on current nightly and will drop functionality that is redundant to or can be replaced by script engine.
-
I'm not sure where to go with this suggestion, so I'm putting it here, since it has little meaning for the vanilla.
UFO:Extraterrestrials was a pretty good game. Well, in reality it was sort of bad without a big mod called UNIMOD, but it had some really need UI solutions. I would like to ask if one of them can be implemented.
In UFO:Extraterrestrials there were three "classes" of shooting weapons:
- 1-handed weapons: they work exactly like 1-handed weapons in X-Com - they can be fired with one hand with no penalties and leave the other hand open.
- 1.5-handed weapons: they work exactly like 2-handed weapons in X-Com - they can be used with one hand, leaving the other hand free, but then they receive a penalty.
- 2-handed weapons: no equivalent in X-Com, which is what would be nice to have. Such a weapon, when in hand, blocks both hands - it displays the weapon in hand slot as normal, and a semi-transparent image of the weapon in the other hand slot, to represent this is currently taken.
Why do I want it? Mostly because every time I see a LP with someone firing a Rocket Launcher or a Heavy Flamer with one hand, I feel some of my brain cells die horribly (and probably some kitten somewhere, too). So I would like an option to enforce two-handed weapons to be two-handed, for sanity reasons. Mind you, it's not like I want to do it for rifles and such, only for the really unwieldy weapons.
The way I imagine it is to add a new flag, like blockBothHands: true or whatever. If used, it displays a semi-transparent bigob in the other hand slot and prevents it from being used. If the other hand is already in use, you can't take a blockBothHands weapon and a warning flashes (like with wrong ammo type).
Alternatively, if you think blocking the other hand is too specific or restricting for the X-Com GUI, we can simply disallow firing a blockBothHands weapon when the other hand is occupied, but it could be a little confusing for the player which weapon can be fired and which cannot, without trying it.
Done.
Usage in ruleset "blockBothHands: true"
Mechanics:
As soon as you click on any action other than Throw... and you have something in the other hand too, a warning (STR_MUST_USE_BOTH_HANDS) will flash.
PS: This restriction applies only to friendly units and mind-controlled enemies/neutrals... doesn't apply to mind-controlled friends, enemies and neutrals. I decided to do this, because AI would probably not be smart enough to drop the item in the other hand.
PS2: the two-handed weapon indicator is not affected by this attribute!
-
PS: This restriction applies only to friendly units and mind-controlled enemies/neutrals... doesn't apply to mind-controlled friends, enemies and neutrals. I decided to do this, because AI would probably not be smart enough to drop the item in the other hand.
Very smart decision, else it'd an apocalypse if suddenly hundreds of AI deployments were broken :)
-
I would prefer teaching AI to handle that situation (drop live grenade to shoot something, getting it back is for noobs :D). But in long run result will be same, only different TU cost.
Btw Meridian when you publish it on github? Because I finished scripting and now I have time to do other things like pulling some of your commits to my branch or helping you with stand alone exe.
-
Btw Meridian when you publish it on github? Because I finished scripting and now I have time to do other things like pulling some of your commits to my branch or helping you with stand alone exe.
I publish immediately (once a day). Everything is on github.
Helping with EXE would be very nice... I don't need it myself, but each time before a new version of PirateZ is released, you could build a latest one for Dioxine.
As for pulling my stuff, I would wait with that, if it's OK with you.
I have only a few more things on my todo list... and then I would make a video with the explanation/presentation of new stuff and would like to talk to you, SupSuper and Warboy about what could go into OXC, what to OXCE and what should stay in OXCE+.
If you want something even before that, I could prepare a pull request with "proper implementation", because currently many features are just prototypes: they are missing support for translation, for TFTD, they are scattered across multiple commits and in general they are sometimes just really dirty.
-
I would prefer teaching AI to handle that situation (drop live grenade to shoot something, getting it back is for noobs :D). But in long run result will be same, only different TU cost.
Thanks for the report on github.
- the blockBothHands flag is now also checked before reaction fire
- but not before berserking (you should still be able to blow yourself to pieces :D)
Currently testing... will upload today or tomorrow.
-
New version 2.9 is ready:
Scripting support in unit graphic (more info in game log with debug on).
`bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version.
New property `refNode` used to shared values between items/solders/armors etc.
Option for setting numbers of melee hits done by AI.
Control space usage of soldiers with 2x2 armors in crafts.
Bug fix and small bump of nightly.
[ps]
I fixed broken download link in mod portal, now you should be able to download it.
-
First tutorial:
How made animation and change torso to something else?
Solution:
armors:
- type: STR_NONE_UC
spriteSheet: TEST.PCK
spriteScript: |
#remember about proper indent! Because of symbol `|` all things that are currently 6 spaces indented will be treated as text
if eq blit_part BODYPART_TORSO; #do we currently draw torso?
set r0 anim_frame; #we set to register0 value of current frame (its start from 0 to infinity or more accurate MAX_INT)
unit.getId r1; #get id of current unit to register1, used to difference animation offset
add r0 r1; #we add id to animation frame
div r0 4; #reduce animation speed by dividing
mod r0 2; #warp it to have only {0, 1} values
offset r0 8 272; #272 is position of new torsos, this operation change possible values {0, 1} to {272, 280}
add r0 i1; #we add rotation of body from input1 arg
ret r0; #we return offset that will be used for `spriteSheet`
end;
add i0 i1; #default behavior
ret i0;
extraSprites:
- type: TEST.PCK
subX: 32
subY: 40
width: 512
height: 720
files:
0: test3.png
Result is now animated A and B over head of solder.
Required file in attachment.
-
@Yankes: on 2.9, I am getting a CTD when "playIntro" is set to true... can you check, if you're getting it too?
-
Look fine for me. I try exe that I posted in my working directory and it run intro without any problems.
[ps]
can you test my version of exe: https://www.mediafire.com/?zbzytnl6s8r69tz if it work or crash?
-
Look fine for me. I try exe that I posted in my working directory and it run intro without any problems.
[ps]
can you test my version of exe: https://www.mediafire.com/?zbzytnl6s8r69tz if it work or crash?
Your version doesn't crash. Strange.
-
Best way is simply compile with debug info and see where crash. And its not strange, I compile using completely different compiler and libraries versions.
Sometimes small difference can easy crash something.
-
Hi Yankes
I am having some trouble getting a properly working binary with xpirates 97D under Debian Linux.
So far I have compiled the 'oxce2.5b-plus-prototypes' branch from https://github.com/MeridianOXC/OpenXcom.git
When it runs I cannot see the latest two handed firearm changes or filtering in the craft crew menu. Other odd thing is I am unable to save and then load. It creates a save game but will not show any save game created by this binary in game for me. I am able to see and load save games in game that was made by other binaries.
I'll attempt to attach my binary if you could see if it works for you or if you could share your known working binary that would be great thanks!
-
Hi Yankes
I am having some trouble getting a properly working binary with xpirates 97D under Debian Linux.
So far I have compiled the 'oxce2.5b-plus-prototypes' branch from https://github.com/MeridianOXC/OpenXcom.git
When it runs I cannot see the latest two handed firearm changes or filtering in the craft crew menu. Other odd thing is I am unable to save and then load. It creates a save game but will not show any save game created by this binary in game for me. I am able to see and load save games in game that was made by other binaries.
I'll attempt to attach my binary if you could see if it works for you or if you could share your known working binary that would be great thanks!
First of all most of this, with you have problems is from Meridian branch. It will be hard to debug someone else code.
Do you used binary based on my branch too https://github.com/Yankes/OpenXcom.git ? (but look out, current version 2.9 is incompatible with xpirates).
Could you prove commit id your binary is build on? Maybe when I will have more free time in this week I will look on your problem.
-
Thank you for the reply Yankes. I have tried compiling your repo https://github.com/Yankes/OpenXcom.git but as you said it does not work with x-pirates.
This is really a problem with Merdian's repo, I was under the impression you are already familiar with x-pirates and hoping you already had a working binary. I'll post in the x-pirate thread https://openxcom.org/forum/index.php/topic,4187.msg58671.html#msg58671
-
I have working (at least I think I have) version at https://www.openxcom.com/mod/openxcom-extended for ubuntu (2.5b is current xpirates).
If it not work in debian then you can grab commit id from readme and compile it yourself. It will lack features from Meridian build but should work (save & load).
If it still not work then its my fault and I probably need fix it fast :)
-
I have working (at least I think I have) version at https://www.openxcom.com/mod/openxcom-extended for ubuntu (2.5b is current xpirates).
If it not work in debian then you can grab commit id from readme and compile it yourself. It will lack features from Meridian build but should work (save & load).
If it still not work then its my fault and I probably need fix it fast :)
PirateZ was able to run with both OXCE and OXCE+ until recently... all my features were optional/nice to have.
Now there is one feature, which is required for PirateZ, which is currently only in OXCE+.
It's this commit (default slot for fixed items): https://github.com/MeridianOXC/OpenXcom/commit/af62ed3fda130df2db7894677df5c52682cc6a2d
Maybe you should cherry-pick it into OXCE, so that PirateZ will still work under OXCE.
-
Right, I forget about this change, but game should still work, not as intended but not crash.
I will need spend some time cherry-pick cherries from your branch :)
-
Just wanted to report a funny experiment that I just did : A torch for Piratez, replacing the electro-flare. It's a light source that you can toss around, and you can club people with it and set them on fire. Partytime!
Item battleType needs to be 10 to make it project light source. The "power" stat determines light distance, as far as I know (didn't try something different from a vanilla flare)
Then I copied the #Bayonet segment section from a rifle
#Bayonet segment
meleeHitSound: 75
meleeAnimation: 4
meleeType: 2 # Was 7 (melee damage), 2 is fire damage
meleePower: 30
meleeBonus:
strength: 0.4
melee: 0.1
accuracyMelee: 110
meleeMultiplier:
flatHundred: 0.5
melee: 0.5
costMelee:
time: 14
energy: 8
flatMelee:
time: true
#segment end
Fire naturally bypasses armor, and has a chance to inflict fatal wounds and flaming status.
(edit: I wanted to share here because only OXCE makes it possible)
-
I think its very smart concept of item.
-
Hi all,
I'm new here so if this is wrong topic please forgive me.
Im using Ubuntu Mate 15.10. When im trying to install libsdl-gfx1.2-4 and libyaml-cpp0.5 apt-get can't find them.
How can i overcome this problem? Do i need to add some repository?
-
sudo apt-get install libyaml-cpp0.5
This command don't work? It work in 14.04 LTS. Do you have other yaml-cpp libs available? You can test is easy typing:
apt-get install libyaml
and not pressing enter but tab. Then it will list all available options for you.
It is possible that you don't have exactly same versions but newer ones.
-
He's using 15.10. The official channels for that version only provide yaml-cpp version 0.5.2 (and a older version like 0.3 if i remember correct).
I don't know if extended has the same problems with that version, but it could easily mean he/she has to resort to either a PPA or a manual build of yaml-cpp.
-
ok, now i have libyaml-cpp0.5v5, libsdl-gfx1.2-5 and OpenXcomEx from mod portal and when i try to run it i get
OpenXcomEx: error while loading shared libraries: libSDL_gfx.so.13: cannot open shared object file: No such file or directory
btw. does OpenXcomEx also supports optons -user/data/config? because when i try to run it with -h , --help or -? i get same error.
-
This error mean that binary need older version of library. Probably best way to avoid this is compile binary yourself.
This will need bit more work (around 4-6 bash commands) but will allow grab other version too (like Meridian version of OXCE).
I can guide you Aldi if you want with this.
-
I built binary and it works now. I had also a little bit confusion with setting up xpiratz but all is up and running now.
Many thanks for advice.
-
Did you use Meridian branch for xpiratz? He adds some gameplay features needed by Dioxine mod (like removing some inventory slots in armores). I do not add them jet to my branch (they will be available in next release).
-
Thanks for info, i'm switching to his branch then.
Another problem occurred..
Now I have two clones OpenXcomExtendedMeridan and OpenXcomExtendedYankes, both set to master and newest XPiratez (0.97D)
I built binary for both. I lunch it with -user and -data pointing to same directories.
On Yankes's repo there is no right hand slot on solider view, so I can arm pirate only in one weapon in left hand, but this weapon works.
On Meridan's repo game saving is not working but pirates have both hands, but meal weapon doesn't work it can only be thrown.
Should I checkout some tag not just master to make it works? or use Yankes's repo with older XPiratez version?
-
I guess most of my problems is ymal-cpp version. I can built it from https://github.com/jbeder/yaml-cpp but what tag should I use? release-0.5.0 or newer?
-
Another problem occurred..
On Meridan's repo game saving is not working but pirates have both hands, but meal weapon doesn't work it can only be thrown.
Should I checkout some tag not just master to make it works? or use Yankes's repo with older XPiratez version?
The master branch in my repo is just vanilla OpenXcom (a copy of SupSuper's repo).
For PirateZ, you need to use the 2.5b branch: https://github.com/MeridianOXC/OpenXcom/tree/oxce2.5b-plus-prototypes
More info here: https://openxcom.org/forum/index.php/topic,4187.0.html
-
What you need to update to move from 2.5 to 2.9? I have all the files, and updated the STR_SOLDIER entry as well.
-
What you need to update to move from 2.5 to 2.9? I have all the files, and updated the STR_SOLDIER entry as well.
Not sure whom was this question addressed, so I'll answer all three I can think of:
1. What do I (=Meridian) need to do to upgrade: I need to be able to compile this whole thing correctly (in vs2015 with c++11). In my endless stupidity, I am still not able to do it. However, Yankes has prepared a recent build (2016-02-13), which you can download also from my thread (https://drive.google.com/open?id=0B8itkFQbhj-YSXZ3YnhsRWdwMzg). I believe he'll gladly help us build it until I figure out how to do it myself.
2. What do you (=Dioxine) need to do to upgrade. Go through list of changes in vanilla I provided somewhere earlier and make sure you're compatible. If you're compatible with that, you should be OK. Yankes didn't introduce any breaking changes between 2.5 and 2.9... and I didn't introduce any changes at all between 2.5 and 2.9.
3. What do they (=Aldi or anyone else compiling on their own) need to do to upgrade... they need to wait for you releasing new version of X-PirateZ and then compile my 2.9 OXCE+ branch (https://github.com/MeridianOXC/OpenXcom/tree/oxce2.9-plus-proto) and use that (instead of 2.5 branch).
-
2. What do you (=Dioxine) need to do to upgrade. Go through list of changes in vanilla I provided somewhere earlier and make sure you're compatible.
Thanks but I can't find it.. perused through this thread, as well as Meridian's Resources thread, no luck. So far seems to be working, though.
-
Thanks but I can't find it.. perused through this thread, as well as Meridian's Resources thread, no luck. So far seems to be working, though.
Here: https://openxcom.org/forum/index.php/topic,3626.msg58480.html#msg58480
-
Thank you very much.
-
I checked out oxce2.5b-plus-prototypes branch and everything seems to works now.
Thanks for help Meridian and Yankes. You are best and fastest tech support I ever met :)
Meridian it would be helpful if could add some note about those branches and maybe this forum link to readme on your repo.
-
I confess that I f*** up stun damage calculation in stun rod. Instead of 100% effective you have random value from 0% to 100%.
This will be fixed in next version (3.0) by introducing new property in damage `ToStunRandom: true` that will be altering how value is calculated.
All damage types except of stun will have true as default.
-
Primed grenade indicator in 2.9 is broken.
Fix here: https://github.com/MeridianOXC/OpenXcom/commit/fcfc7158e12f116a4e2718dd1351da5120291f1f
EDIT:
@Yankes: are you compiling windows executable using Visual Studio 2015 or something else? If using vs2015, could you send/link/share me your entire project including everything? I am totally not capable of doing this right...
-
I using linux build chain: mxe. This is gcc packed and configured to output stand alone exe.
-
I using linux build chain: mxe. This is gcc packed and configured to output stand alone exe.
OK, I think I finally made it. Haleluja.
In other news, I think I may have found another issue in 2.9 while merging some of my stuff: https://github.com/Yankes/OpenXcom/blob/master/src/Battlescape/Map.cpp#L866
The offsets there should probably not include screenPosition anymore, since you have included it in the offset itself several lines above.
I can't test it now, but it looks like something you could easily overlook.
Maybe review the whole section.
-
Thanks, I will look on this.
-
I've just started trying out OXCE recently and have really been enjoying all the extras. Saw the silacoid with the burning fire animation for the first time; very cool stuff.
I also think the feature being able to shoot unconscious units and kill them is a big plus. Is there a way to add a death sound for this in the rulesets? If you are shooting at an unconscious alien, you might be unsure if you hit/killed it since there is no sound. You have to step on it and look at the inventory. Not a major thing, but just curious if it was a feature in the rulesets to change the properties of a corpse.
Speaking of corpses, I saw this thread from a long time ago and it seemed like individualized corpses (for race/gender) were on their way to being added: https://openxcom.org/forum/index.php/topic,523.75.html
What ever happened with that? Is that moddable too with the current rulesets?
Thank you!
-
Is there a way to add a death sound for this in the rulesets? If you are shooting at an unconscious alien, you might be unsure if you hit/killed it since there is no sound. You have to step on it and look at the inventory.
It is possible, but AFAIK it was a conscious decision, because unconscious people don't scream.
-
It is possible, but AFAIK it was a conscious decision, because unconscious people don't scream.
This is true, but in real life you'd be able to tell if you put a bullet in their head haha.
I tried adding a death sound to the corpse in item.rul and that didn't do it. I also tried to use "explosionHitSound" and no luck either (not that I expected that one to do it). Would there be another way?
-
I've just started trying out OXCE recently and have really been enjoying all the extras. Saw the silacoid with the burning fire animation for the first time; very cool stuff.
I also think the feature being able to shoot unconscious units and kill them is a big plus. Is there a way to add a death sound for this in the rulesets? If you are shooting at an unconscious alien, you might be unsure if you hit/killed it since there is no sound. You have to step on it and look at the inventory. Not a major thing, but just curious if it was a feature in the rulesets to change the properties of a corpse.
Speaking of corpses, I saw this thread from a long time ago and it seemed like individualized corpses (for race/gender) were on their way to being added: https://openxcom.org/forum/index.php/topic,523.75.html
What ever happened with that? Is that moddable too with the current rulesets?
Thank you!
This isn't separate sprites but recoloring. And it should work right now. And in future you will have full control over that sprite to show in item (as corpse is only one use case).
-
Any chance for adding function for gibs animation/floorob? Current overkill anim is kewl but some variety would be even better :)
-
Right now different corpse if off the limits but animation of death is fully customizable in 2.9, in 3.0 it will probably affectable by kill weapon.
[ps]
This is true, but in real life you'd be able to tell if you put a bullet in their head haha.
I tried adding a death sound to the corpse in item.rul and that didn't do it. I also tried to use "explosionHitSound" and no luck either (not that I expected that one to do it). Would there be another way?
do you add death explosions? If not it would be hard to get it. Overall at some point I had plans to add screams but now I working on other things and it was push back to other time.
-
This isn't separate sprites but recoloring. And it should work right now. And in future you will have full control over that sprite to show in item (as corpse is only one use case).
Yankes, thanks for the reply. I've actually been playing around with sprite color replacement with the LIVE soldiers and it's worked well using spriteFaceGroup, spriteHairGroup, SpriteUtileGroup and SpriteRankGroup.
But those work for the "armor" rulesets. How do you do sprite replacement for a "bigSprite" (inventory) or "floorSprite" to change a corpse? I tried applying those to the corpse in the item ruleset or even the sprites themselves in that ruleset and I either get an error or no change. Can this be used to change color in the inventory armor as well?
Sorry for all the questions, I'm trying to figure it out myself, but if it's not here in the wiki (https://www.ufopaedia.org/index.php?title=Ruleset_Reference_Nightly_(OpenXcom)) or in a previous thread, it's hard to know where to go.
Overall at some point I had plans to add screams but now I working on other things and it was push back to other time.
Okay, cool. Being able to shoot them at all is already a big plus.
-
But those work for the "armor" rulesets. How do you do sprite replacement for a "bigSprite" (inventory) or "floorSprite" to change a corpse? I tried applying those to the corpse in the item ruleset or even the sprites themselves in that ruleset and I either get an error or no change. Can this be used to change color in the inventory armor as well?
You only define recoloring in armor. After that corpse of unit with that armor should be recolored using definition from its armor. But you need remember to have making colors in graphic of unit and items. If they mismatch then it will not work.
-
But you need remember to have making colors in graphic of unit and items. If they mismatch then it will not work.
Sorry you lost me with that part. What do you mean graphic of unit and items? Doesn't a corpse and inventory screen use the same Battlescape palette that live units do?
If you can post the example ruleset you used to do this I'd appreciate it, but you seem busy so if you don't have time not a big deal.
(https://openxcom.org/forum/index.php?action=dlattach;topic=523.0;attach=6556;image)
-
Yes, they use same palette (with exception of last 15 index in inventory), but they need use exactly same colors to work with recoloring.
Working example is normal solders from OXC, Extended add same recoloring to corpses and inventory items. If it work for unit it should work for items and inventory.
-
look here:
https://falkooxc.pythonanywhere.com/palconvert
the recoloring routine takes one of the colors (horizontal rows) and translates it by adding a fixed number, so say row 4 is recolored to row 7. For your hair recolors to work, both males and females on the spritesheet must have hair composed of one and the same color (row), with no rogue pixels.
-
I think maybe I'm not explaining my problem very well. I understand how to do the color replacement with the armor ruleset, I just don't understand how to carry over those changes for corpses/inventory. See the screen shots and ruleset code below. The first part works for the live units, but once they are corpses the color change stops:
armors:
- type: STR_NONE_UC
spriteFaceGroup: 6
spriteFaceColor: [96, 96, 96, 96, 160, 160, 163, 163] #M0 F0 M1 F1 M2 F2 M3 F3
spriteHairGroup: 9
spriteHairColor: [144, 144, 164, 164, 245, 245, 166, 166] #M0 F0 M1 F1 M2 F2 M3 F3
- type: STR_POWER_SUIT_UC
spriteRankGroup: 5
spriteRankColor: [16, 35, 68, 211, 205, 7]
- type: STR_FLYING_SUIT_UC
spriteRankGroup: 5
spriteRankColor: [16, 35, 68, 211, 205, 7]
EDIT: I deleted the incorrect ruleset code here so it didn't confuse someone who stumbled on this thread and tried to do something similar.
-
First of all, what version of extended you are using? Corpse recoloring was added in 2.9. Previously you have only basic nightly version recoloring (that is you are using now).
-
You cannot auto-recolor Inventory pics.
-
First of all, what version of extended you are using? Corpse recoloring was added in 2.9. Previously you have only basic nightly version recoloring (that is you are using now).
I'm using OXCE 2.9. Is there a ruleset defenition list for OXCE somewhere like there is for the latest nightly wiki? https://www.ufopaedia.org/index.php?title=Ruleset_Reference_Nightly_(OpenXcom)
I see the first post of this thread and the mod site has some more info (https://www.openxcom.com/mod/openxcom-extended), but nothing about sprite recoloring that I saw so I just assumed it used the same rules as the latest nightly to do it.
-
Sorry, game behave a bit different than I though. Because I now testing recoloring scripts this functionality "work for me". I forget that I never implemented recoloring (using properties form basic OXC) for items without scripts :/
Again sorry for confusion.
Work around to enable items and inventory recoloring is adding in armor:
recolorScript: |
unit.getRecolor i0;
add_burn_shade i0 burn shade;
ret i0;
-
Cool, I will try that out. Thanks again.
UPDATE: Yankes, that worked well. Looks great.
UPDATE #2: Question for Yankes or anyone else who might be looking on. I think I already know the answer is no, but can you set a new inventory portrait for a soldier based on his rank? (I'm not talking about color changing script since I assume that isn't doable, I'm talking about using the extrasprite ruleset for the MAN.SPK files.)
If you want to set a different colored armor for the gender/race that is easy. Just modify the extrasprite rulset and switch out the vanilla armor for the image you want ... done.
But could you do this based on the unit's rank? I don't see a way. You would need an if/then statement (not doable in YAML I don't think) and I must be missing it because I can't even find rank as a property in any of the rulesets for XCOM soldiers.
-
Question for Yankes or anyone else who might be looking on. I think I already know the answer is no, but can you set a new inventory portrait for a soldier based on his rank? (I'm not talking about color changing script since I assume that isn't doable, I'm talking about using the extrasprite ruleset for the MAN.SPK files.)
If you want to set a different colored armor for the gender/race that is easy. Just modify the extrasprite rulset and switch out the vanilla armor for the image you want ... done.
But could you do this based on the unit's rank? I don't see a way. You would need an if/then statement (not doable in YAML I don't think) and I must be missing it because I can't even find rank as a property in any of the rulesets for XCOM soldiers.
Right now not. But I think about way to add it.
-
Primed grenade indicator in 2.9 is broken.
Fix here: https://github.com/MeridianOXC/OpenXcom/commit/fcfc7158e12f116a4e2718dd1351da5120291f1f
One more fix for the same indicator on the ground: https://github.com/MeridianOXC/OpenXcom/commit/ef1931cfa104e752ee9958df79ba7621c304aa9e
-
What is the plan for the stun damage randomizer bug? I like how it works now, allowing for hits to have a random secondary stun damage. Maybe leave that extra 0-100% Stun roll be? Or make it optional? Actually while this stunts stun weapons (which I had to compensate by powering them up), it does work great for secondary stun damage.
-
Fix for bug will be new option for each damage part (stun/hp/morale et..) that define that is it randomized.
Stun damage type for defualt will have not random value but other damage types will randomize it.
Sneak peek from next version ruleset:
RandomHealth: false #do calucaltion of final health change use random value.
RandomArmor: false #do calculation of final armor change use random value.
RandomArmorPre: false #do calculation of final armor change use random value.
RandomWound: false #for `true` use original radom system giving `1` to `3` wounds, `false` will give linear value based on `ToWound`.
RandomItem: false #do calculation of value that compare with item armor use random value.
RandomTile: false #do calculation of value that compare with tile armor use random value.
RandomStun: false #do calculation of final stun level change use random value.
RandomEnergy: false #do calculation of final energy change use random value.
RandomTime: false #do calculation of final time units change use random value.
RandomMorale: false #do calculation of final moral change use random value.
-
Maybe one example for explanation:
Current in 2.9:
Cattle prod has base damage 70... meaning range from 0 to 140.
Let's say we roll damage 60.
This 60 roll will not do anything.
Another roll between 0 and 60(or less?) will be done for stun damage.
Let's say the roll will be 13.
Final total stun damage (before armor reduction) will be 13.
New in 3.0:
Cattle prod has base damage 70... meaning range from 0 to 140.
Let's say we roll damage 60.
This 60 roll will not do anything (yet).
Another roll between 0 and 60(or less?) will be done for stun damage. There will be no second roll (by default).
Let's say the roll will be 13.
Final total stun damage (before armor reduction) will be 60.
@Yankes: please correct me if I understood it incorrectly
EDIT: weapons with other damage type than stun will not be affected... they will still have random stun effect (by default)... same as now... for example gauss rifle with power 70 (range 0 to 140) will roll damage 60 and do 60 piercing damage. Then it will do another roll for stun, let's say 13 and do additional 13 stun damage.
-
Exactly.
-
Good. But I will keep Cattle Prod using the current ('bugged') formula, isn't it OP anyway? :)))
-
If you change option, then yes.
-
Hi Yankes!
I was just getting ready to create a mod for stunned corpses.... then I saw this:
" `bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version."
Can you help me out? What would I need to know to get this to work? (just be patient? ) ;)
Cheers, Ivan :D
-
It's still working, I plans to scrap it in 3.0 (or more accurate already did in my local code base) and replace with better functionality.
-
It's still working, I plans to scrap it in 3.0 (or more accurate already did in my local code base) and replace with better functionality.
Ok. So I can set this up now, on 2.9, and just be aware that I'll need to change it down the road at 3.0.
thanks!
-
Is there any possibility of a crash due to having 56 avatars defined? (7 variants). Does it have to be a number divisible by 2?
NVMD, it turned out that the game crashes if you delete the STR_NONE_UC from the list of armors (even if it's not used)
-
Is there any possibility of a crash due to having 56 avatars defined? (7 variants). Does it have to be a number divisible by 2?
NVMD, it turned out that the game crashes if you delete the STR_NONE_UC from the list of armors (even if it's not used)
STR_NONE_UC is used (hard-coded) on few places (even in vanilla, and also in OXCE+).
I can look if we can unhardcode all these places, but it requires some effort.
Why do you want to get rid of this default armor?
-
In short, bacause it is getting in the way with it's hard-codeness, and creating disorder in my armor lists. Also it is linked to the word NONE which I cannot change to, say, UNARMORED beacuse you'll have WEAPON>UNARMORED in each empty craft weapon slot. I had to use a fake entry to circumvent that and I wanted to get rid of this. But nvmd, I blocked it off with a research that doesn't exist so you can only access it in QB. I can also block it off on the list for each race.
However there is a minor problem I'd be happy to see fixed. If you equip a default armor to an unit, the armor selection button says ARMOR> SOMETHING instead of just SOMETHING.
-
Just wanted to chime in here that I've built a mod for PirateZ based on the bigSpriteAlt: functionality of OXCE 2.9. (I hope the jump to scripting in 3.0 doesn't break my brain, but if it does, I'll ask Yankes for help. ;) )
https://openxcom.org/forum/index.php/topic,4424.0.html
Cheers, Ivan :D
-
bigSpriteAlt: functionality of OXCE 2.9.(I hope the jump to scripting in 3.0 doesn't break my brain, but if it does, I'll ask Yankes for help. ;) )
I will supply example script that have same behavior as old functionality. Biggest grain will be that it allow more than one version to choose (e.g. separate sprite for each face/hair color).
-
Small update on current progress.
Right now I'm finishing basic functionality required for new features. Right now only thing left in it is automatic self documentation of scripts.
When I done it I will finally start implementing new features. I expect that will take me around 4 weeks to release 3.0 version.
Some features that should be available in 3.0 (some already implemented, other still in plans):
- items are now available in scripts
- you can get items held in hands of unit (rest of inventory or ground is unavailable)
- custom rulesets properties of items and units available in scripts
- bonus stats will be able to use scripts for calculation of bonuses
- custom recoloring and switching graphic for items
- scripts access to unit reactions and maybe visibility too
- special scripts that will handling unit damage and defense
-
In short, bacause it is getting in the way with it's hard-codeness, and creating disorder in my armor lists. Also it is linked to the word NONE which I cannot change to, say, UNARMORED beacuse you'll have WEAPON>UNARMORED in each empty craft weapon slot. I had to use a fake entry to circumvent that and I wanted to get rid of this. But nvmd, I blocked it off with a research that doesn't exist so you can only access it in QB. I can also block it off on the list for each race.
However there is a minor problem I'd be happy to see fixed. If you equip a default armor to an unit, the armor selection button says ARMOR> SOMETHING instead of just SOMETHING.
OK, I looked at it and it is used on 3 places:
1. OXCE+ "deequip all armor" hotkey... I can change that to "equip a default armor per solder type" (and create that armor out of thin air if necessary)
2. vanilla default for last selected armor... for the right-click in the craft armor screen... I can change that too, but it raises a question how should the right-click work when using multiple soldier types with different supported armors
I.e. let's have soldier type 1 = xcom and soldier type 2 = dogs... both of which have distinct armor types, if I start right-clicking power suits on soldiers... what should happen when I come to dogs? Nothing? Error? Equip power suit on dogs? :)
3. the ARMOR> NONE label is not hardcoded for NONE armor, it is set to any default armor, so if you change default armor to let's say power suits, it will still say ARMOR> POWER SUIT.... I can remove that completely, if you'd prefer as I don't see any real purpose to it.
-
1. Yes, that'd be good. Default armor is always for free anyway, so I can't see any problems.
2. It should work just like when you don't have enough armor sets and try to equip by r-clicking (ignore command).
3. Yes, it would just look cleaner that way.
-
1. Done
2. Done... but please test. It was too much work to remove STR_NONE_UC from all rulesets, so I didn't test it.
3. This can be done without code changes actually, just change translation from this:
STR_ARMOR_: "ARMOR> {0}"
to this:
STR_ARMOR_: "{0}"
Download later in the evening.
-
Hi Yankes,
I managed to compile and run OXCE+ on Kubuntu successfully... using the guide on UFOpaedia.org.
Can you tell me/share how to compile a Windows executable under Linux with everything inside as you do it?
If possible, an idiot-proof guide... I am a bit of a Linux n00b. And by a bit I mean I am a frikkin' amateur.
Cheers,
Meridian
-
one word: `Makefile.mxe` this is make file I used for compiling exe. It require too components, yaml and mxe build chain.
To work properly it need one folder with `openxcom`, `yaml-cpp` and `mxe`.
I add some scripts that I prepared for "one-click deployment" (in case of Linux this is one script :D). You need fix paths and branches in it but overall structure should work for you too.
-
Excellent... worked on first try... thank you.
-
Sorry for stupid question, but where i can find latest version of compiled EXE with OpenXCOM Extended / OpenXCOM Extended+ (include all needed data files).
And what is the difference between OpenXCOM Extended & OpenXCOM Extended+
-
Not a stupid question IMO, but I'm biased as I asked the same thing not to long ago, haha. Here is the response I got. There is some more explanation in the thread this quote comes from as well (plus obviously a ton more info in the thread we're in now).
OXCE is Yankes' OpenXcom Extended version. It opens up alot of features and customization for modders.
OXCE+ is Meridian's Branch of the above, that he coded for use with PirateZ, but it can run without PirateZ, though other mods may not take advantage of its capabilities. You can download it from the first post here: https://openxcom.org/forum/index.php/topic,4187.0.html
As far as downloading the latest version of OXCE:
Current working branch:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended
Download available on mod site (require latest nightly):
https://www.openxcom.com/mod/openxcom-extended
Backup:
https://www.mediafire.com/folder/w07p0ibc985kd/OXCE
Forum thread:
https://openxcom.org/forum/index.php?topic=2915.msg31641#msg31641
-
Sorry for stupid question, but where i can find latest version of compiled EXE with OpenXCOM Extended / OpenXCOM Extended+ (include all needed data files).
And what is the difference between OpenXCOM Extended & OpenXCOM Extended+
There is no download with all data files available at the moment, only EXE file.
I will prepare a full download later today.
As for the changes between OXCE and OXCE+, the full changelog is here: https://openxcom.org/forum/index.php/topic,4187.0.html
-
Thanks alot, and one more question - OpenXcom Extended include all changes/fixes from latest nightly builds of standart OpenXCOM?
-
Thanks alot, and one more question - OpenXcom Extended include all changes/fixes from latest nightly builds of standart OpenXCOM?
Most of them, since it's a few months behind. But the only still missing relevant thing I can think of right now is Soldier Diaries.
-
There is no download with all data files available at the moment, only EXE file.
I will prepare a full download later today.
How about all data files with EXE ? And does it so difficult to place it (EXE + data files) together?
-
How about all data files with EXE ? And does it so difficult to place it (EXE + data files) together?
I deliberately do not add data because my exe was drop in replacement of original exe. You download updated nightly and my exe and every thing woks fine.
Right now because I focus on some complex elements I don't have time to keep with nightlys. When I finish this I will try back to weekly releases that are compatible with master branch. And problem of lack of data with exe will be again not important, but if you still need this data I always add it to first post in this thread.
-
I play OpenXCom a long time, everythin OK (latest nightly)
I drop OpenXcomExPlus29.exe to the game folder and try to run and get error. What i do wrong?
[12-04-2016 18:08:49] [INFO] Data folder is:
[12-04-2016 18:08:49] [INFO] Data search is:
[12-04-2016 18:08:49] [INFO] - C:\Users\user\Documents\OpenXcom\
[12-04-2016 18:08:49] [INFO] - F:\games\openxcom
[12-04-2016 18:08:49] [INFO] - F:\games\openxcom
[12-04-2016 18:08:49] [INFO] User folder is: C:\Users\user\Documents\OpenXcom\
[12-04-2016 18:08:49] [INFO] Config folder is: C:\Users\user\Documents\OpenXcom\
[12-04-2016 18:08:49] [INFO] Options loaded successfully.
[12-04-2016 18:08:49] [INFO] Scanning standard mods in 'standard'...
[12-04-2016 18:08:49] [INFO] Scanning user mods in 'C:\Users\user\Documents\OpenXcom\mods'...
[12-04-2016 18:08:49] [INFO] Mapping resource files...
[12-04-2016 18:08:50] [INFO] Resources files mapped successfully.
[12-04-2016 18:08:50] [INFO] SDL initialized successfully.
[12-04-2016 18:08:50] [INFO] SDL_mixer initialized successfully.
[12-04-2016 18:08:50] [INFO] Attempting to set display to 640x400x8...
[12-04-2016 18:08:50] [INFO] Display set to 640x400x8.
[12-04-2016 18:08:50] [INFO] Loading data...
[12-04-2016 18:08:50] [INFO] Loading font... Font.dat
[12-04-2016 18:08:50] [ERROR] bad conversion
--- posts merged by your friendly neighbourhood moderator-nya~! ---
Replace original OpenXCom font.dat by font.dat from data29.zip, game runs (OpenXcom Extended).
OpenXcom crashed.
-
The executable is simply not compatible with the data files from the latest nightly... because it is not based on the latest nightly, but on an older version (couple of months old).
You need different data files.
-
The executable is simply not compatible with the data files from the latest nightly... because it is not based on the latest nightly, but on an older version (couple of months old).
You need different data files.
For me there is only one problem - font.dat
-
Around February, Warboy introduced a feature called siteType that can be used in alienMissions. Can somebody please confirm if it's already in OXCE or not?
-
Around February, Warboy introduced a feature called siteType that can be used in alienMissions. Can somebody please confirm if it's already in OXCE or not?
It's not.
Anything from Dec 2015 onwards is not in.
-
For me there is only one problem - font.dat
Not surprisingly. OXC nightly changed font handling somewhere around the end of march, which is way later than the point of last merger as indicated by Meridian.
-
OpenXcom Extended also not compatible with Soldier Diaries 1.0 mod as i understand? :(
-
OpenXcom Extended also not compatible with Soldier Diaries 1.0 mod as i understand? :(
1. Soldier Diaries is not a mod anymore, it's part of OpenXcom.
2. Extended doesn't have Soldier Diaries yet (it has only features implemented until November 2015)
-
@Yankes:
Would you mind looking at this bug: https://openxcom.org/forum/index.php/topic,4637.0.html when/if you have some time... I don't understand the dogfight code well enough to find what's causing it. It's nicely reproducible.
Also, if you'll be going through dogfight code, maybe have a look at this too: https://openxcom.org/forum/index.php/topic,4058.msg64352.html#msg64352
This one is unfortunately not reproducible... but many people (including me) experience it relatively often. Maybe you'll see what could be wrong...
-
I will check it out.
-
Q. how do I make the psi-amp special attack deal damage? I managed to get it to work, but it doesn't do any visible damage... do I need to define this by damage bonus and damage alter? I have this so far, but it doesn't work...
psiAttackName: STR_PSI_CUSTOM_ATTACK
accuracyUse: 7
damageBonus:
psi: 0.02
damageAlter:
ToHealth: 1.0
-
Its need be defined like as in normal weapons e.g. you need add power, damage type, hit animation. Aside of that you need add name of attack that enable it in action menu.
-
Ah so it does need a damage type! Ok got it now. But it still does work through walls, right? :)
Iif this works I will redo some of the magic wands etc., psi-amp attack (LoS-only if needed) will be so much better that using bullets! Sweeet. Damn there still are depths of OXCE I didn't discover :)
-
Ah so it does need a damage type! Ok got it now. But it still does work through walls, right? :)
yup
-
Hi Yankes,
I see you've cherry-picked a few of OXCE+ commits into OXCE.
Although, that is the ultimate goal, please don't take anything GUI-related at the moment... I want to refactor GUI-code after OXCE 3.0 (there are missing translations, missing tftd support and a lot of hardcoded colors and constants). Also I want to remove some stuff, which is now either obsolete or turned out not to be useful.
On a similar note... have you started with merging OXC master? Don't want to rush you or anything, just want some indication so that I can plan also my activities a bit better...
Meridian
-
I plan do not touch GUI at all :) I only interested in stealing game mechanic.
And for master, right now I thinking on merging up to 25edd7b.
I already did most of hard work and only left some basic testing and I will probably releasing new version.
Rest of commits I did not merge yet will wait for end of next month.
-
I plan do not touch GUI at all :) I only interested in stealing game mechanic.
And for master, right now I thinking on merging up to 25edd7b.
I already did most of hard work and only left some basic testing and I will probably releasing new version.
Rest of commits I did not merge yet will wait for end of next month.
That's great news! There's a number of features that would be really useful for Piratez or X-Com Files:
- Soldier Diaries
- spawning UFO by mission
- destroyItem command
- defining waypoints (if possible, by soldier stats too)
-
And for master, right now I thinking on merging up to 25edd7b.
I already did most of hard work and only left some basic testing and I will probably releasing new version.
Rest of commits I did not merge yet will wait for end of next month.
25edd7b is 2nd of January, right?
I'll wait a bit more then, still 6 more months to merge :/
EDIT: also to your attention: https://github.com/stiansel/OpenXcom/commit/b8a94c8c581d6a804c9307b18168cb3f476ed739
-
25edd7b is 2nd of January, right?
I'll wait a bit more then, still 6 more months to merge :/
EDIT: also to your attention: https://github.com/stiansel/OpenXcom/commit/b8a94c8c581d6a804c9307b18168cb3f476ed739
Do you have some commit from master that are you interested in? I will for now keep away from commit with AI changes because I will need rewriting my changes to fit new system (it could be trivial or it could be hard). I could grab bit more commits if they merge smoothly.
That's great news! There's a number of features that would be really useful for Piratez or X-Com Files:
- Soldier Diaries
- spawning UFO by mission
- destroyItem command
- defining waypoints (if possible, by soldier stats too)
Right now only Soldier Diaries are in. For rest I need check, "destroyItem" is not because its recent commit and I'm now around 300 commits behind (down form 800).
-
Another question regarding custom psi attacks... the accuracyBonus. What are the defaults for Mind Control and Panic, so I could fine-tune the special attack accuracy?
-
Psi have 4 bonuses:
accuracyUse: 0
accuracyMindControl: 0
accuracyPanic: 20
accuracyMultiplier:
psi: 0.02
One special case is that psi add `accuracyMultiplier` instead of multiplying it. `accuracyUse` is accuracy of special attack.
Another part of equation is defense in armor:
psiDefence:
psiSkill: 0.2
psiStrength: 1
On top of that is fixed bonus of 30 for defense value, distance penalty (1 power per square, can be changed by `dropoff` and `aimRange`).
And finally random chance of 0 to 55 added to attack.
Now after all of this we subtract attack from defense and we have number greater than than zero then attack succeeded.
-
New version 3.0 is ready (based on 2016-01-02 nightly)
Backported game machanic changes from Meridian OXCE+.
Fix stun damage calculation and add random for random option for final stats change by damage.
Refactored script handling.
Script support in reaction atack chance calculations.
Some light handling improvments.
New recolr and replace script graphic option for items.
Option for global events shared by scripts.
Custom tags that have user defined values.
Scripts was improved a lot compared to previous version. First part of game engine that was exposed to script is reaction handling.
You can made unit immune to reaction shoots or reaction shoots have lesser chance to happens if unit is far away.
In next version I plan expose unit damage, visibility and allow do custom actions on turn end.
-
Can someone make the extended version on Android?
Gesendet von meinem SM-T800 mit Tapatalk
-
Finally! Awesome! Grr and I can't really work on the mod now! :) Does your build include all the latest Meridian's changes? Or is it just 'base' and we have to wait for Meridian to make his own build with all non-mechanic extras?
-
Finally! Awesome! Grr and I can't really work on the mod now! :) Does your build include all the latest Meridian's changes? Or is it just 'base' and we have to wait for Meridian to make his own build with all non-mechanic extras?
I steal only game mechanic changes from Meridian (if I miss some I will include in bug fix release).
In some time I will prepare tutorial how to use my scripts and what possibilities are.
-
Hi there,
I'm hurting my head with an idea to work on and I have to point out a feature/request that may be interesting.
In the new ruleset for facilities, could it be implemente an oposite of the following rule?
"requiresBaseFunc: [ ] #List of custom IDs that are require to build this building in base."
My idea is:
"ForbiddenbyBaseFunc: [ ] #List of custom IDs that forbids the building of this building in base."
What are the advantages of having this functionality:
- Wonder facilities: facilities that exclude others or limit their construction to one for each base
- Divergent base evolutions: Which could enable the specialization of bases, giving flavouring to each base and
- Content restriction: Which helps to provide balance in overhuge and overwhelming mods with a lot of content
I am working on a mod for XPiratez and having this functionality changes heavily the way in which I should approach the issue.
Here's a hint:
https://www.youtube.com/watch?v=BGi6Q1pNbS0
-
Yeah, this looks like a very useful thing. One building per base mechanics would have its perks!
-
I probably could add it, right now I don't see any possible complication that it could cause.
-
So, if for example A forbids B... I can just build B first and then A. How are you gonna stop me?
-
So, if for example A forbids B... I can just build B first and then A. How are you gonna stop me?
Give both the same prevention condition and also make them both cause the condition?
-
Give both the same prevention condition and also make them both cause the condition?
Then it should be "unique" instead of "forbid".
-
That depends if you can define multiple "cases" with forbid (as with the example of the requirements of the "study" facility in Piratez extended).
Also important, it depends if a building under construction already gives its trait for such case (forbidding), otherwise you have a hole in the method.
As pointed out by Solarius, if you give facilities a trait of "unique" and at the same time they forbid themselves if the trait "unique" already is given by another facility in the base, you have a unique facility. If some facilities share the same approach, then is a "choose one facility".
BUT (big but), if you also start branding other facilities with a common trait (let's say, branchA) and you forbid them with another one (branchB), you can segregate "families" of facilities, forcing the specialization.
in such conditions you could define "common", "branchA", "branchB".
in terms of game mechanics, you could recycle the system in each branch to your will, isolating their behavior with the rest of the game.
As this last statement is kind of gray I put the idea I've been going around theses days.
"Casino Base".
One unique barrack with space for X people, Y storage and Z work spaces. Branded "unique" and "BranchB". (business HQ). It is the start of the branch and that inmediately forbids "BranchA".
Everything that does go with the flow and breaks the mechanics go branded "branchA", including workshops, quarters and stores.
- Storage becomes dedicated to storing a merchandise or HWP called "Criminal roller" (not transferable). Each give and income but occupies 1 point of storage. Dedicated facilities gives more storage (accommodations).
- Manufacturing becomes specialized, it creates this "merchandise" or transforms other materials. I can use the quantity of "merchandise" to set a minimum value in order to be able to do other stuff. Additional facilities give more manufacturing options, all of them under margins of "control" thanks on the limitation on workshop space (the cash cow can't skyrocket unexpectedly). Additional facilities gives additional manufacturing projects (taverns, variety shows, safe depots, racing garage, parking slot, underground arena, Supervillain comms room,etc). You can tier them, you can bind them by research or by requiring another room trait (sky is the limit).
- Living space becomes a tradeoff, If the base is under attack you need soldiers but the quantity and their equipment impacts on the revenue given by the "merchandise" and the runts working in the projects. Having the merchandise going around during assaults (if HWP) could go directly into a monetary and score loss.
Sickly conceived, yes, I know. But this opens a lot of gameplay options for everyone to conceive ;D
-
After some thoughts I come to conclusion that this property should prevent building other buildings.
If you list some base functionality on forbid list then when this building is build you can't build any building that provide that functionality.
In case if you already have that functionality in base, you can't place building with it on forbid list.
-
After some thoughts I come to conclusion that this property should prevent building other buildings.
If you list some base functionality on forbid list then when this building is build you can't build any building that provide that functionality.
In case if you already have that functionality in base, you can't place building with it on forbid list.
One point to avoid "exploits" is that this should be considered even with the facility "being build", otherwise you could potentially chain the constructions and surpass the limitation. I imagine this complicates things ???
-
One point to avoid "exploits" is that this should be considered even with the facility "being build", otherwise you could potentially chain the constructions and surpass the limitation. I imagine this complicates things ???
In case of OXC "harder" is test for finished buildings :> From game engine you create new thing when you place it on grid. Its simply deactivated until construction is finished.
-
I prepare short tutorial for OXCE scripts. Before expanding it more I would like hear some feedback.
Is it easy to understand? What you would want be more elaborate? Anything is missing?
Tutorial of using scripts
List of available function and vales in script is available in log file with debug mode enabled.
Assume you want add reaction to melee attacks.
Then you can do it in two ways:
#script defined per item
items:
- type: STR_WEAPON_WITH_MELEE
scripts:
reactionWeaponAction: |
if eq action action_hit; #when you hit with this weapon enemy can react to it.
return 100;
else;
return reaction_chance;
end;
#script defined for all items
extended:
scripts:
offset: 1.0
reactionWeaponAction: |
if eq action action_hit; #all items used as melee will case enemies to react.
return 100;
else;
return reaction_chance; #return old reaction chance
end;
every thing after `#` is comments, exactly same as in yaml.
each operation need end with `;`.
`if` is condition operation. It will control what code will be executed.
someScriptCode: |
if OPERATION A B; #OPERATION can be: `lt` - less, `le` - less equal, `gt` - greater, `ge` - greater equal, `eq` - equal, `neq` - not equal
#some code 1
else OPERATION A B; #`else` can have same condition as first `if`.
#some code 2
else OPERATION A B; #you can repeat `else` with test multiple times.
#some code 3
else;
#final case, can be skipped.
end;
`reaction_chance` in `reactionWeaponAction` is current percent chance of enemy to react. You can modifi it and return it:
reactionWeaponAction: |
var int shade; #definition of new variable that can be used by script.
BattleUnit.getTileShade action_unit shade; #getting shade of tile that unit is standing on.
if gt shade 10; #shade of tile is greater than 10.
div reaction_chance 2; #now is two time less chance to react.
end;
div distance 16; #distance between units is in vexels, dividing by 16 give us distance in tiles.
if gt distance 10; #distance is greater than 10 tiles.
sub reaction_chance 30; #subtracting
end;
return reaction_chance;
Now if acting unit is in dark place (unit lighting count!) and 10 tiles away, then enemy units will have only 20% chance to
react (20 = 100/2 - 30).
We can define variables, each variable have fixed type and can't store anything else:
someScriptCode: |
var int var_name;
`var` mean that we create new variable. `int` is type of it, in this case this is number.
`var_name` is name of variable. New variable start with empty value, in case of `int` this is 0.
You can set different value when you define it:
someScriptCode: |
var int answer_to_every_thing 42; #42 is starting value of this variable.
set answer_to_every_thing 13; #it was 42 but now is 13.
We have other types than `int`. They are pointers to object from OpenXcom engine.
someScriptCode: |
var int unit_size;
var ptr BattleUnit unit; #read only pointer to battle unit, this mean unit that you can see in battlescape.
var ptr RuleArmor unit_armor; #read only pointer to armor that unit can use and what is defined in `armors` node.
set unit action_unit; #now `unit` and `action_unit` represents same unit.
BattleUnit.getRuleArmor unit unit_armor; #we get pointer to armor of that unit.
unit.getRuleArmor unit_armor; #shortcut of previous operation.
unit_armor.getSize unit_size; #now we have size of unit armor in variable `unit_size`.
-
Thanks for the tutorials on scripting, Yankes! I do have a question about the ability to do alternate graphics for corpses....
Let me try to think how this would be handled....
Say we want to know from looking at them which were alive (stunned), which were wounded (bleeding), and which were dead.
Could we do this on mouse over? say hover over a corpse floorOb and if its bleeding, it Pops text "wounded" (from a defined STR_WOUNDED definition) or "Stunned" etc,? Or maybe by placing another graphic over it? "ZZzz" for stunned "++++" for wounded, and nothing for dead, etc.
At a minimum could a system of multiple different graphic versions for each item would similar to the altBigsprite that I'm currently using in the Alt_Corpses mod for Piratez? If so, how would that work, could you use the file name convention to define it, ...
Here corpses (bigObs) are dead (b), stunned (bs), and wounded (bw).
Resources/Corpses/PIR_1_b.png
Resources/Corpses/PIR_1_bs.png
Resources/Corpses/PIR_1_bw.png
Alternately could we do some of that weird glowy stuff for the floor objects, ie, flash them blue glow for stunned, red glow for wounded, or even pulse an outline around them? :)
I hope this isn't too much of a ramble, and thanks for the amazing work externalizing these functions.
-
I think in future I could add option for that script could react to if current tile is selected by mouse.
Adding text is impossible and for long time will be. You can only change sprites.
I'm now working on implementing example scripts that will change corpse ground image based on unit state (stunned/wounded/dead).
Whiled doing that I find couple small bugs and missing features needed to do it. In beginning of next week I will release new version that fix that problems and allow crating fully functioning corpse replacer. With that I will post example script that will implements this functionality.
-
Hey Yankes, I was curious if the capability from the nightlies to set the number of waypoints for a guided missiles made it into your latest version of 3.0?
-
Not yet. I will merge recent changes from master at end of this month or beginning of next.
-
I am getting following errors when trying to compile oxce 3.0 in visual studiio 2015... any idea what's wrong?
-
I am getting following errors when trying to compile oxce 3.0 in visual studiio 2015... any idea what's wrong?
sh**, probably bug in VS. I will think how I could avoid it.
[ps]
Ok I manage reproduce it on web compiler and fix it: https://rextester.com/DQH12645
Problem is that VS can't handle static functions (and nested types too) when template pack is expanded.
One way to work around is access it indirectly (`helper` function from that link).
Tomorrow I will prepare special commit that will fix it.
-
I have upgraded my piratez campaign to OXCE 3.0 (without +) and there are some glitches:
1. Clicking on "New project" takes about 30 seconds...
2. When I go into craft and inventory screen to equip my soldiers... after clicking OK to return back... I get crash to desktop
This was just 5 minutes of testing, I'll do more tests in the evening and report them in this post...
EDIT1:
3. when I transfer a soldier from one base to another, after arrival the game seems to get in an endless loop and stops responding
4. actually just letting the time pass on 1hour or 1day results in application hanging quite soon (with 100% CPU usage)
-
1: confirmed.
2 - 4: at leas on my exe and some old piratez version I can't get it. Did you do it on exe compiled by my or yourself?
-
1: confirmed.
2 - 4: at leas on my exe and some old piratez version I can't get it. Did you do it on exe compiled by my or yourself?
On your EXE from the first post, mediafire link.
2/ happens only during equiping in the base, not during the mission... happens also with no mods at all, just go to skyranger, click inventory and click OK... see attached screenshot
[04-07-2016 17:46:52] [INFO] OpenXcom started successfully!
[04-07-2016 17:47:07] [ERROR] Surface MAN_0M50.SPK not found
[04-07-2016 17:47:07] [ERROR] Surface MAN_0M18.SPK not found
[04-07-2016 17:47:09] [FATAL] A fatal error has occurred: code 0xc0000005
[04-07-2016 17:47:09] [FATAL] SymFromAddr failed: 487
[04-07-2016 17:47:09] [FATAL] StackWalk64 failed: 299
[04-07-2016 17:47:09] [FATAL] Crash dump generated at c:\!private\OpenXcom_XPiratez 0.99\user\04-07-2016_17-47-09.dmp
[04-07-2016 17:47:16] [FATAL] OpenXcom has crashed: code 0xc0000005
Extra information has been saved to openxcom.log.
Please report this to the developers.
3/ and 4/ are probably the same issue... game just stops responding after some time... this may be related to my game, also attached... I will try to narrow it down, but it's hard without being able to run it from VS
-
5/ Also, I don't see any games I save in piratez using this new exe.
They are on the harddisk... but not in the Load window :(
Looks like the save is missing the "- piratez" in the "mods:" section... all other mods are there, just the main mod not.
-
https://github.com/Yankes/OpenXcom/commit/dcd84b09cd25a3090e361d8240c9e8251e5c5f29
This commit should fix VS bug. Meantime I'm working on rest of bugs.
-
5/ Also, I don't see any games I save in piratez using this new exe.
They are on the harddisk... but not in the Load window :(
Looks like the save is missing the "- piratez" in the "mods:" section... all other mods are there, just the main mod not.
Some time ago a similar bug was fixed in the main openxcom branch.
https://github.com/SupSuper/OpenXcom/commit/ab552fb0aa7b16ef29f3c178bddcbb0b9546903b
-
Some time ago a similar bug was fixed in the main openxcom branch.
https://github.com/SupSuper/OpenXcom/commit/ab552fb0aa7b16ef29f3c178bddcbb0b9546903b
Thanks, you save me some hours of work to figuring out this bug :)
[ps]
Ok I probably fixed all this bugs. Geoscape hanging is because each research project try find alien with that same name and this cause new line in debug log.
This is VERY slow. Today or tumorrow I will release new version 3.1 with bug fix and some new functionality.
-
The compilation on VS2015 with the fix works now, but when I tried to merge the whole branch I got several errors because of mismatch between std::set and std::vector where getProvidedBaseFunc is used (https://github.com/Yankes/OpenXcom/commit/ad27f8deefb69a3cc8797a138478635f5ed22a7e). Sometimes it's set, sometimes vector.
Also, you may want to rename forbidenBaseFunc to forbiddenBaseFunc, just for spelling correctness before you release 3.1 :)
-
please cherry pick only one commit, I push my working copy of 3.1 and one bug slip in it. Sorry for not saying this clearly previously.
[ps]
https://github.com/Yankes/OpenXcom/commit/5dad96d0c2d955b1df02fdee4516a5dd08f88aeb
I push commits that fix bugs that you encounter. I prefer if you cherry-pick then because I don't finished yet 3.1. It will take me around day to finish it.
-
Finally! Awesome! Grr and I can't really work on the mod now! :) Does your build include all the latest Meridian's changes? Or is it just 'base' and we have to wait for Meridian to make his own build with all non-mechanic extras?
OXCE+ 3.0 is ready here: https://openxcom.org/forum/index.php/topic,4187.0.html
I tried the Commendations too (Draco's package)... looks to be working in general, but I guess it will require a lot of polishing.
Btw. where is the latest official Commendations mod? There are so many different versions floating around :(
@Ivan: I have the Draco's package (https://openxcom.org/forum/index.php/topic,3626.msg56043.html#msg56043) and some medals just say "PlaceHolder"... is this something you have abandoned? or are still working on? or don't know about at all?
-
@Ivan: I have the Draco's package (https://openxcom.org/forum/index.php/topic,3626.msg56043.html#msg56043) and some medals just say "PlaceHolder"... is this something you have abandoned? or are still working on? or don't know about at all?
I believe the latest official Commendations Mod should be in Shoe's thread. (https://openxcom.org/forum/index.php/topic,1718.msg55250.html#msg55250)
Soldier Diaries was merged into the nightlies, so we should be tracking soldier kills etc, now.
I haven't worked on Commendations for a while (about a year or more iirc). There is a "Place Holder" medal iirc that is meant to be just that. If a medal was created after I stopped working on it, the placeholder image is available to fill in. I'm not sure which are using it now or not.
The simple ribbons in Commendations are fine, such as they are, but I think there might have been some discussion on changing the formatting to something else entirely, such as tattoos or gems/jewelry etc. This would require re-coding how the graphics are displayed, etc.
I see Draco has given the commendations a Face lift with Piratey names and Piratey descriptions. I'm not sure if these will fit directly with the current commendations requirements settings. For example, some awards are given for vanilla races/foes. (Also worth noting, I think there might be a lingering bug or two in the awards that Shoes was still sorting out. i.e. awards being given undeservedly, and or awards with two criteria not working correctly.)
Anyway, I think I'll fire up a PirateZ Commendations thread, (https://openxcom.org/forum/index.php/topic,4734.0.html) and try to compile stuff there instead of thread jacking this one.
-
This is script that will work in 3.1 that allow altering corpse graphic based on unit state.
extended:
tags:
RuleArmor:
CORPSE_SWITCH_ENABLED: int
CORPSE_SWITCH_RESOURCES_MOD: RuleList
CORPSE_SWITCH_SPRITE_STUN: int
CORPSE_SWITCH_SPRITE_WOUND: int
CORPSE_SWITCH_SPRITE_DEAD: int
scripts:
selectItemSprite:
- offset: 1
code: |
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
if eq blit_part blit_item_floor;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_STUN;
end;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
end;
end;
end;
return sprite_index;
#usage
armors:
- type: STR_NONE_UC
tags:
CORPSE_SWITCH_ENABLED: 1 #1 enable this functionality for this unit, 0 disable
CORPSE_SWITCH_RESOURCES_MOD: master #to what mod sprites belongs to, `current` mean this mod.
CORPSE_SWITCH_SPRITE_STUN: 39
CORPSE_SWITCH_SPRITE_WOUND: 40
CORPSE_SWITCH_SPRITE_DEAD: 42
I will add some small features to 3.1 and I will release it soon.
-
New version 3.1 is ready:
Base building can now prevent building other buildings.
New tag type that store other mod id.
Option for changing defualt unit light radius.
New functions exposed to script.
Reaction scripts have now information about runing or strafing of target.
-
Some questions about Scripts:
Can I have the Script in its own separate .rul file in the mod folder, or does it need to be included in the .rul file that calls the script functions?
Second: in your corpse replacement script example: Will this same script work to define both FloorObs and BigObs? or would something here:
if eq blit_part blit_item_floor
need to be updated for the BigObs?
-
Some questions about Scripts:
Can I have the Script in its own separate .rul file in the mod folder, or does it need to be included in the .rul file that calls the script functions?
Second: in your corpse replacement script example: Will this same script work to define both FloorObs and BigObs? or would something here:
if eq blit_part blit_item_floor
need to be updated for the BigObs?
right I did it only for FloorObs. You probaby need copy paste this `if` to `end` replaced `getSpriteOffsetFloorob` with `getSpriteOffsetBigobs`.
Add new tags that will store index for bigobs.
And for where script should go. You can place in any `.rul` file, but in each file you need add `extended->tags->RuleArmor`. If armors and script would be in different files you need copy this tags to both files.
-
Okay, I think I have it. Here is my proposed script:
extended:
tags:
RuleArmor:
CORPSE_SWITCH_ENABLED: int
CORPSE_SWITCH_RESOURCES_MOD: RuleList
CORPSE_SWITCH_SPRITE_FLOOR_STUN: int
CORPSE_SWITCH_SPRITE_FLOOR_WOUND: int
CORPSE_SWITCH_SPRITE_FLOOR_DEAD: int
CORPSE_SWITCH_SPRITE_BIG_STUN: int
CORPSE_SWITCH_SPRITE_BIG_WOUND: int
CORPSE_SWITCH_SPRITE_BIG_DEAD: int
scripts:
selectItemSprite:
- offset: 1
code: |
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
if eq blit_part blit_item_floor;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;w
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_STUN;
end;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
end;
if eq blit_part blit_item_floor;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;w
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_STUN;
end;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
rules.getSpriteOffsetBigobs sprite_index temp;
return sprite_index;
end;
end;
end;
add sprite_index sprite_offset;
return sprite_index;
#usage
armors:
- type: STR_NONE_UC
tags:
CORPSE_SWITCH_ENABLED: 1 #1 enable this functionality for this unit, 0 disable
CORPSE_SWITCH_RESOURCES_MOD: current #to what mod sprites belongs to, `current` mean this mod.
# CORPSE_SWITCH_RESOURCES_MOD: master #to what mod sprites belongs to, `current` mean this mod.
CORPSE_SWITCH_SPRITE_FLOOR_STUN: 1001
CORPSE_SWITCH_SPRITE_FLOOR_WOUND: 1002
CORPSE_SWITCH_SPRITE_FLOOR_DEAD: 1003
CORPSE_SWITCH_SPRITE_BIG_STUN: 2001
CORPSE_SWITCH_SPRITE_BIG_WOUND: 2002
CORPSE_SWITCH_SPRITE_BIG_DEAD: 2003
-
You made couple of mistaken, here fixed version:
scripts:
selectItemSprite:
- offset: 1
code: |
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
if eq blit_part blit_item_floor;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_STUN;
end;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
else eq blit_part blit_item_big;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_STUN;
end;
rules.getSpriteOffsetBigobs sprite_index temp;
return sprite_index;
end;
end;
end;
return sprite_index;
How you choose sprite indexs? In what mod you plan add this graphics?
[ps]
New version, previous had bug.
-
Awesome, Yankes! Thanks for spotting those! I knew you would be able to spot any mistakes I made there!
I'll be working the alt-corpses up for Piratez. It will be a stand alone mod, so I'll create my own sprite index for the mod (using "current") as the overall index for sprites in Piratez is very extensive. I'll number the floor obs in the 1000s and the big obs in the 2000s or vica versa.
Also: Now that this functionality is in 3.1 has the "bigSpriteAlt" (and floorSpriteAlt?) been deprecated? Or will it still be there for a while?
-
"bigSpriteAlt" was drop in 3.0.
And for sprites, if you choose value bigger that last index in piratez it should work, but need be less than last+1000 otherwise you will overlap with next mod.
Good thing is that you can easy split resources part into two mods and only define tags in other to have same functionality.
[ps]
btw I can take couple of small request for new functionality. I plan doing couple of small releases (3.2 to 3.4) and one big one 3.5 with merge of current master.
[ps2]
@ivandogovich I update script again because I made bug in it too.
-
Is it possible to change master settings for damage types through ruleset? Manually resetting RandomStun from false to true for every non-stun weapon seems insane; same goes for other settings I would like to add to every weapon dealing certain damage type, like armor piercing for all laser weapons.
-
Is it possible to change master settings for damage types through ruleset? Manually resetting RandomStun from false to true for every non-stun weapon seems insane; same goes for other settings I would like to add to every weapon dealing certain damage type, like armor piercing for all laser weapons.
I could say that in 80% you can do something like that, you will still need change every weapon but only once:
customDefalutStunWeapon: &refStun
damageType: 5
damageAlter:
RandomStun: true
customDefalutStunAPWeapon: &refStunAP
refNode: *refStun #share values from `refStun`
damageAlter:
ArmorEffectiveness: 0.5
items:
- type: SOME_STUN
refNode: *refStun
# `damageType` need be commentout otherwise it will override values from `refStun`
#damageType: 5
- type: SOME_STUN_2
refNode: *refStun
- type: SOME_STUN_3
refNode: *refStun
- type: SOME_STUN_4
refNode: *refStunAP #no with AP
- type: SOME_STUN_5
refNode: *refStunAP
Its need more work than global switch but it lot more powerful. You can share in that way all properties of item.
-
Ack, damagetype overrides? So I need to make the custom shared setting with every possible property set in the damageAlter, including res type, damage roll, blast propagation etc? Since you can't have a weapon with an undefined damage type?
-
`damageType` is only for backward compatibility, this is why he always override `damageAlter`.
Setting `damageType` set default `damageAlter` and `blastRadius`. If you set in one node `damageAlter` and `damageType` then `damageAlter` will override default values from `damageAlter`.
Some example:
customNodeA: &A
damageType: 1
damageAlter: ... #its override damage type 1
customNodeB: &B
refNode: *A
damageAlter: ... #its override damage type 1
customNodeC: &C
refNode: *B
damageType: 2 #overide all changes from B
customNodeD: &D
refNode: *C
damageAlter: ... #its override damage type 2 from node C
If this is too cumbersome to use, I can in next version add `refNode` directly to `damageAlter`. With that you will have something like that:
item:
- type: STUN_ITEM_A
damageType: 5 #I hope this is stun damage value :>
damageAlter:
refNode: *SomePredefinedValuesForStun
- type: NOT_STUN_ITEM_B
damageType: 3
damageAlter: #behave similar to stun but properties not set in `SomePredefinedValuesForStun` will be inherited from `damageType: 5`
refNode: *SomePredefinedValuesForStun
If you really want, you can drop `damageType` and use `ResistType` in `damageAlter`.
-
Ack, unfucking everything line by line still looks less work-intensive than either of this: I'd need to add lines to every item PLUS make script declarations (which is sort of black magic - I have no idea about traps like damagetype overriding damagealter). What would really help is moddable default damage settings. Thanks anyway.
-
Ok, I'm at the point of trying to test the Alt-Corpse script.
I've created a script for both floorobs, and bigobs. For this test, I've trimmed it down to just floorobs by commenting out the bigobs portion.
The script is included in the code section below.
extended:
tags:
RuleArmor:
CORPSE_SWITCH_ENABLED: int
CORPSE_SWITCH_RESOURCES_MOD: RuleList
CORPSE_SWITCH_SPRITE_FLOOR_STUN: int
CORPSE_SWITCH_SPRITE_FLOOR_WOUND: int
CORPSE_SWITCH_SPRITE_FLOOR_DEAD: int
CORPSE_SWITCH_SPRITE_BIG_STUN: int
CORPSE_SWITCH_SPRITE_BIG_WOUND: int
CORPSE_SWITCH_SPRITE_BIG_DEAD: int
scripts:
selectItemSprite:
- offset: 1
code: |
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
# begin testing status of for floor ob graphics
if eq blit_part blit_item_floor;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;w
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_STUN;
end;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
end;
# begin testing status of for big ob graphics
#if eq blit_part blit_item_floor;
# unit.getHealth curr_hp;
# unit.getFatalwoundsTotal curr_wounds;w
# armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
# if eq temp 1;
# if le curr_hp 0;
# armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_DEAD;
# else gt curr_wounds 0;
# armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_WOUND;
# else;
# armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_STUN;
# end;
# armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
# rules.getSpriteOffsetBigobs sprite_index temp;
# return sprite_index;
# end;
#end;
end;
add sprite_index sprite_offset;
return sprite_index;
#usage
#armors:
# - type: STR_NONE_UC
# tags:
# CORPSE_SWITCH_ENABLED: 1 #1 enable this functionality for this unit, 0 disable
# CORPSE_SWITCH_RESOURCES_MOD: current #to what mod sprites belongs to, `current` mean this mod.
## CORPSE_SWITCH_RESOURCES_MOD: master #to what mod sprites belongs to, `current` mean this mod.
# CORPSE_SWITCH_SPRITE_FLOOR_STUN: 1001
# CORPSE_SWITCH_SPRITE_FLOOR_WOUND: 1002
# CORPSE_SWITCH_SPRITE_FLOOR_DEAD: 1003
# CORPSE_SWITCH_SPRITE_BIG_STUN: 2001
# CORPSE_SWITCH_SPRITE_BIG_WOUND: 2002
# CORPSE_SWITCH_SPRITE_BIG_DEAD: 2003
Beyond this, I've got two rulesets, one to define all the sprites, and one to set the tag on the armors, as well as pass the sprite numbers for each state.
For my test, I've trimmed down the corpses to only the "Bandit" faction in my rulesets by commenting out all the others.
I fire up the game. Ensure the mod is on. The game reloads. So far, so good. I decide to use "New Battle" to generate a battle with the Bandit faction, equipping the troops. When I go to start the battle I get a CTD.
Checking the openxcom.log I spot the following error:
[16-07-2016 20:11:24] [ERROR] Error in parsing script 'selectItemSprite' for 'Global Event Script': invalid operation in line: 'w
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;'
Should the "temp" be in that line? Or have I messed up something broader?
I'll attach the mod itself here for trouble shooting too.
-
invalid operation in line: 'w
Do you see this "w"?
unit.getFatalwoundsTotal curr_wounds;w
I see you use first version of this script, I fix couple of bugs in it after posting it.
You probably did not see my edits.
This should be finial version:
scripts:
selectItemSprite:
- offset: 1
code: |
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
if eq blit_part blit_item_floor;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_STUN;
end;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
else eq blit_part blit_item_big;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_STUN;
end;
rules.getSpriteOffsetBigobs sprite_index temp;
return sprite_index;
end;
end;
end;
return sprite_index;
-
Thanks a ton, I knew it was probably something simple. :)
I must have gotten my version messed up.
-
Ok, I tried out the new script (thank you). New Battle Generation consistently crashed for me. The final error in the log is:
[17-07-2016 07:56:13] [ERROR] Map Script not found
So I gave up on trying to use New Battle to test this.
I found an old save with a Bandit Pogrom and loaded it. None of the fallen enemy were showing any of the new sprites, so I stunned a few with the shield. There is a slight, but noticeable pause when the unit completes its death animation before it comes to rest as the final floor ob image. However, I'm still not getting the "Stunned" version of the sprite to display.
I'm attaching a verbose log file to see if this helps. Thanks for helping me trouble shoot this!
Ack! The log file is too large to go up as it is. Let me try to .zip it.
Edit: also including the save file.
-
This is not "my" bug, "[ERROR] Map Script not found". Do you have up to date xpiratez version?
-
This is not "my" bug, "[ERROR] Map Script not found". Do you have up to date xpiratez version?
Yes, I do. I'm up to date with Piratez .99, as well as Meridian's latest 3.2 of 07-16-2106.
Any ideas why the script isn't working to replace the images?
-
Do your game work without this script?
Did this script compile correctly, no errors are reported in log?
Did script run at all, you can test it by adding line `debug_log 1 1;` on top of script after declaration of variables.
If it work then you will get new log info in game log with two "0x1" values.
If you see it do unit have correctly defined tags for it? You can move `debug_log` to other lines to see if this place is executed by script.
Something like that:
debug_log 0 test; #debug accept two ints as argument to pass it to log file.
if eq test 10;
debug_log 1 test;
end;
This is bit rough tool but allow easy see that exactly happening inside script.
It's cap at 500 lines to show because otherwise it could slow game to crawl.
I suggest turn off verbose loging because it easy hide interesting information.
-
Ok, I've been trying a few things.
First I read back through all the posts we have exchanged about this script. One of the things that you mentioned was that the
extended:
tags:
RuleArmor:
tag needed to be in each file mod rulesets. I have added this section to the file where I define the armors:
extended:
tags:
RuleArmor:
CORPSE_SWITCH_ENABLED: int
CORPSE_SWITCH_RESOURCES_MOD: RuleList
CORPSE_SWITCH_SPRITE_FLOOR_STUN: int
CORPSE_SWITCH_SPRITE_FLOOR_WOUND: int
CORPSE_SWITCH_SPRITE_FLOOR_DEAD: int
Despite this, I'm still not getting it to work. Upon trying to load my Bandit Pogrom save, I get a CTD. Nothing shows up in the .log file.
I suspected that maybe my images weren't formatted with the correct palette, so I ran them through Falko's sprite tool to "fix" the battlescape palette. Still had the same issue, so I've been trying to use your debug_log tool, but I get failures everytime I try to use it.
[17-07-2016 18:46:44] [WARN] disabling mod with invalid ruleset: BanditFloor
[17-07-2016 18:46:44] [ERROR] failed to load 'BanditFloor'; mod disabled for next startup
C:\Users\FM\Downloads\XPirateZ_Working\OpenXcom_XPiratez\user\mods/BanditFloorMod/Ruleset/altFloorCorpsesScript.rul: yaml-cpp: error at line 17, column 9: end of map not found
With the corresponding section in the script as follows:
scripts:
selectItemSprite:
- offset: 1
code: |
debug_log 1 1;
I tried putting it on the line directly above "scripts:" too, with the same error.
I guess I'm not using it correctly because I don't understand it. Also, with verbose off, I can't see if the script is loading or not. :(
-
extended:
scripts:
selectItemSprite:
- offset: 1
code: |
debug_log 1 1; #you need 2 space indent there!
Otherwise it will be threaded as next yaml element.
-
Ok, I did a run, with debuglogs salted in the script.
extended:
tags:
RuleArmor:
CORPSE_SWITCH_ENABLED: int
CORPSE_SWITCH_RESOURCES_MOD: RuleList
CORPSE_SWITCH_SPRITE_FLOOR_STUN: int
CORPSE_SWITCH_SPRITE_FLOOR_WOUND: int
CORPSE_SWITCH_SPRITE_FLOOR_DEAD: int
scripts:
selectItemSprite:
- offset: 1
code: |
debug_log 1 1;
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
# var ptr RuleMod rules;
debug_log 2 1;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
debug_log 9 1;
if eq temp 1;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
debug_log 3 1;
if eq blit_part blit_item_floor;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_DEAD;
debug_log 4 1;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_WOUND;
debug_log 5 1;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_STUN;
debug_log 6 1;
end;
rules.getSpriteOffsetFloorob sprite_index temp;
debug_log 7 1;
return sprite_index;
end;
end;
end;
debug_log 8 1;
return sprite_index;
I got this result when I stabbed then stunned a unit (which then crashed the game as has been happening). This unit should return the "stunned" corpse.
From the Log:
[18-07-2016 12:58:52] [DEBUG] Script debug log at 0x9 values: 0x1 0x1
[18-07-2016 12:58:52] [DEBUG] Script debug log at 0x12 values: 0x2 0x1
[18-07-2016 12:58:52] [DEBUG] Script debug log at 0x5d values: 0x9 0x1
[18-07-2016 12:58:52] [DEBUG] Script debug log at 0x7d values: 0x3 0x1
[18-07-2016 12:58:52] [DEBUG] Script debug log at 0xd0 values: 0x5 0x1
[18-07-2016 12:58:52] [DEBUG] Script debug log at 0xfd values: 0x7 0x1
the 0x5 line is the one indicating that it should be the stunnned corpse if I follow the logic in the script.
Could there be a problem with the two "return sprite_index;" lines near the end of the script? is it possible that they aren't getting the value? (and is it stored in "temp" which is used many places in the script for different values? Is there a way I can use debug_log to tell me what value "temp" is at any, or all places in the script?
-
I've refined it a bit more.
The script crashes before debug has a chance to log at the last return sprite_index
rules.getSpriteOffsetFloorob sprite_index temp; #logs here
return sprite_index; #crashes before it writes here.
-
Could you upload whole mod, or at least test part that I could examine exactly what go wrong?
It bit strange that this two lines could crash.
BTW debug_log can output some values like: `debug_log test sprite_index`. Useful is script do something complex and you want know partial results.
Another thing is if you have some suggestions about improvements or additions to scripts?
-
I'll upload the mod and the current save I'm using for testing. I wish I had a vanilla set to pass you for testing but this is all X-piratez.
As part of testing I disabled my separate script.rul file and add the script part directly into the items.rul file that sets the script values for each of the armors.
With the sav file, you have about 4 swipes with the stun baton to take down the ratman in front of you. I just reload and try again.
As far as improvements or additions to these scripts.... I'm still trying to completely understand them, and it feels like I only grasp about 40%....
Like I understood that you said debug_log could accept two ints, but not what they mean. I increased the first number to differentiate them through the script, but just left "1" as the second number. I suppose that just gave it a value to return if it was successful? Also, I didn't realize how the "test" parameter would work with the debugger too.
Some thoughts I had that could be done with these scripts though, how about recoloring the floor sprite to indicate these different states. Gray for dead, pink for wounded, blue for stunned.... etc. Also, with the ability to script for unit morale, it seems possible to set up a marker for "panicked" units much like what XCOM Apocalypse had.
Edit: I also have no clue as to what the initial "- Offset= 1" line is about. ;)
Edit 2: Also, I got errored results inserting "debug_log test sprite_index" :
[18-07-2016 15:48:14] [ERROR] Unknown argument 'test'
[18-07-2016 15:48:14] [ERROR] Error in maching arguments for operator 'debug_log'
[18-07-2016 15:48:14] [ERROR] Error in parsing script 'selectItemSprite' for 'Global Event Script': invalid operation in line: 'debug_log test temp;'
-
I will test it tomorrow.
Offset is order what this script is call if multiple scripts are defined.
`debug_log test sprite_index;` would be working if you define variable `test`.
e.g.`debug_log temp sprite_index;` will show current temp and index.
-
I was looking through the various versions of the script that I've been playing with and I noticed a line:
add sprite_index sprite_offset;
near the end of the script (before "return sprite_index" ) that isn't in your current examples. Is this something that is needed?
-
I was looking through the various versions of the script that I've been playing with and I noticed a line:
add sprite_index sprite_offset;
near the end of the script (before "return sprite_index" ) that isn't in your current examples. Is this something that is needed?
This would be needed if you override default script handling in armor. This would work only for this one not for all armors like global scripts.
Script defined in armor is call with offset 0 and its responsible for default behavior. Your script is called after that (if you set offset to -1 you will be call before it).
`sprite_offset`is not zero only when scripts are call for selecting hand objects sprite. It will hold value of rotation of unit.
[ps]
@ivandogovich I find bug in my code, its why game crash because it not apply correct mod offset to index surface. I will fix it tomorrow.
-
[ps]
@ivandogovich I find bug in my code, its why game crash because it not apply correct mod offset to index surface. I will fix it tomorrow.
Awesome! Thanks for looking into this! (Also, glad I could help you by testing this!)
-
Question: does OXCE (or OXC?) allow adding dropoff to throwing? It's a bit crazy that grenades are as accurate from close by as they are from far-off.
-
Question: does OXCE (or OXC?) allow adding dropoff to throwing? It's a bit crazy that grenades are as accurate from close by as they are from far-off.
From my experience they are the most inaccurate on a distance between 1 and 3 tiles... just try to throw a smoke from inside Bonaventura to the ramp... fails in 50+ % of cases (with max stats).
-
Thats a really good point, Dioxine!
By the way, speaking of grenades, I've noticed something unusual recently with explosions. When I toss out smoke grenades, it appears that the explosion is offset from the grenade object. My impression is that the center of the explosion graphic is located a tile or two down from the grenade location. This also strikes me as a change from earlier versions of OXC/OXCE etc.
Different question: I got to thinking of the Overkill issue, and creating a mod to turn those corpses into a pile of ash. :)
What sort of value should the script test for in BattleUnit.getOverKillDamage ? is it a binary value? 0 = not overkilled, 1 = Overkilled?
So the code might look something like this?
if eq blit_part blit_item_floor;
unit.getOverKillDamage curr_overkill;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
if eq curr_overkill 1;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_OVERKILL
end;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
end;
-
Thats a really good point, Dioxine!
By the way, speaking of grenades, I've noticed something unusual recently with explosions. When I toss out smoke grenades, it appears that the explosion is offset from the grenade object. My impression is that the center of the explosion graphic is located a tile or two down from the grenade location. This also strikes me as a change from earlier versions of OXC/OXCE etc.
Different question: I got to thinking of the Overkill issue, and creating a mod to turn those corpses into a pile of ash. :)
What sort of value should the script test for in BattleUnit.getOverKillDamage ? is it a binary value? 0 = not overkilled, 1 = Overkilled?
So the code might look something like this?
if eq blit_part blit_item_floor;
unit.getOverKillDamage curr_overkill;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
if eq curr_overkill 1;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_FLOOR_OVERKILL
end;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
rules.getSpriteOffsetFloorob sprite_index temp;
return sprite_index;
end;
Unit do not spawn corpse after overkill, but you can modify corpse unit that was close to evaporating simply looking on current hp.
Over kill is amount of current negative hp that surpass durability of "corpse".
overkillDamage = -curr_health - max_health * overKill
-
New version 3.2 is ready. Not many changes, primary bug fix and some improvements for script.
-
Thanks a ton! Its working! :D Now just to clean up all my rulesets. :)
-
From my experience they are the most inaccurate on a distance between 1 and 3 tiles... just try to throw a smoke from inside Bonaventura to the ramp... fails in 50+ % of cases (with max stats).
Stats mean nothing when you try impossible (yet somehow allowed) trajectories - the glitchy projectile engine is to blame. Most of your grenades in such situations get 'caught' by wall edges or soldiers' bodies, or other 3d features. A grenade 'caught' this way immediately drops to the ground (to illustrate this, try throwing a grenade at a treetop - if you hit the very top, it will fall all the way down and become 'stuck' in tree's trunk). Another iron rule is, that if your soldier stands next to the wall's edge, the edge blocks almost full 90 degree arc, not 45 or less as you'd expect - another engine peculiarity.
-
Question: does OXCE (or OXC?) allow adding dropoff to throwing? It's a bit crazy that grenades are as accurate from close by as they are from far-off.
If already is not added then we could add this. How exactly it should work?
-
Since throwing distance is determined by weight of the object and a unit's strength - make the falloff setting affect it via percentage. Then you can just define the max percentage allowed before falloff goes into effect.
-
Yeah something like this... a single global setting with '% range' which sets from which point the dropoff for throwing starts (at 100, no dropoff, at 0, immediately), another setting with '% accuracy at max range', again from 0 (drops to 0 at max throw range) to nominal (100, accuracy as from close range).
Also... Something's not right. I have this code:
damageAlter:
RadiusEffectiveness: 0.1
RadiusReduction: 5.0
If I'm reading this right, @200 Power I should get 20 radius. However, testing it both @222 and @190 Power, I got radius = 11 in both cases. Is the max blast radius capped again in Nightly? And no, I don't want to use FixRadius since I want the radius to be dynamic...
-
I can add this two properties for throwing.
And for radius, it always been caped on 11 for non fixed radius. Looking through history I don't see anyone changing this cap.
I think, I could add new item property that will allow changing this cap.
-
I'd like the cap removed, please. Or better yet, make settable through ruleset (I can up it to 30-40 and be happy)
-
Let the darkness consume you!
https://youtu.be/9oNroA3feEw
I'm now working on bit more realistic lighting in game, biggest difference will be that you need have LOS to illuminate tile.
-
Let the darkness consume you!
https://youtu.be/9oNroA3feEw
Sorry, but what is the difference between this and vanilla? I've watched it, but...
I'm now working on bit more realistic lighting in game, biggest difference will be that you need have LOS to illuminate tile.
That sounds nice.
-
Sorry, but what is the difference between this and vanilla? I've watched it, but...
On flat surface without any obstacles there none difference, but when you have walls and objects, they block light.
You can see when I throw flare to doors, parts of map become black even they still should be in flare glow in normal xcom.
Another is last part when unit circle around stone and everything behind is deep black.
-
On flat surface without any obstacles there none difference, but when you have walls and objects, they block light.
You can see when I throw flare to doors, parts of map become black even they still should be in flare glow in normal xcom.
Another is last part when unit circle around stone and everything behind is deep black.
Ah, OK! I thought you were talking about two different features.
Nice feature, much needed.
-
Let the darkness consume you!
https://youtu.be/9oNroA3feEw
I'm now working on bit more realistic lighting in game, biggest difference will be that you need have LOS to illuminate tile.
Oh god, no - lighting up a UFO by throwing a flair on the roof is like night-tactics 101! :p
-
Ugh. Popping in with more challenges with corpse switches. Bigobs this time. Yankes, can you look this over and see if I'm messing something up?
This is the error I get at a CTD when trying to switch to an inventory view with an corpse that should be switched on the floor.
[26-07-2016 19:03:43] [FATAL] A fatal error has occurred: Invlid surface set 'BIGOBS.PCK' for item 'STR_TRADER_9_CORPSE_BATTLE': not enoght frames
[26-07-2016 19:03:44] [FATAL] Crash dump generated at C:\Users\FM\Downloads\XPirateZ_Working\OpenXcom_XPiratez\user\26-07-2016_19-03-43.dmp
[26-07-2016 19:04:00] [FATAL] OpenXcom has crashed: Invlid surface set 'BIGOBS.PCK' for item 'STR_TRADER_9_CORPSE_BATTLE': not enoght frames
Extra information has been saved to openxcom.log.
Please report this to the developers.
Current version of the script:
extended:
tags:
RuleArmor:
CORPSE_SWITCH_ENABLED: int
CORPSE_SWITCH_RESOURCES_MOD: RuleList
CORPSE_SWITCH_SPRITE_BIG_DEAD: int
CORPSE_SWITCH_SPRITE_BIG_STUN: int
CORPSE_SWITCH_SPRITE_BIG_WOUND: int
scripts:
selectItemSprite:
- offset: 2
code: |
var int curr_hp;
var int curr_wounds;
var int temp;
var ptr BattleUnit unit;
var ptr RuleArmor armor;
# var ptr RuleMod rules;
item.getBattleUnit unit;
unit.getRuleArmor armor;
if neq armor null;
unit.getHealth curr_hp;
unit.getFatalwoundsTotal curr_wounds;
armor.getTag temp Tag.CORPSE_SWITCH_ENABLED;
if eq temp 1;
armor.getTag temp Tag.CORPSE_SWITCH_RESOURCES_MOD;
if eq blit_part blit_item_big;
if le curr_hp 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_DEAD;
else gt curr_wounds 0;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_WOUND;
else;
armor.getTag sprite_index Tag.CORPSE_SWITCH_SPRITE_BIG_STUN;
end;
rules.getSpriteOffsetBigobs sprite_index temp;
return sprite_index;
end;
end;
end;
return sprite_index;
#usage
#armors:
# - type: STR_NONE_UC
# tags:
# CORPSE_SWITCH_ENABLED: 1 #1 enable this functionality for this unit, 0 disable
# CORPSE_SWITCH_RESOURCES_MOD: current #to what mod sprites belongs to, `current` mean this mod.
## CORPSE_SWITCH_RESOURCES_MOD: master #to what mod sprites belongs to, `current` mean this mod.
# CORPSE_SWITCH_SPRITE_BIG_DEAD: 1001
# CORPSE_SWITCH_SPRITE_BIG_STUN : 1002
# CORPSE_SWITCH_SPRITE_BIG_WOUND: 1003
Edit: removing previous attachments now that the issue is resolved. :)
-
It is working for me. Could you run only your mod and piratez and see if it still crash?
-
:)
Yep, when I turned off the Alt- Floor Mod it works. So somehow I have a conflict between them. I think RuleArmor might be defined in both.
-
As you have different mods then `CORPSE_SWITCH_RESOURCES_MOD` need be separated for both modes because graphic is stored in different mods.
Second mod override it ad pointing to wrong one causing crash.
-
I have each mod in separate folders (so they load independently) and they are both set to
CORPSE_SWITCH_RESOURCES_MOD: current.
Can I specify the mod by name then, or by rulefile.rul ? I don't want them to pull resources from the master (piratez in this case)
-
`CORPSE_SWITCH_RESOURCES_MOD` is one unique name.
`CORPSE_SWITCH_RESOURCES_MOD: current` is equal `CORPSE_SWITCH_RESOURCES_MOD: Alt-Corpse-Big` or `CORPSE_SWITCH_RESOURCES_MOD: Alt-Corpse` depending in witch mode you used it. Because this is same name it will be override by second mod. It will be wrong for first mod after that.
You need add `CORPSE_SWITCH_BIG_RESOURCES_MOD` and `CORPSE_SWITCH_BIG_ENABLED` and use it accordingly by script and item definitions.
-
`CORPSE_SWITCH_RESOURCES_MOD` is one unique name.
`CORPSE_SWITCH_RESOURCES_MOD: current` is equal `CORPSE_SWITCH_RESOURCES_MOD: Alt-Corpse-Big` or `CORPSE_SWITCH_RESOURCES_MOD: Alt-Corpse` depending in witch mode you used it. Because this is same name it will be override by second mod. It will be wrong for first mod after that.
You need add `CORPSE_SWITCH_BIG_RESOURCES_MOD` and `CORPSE_SWITCH_BIG_ENABLED` and use it accordingly by script and item definitions.
Ok, great! I wasn't sure if it was something hard coded or not.
Edit: Works like a charm!! Thanks for your patience!!
Also, here is the link for anyone thinking about setting up their own versions of Alternate Graphics for Corpses mods:
https://openxcom.org/forum/index.php/topic,4424.msg60744.html#msg60744
From the packages there you could get a solid working script and some good example rulesets. (Also, there are a few vanilla enemies salted in there, but not all of them)
-
Yankes,
I beg your pardon if I couldn't find it, but I was curious to know if their was an effect that could reduce TU % spent on firing, priming, throwing etc implemented.
In the same tact... is there effects to temporarily reduce or increase firing and throwing accuracy, strength etc.
and
is there such a thing as negative fatal wounds? What I mean exactly is there a healing effect of regeneration where a soldier or monster could rapidly heal over time so long as they weren't killed outright?
and what about sight distance?
I had a few ideas about "combat drugs" or enemy attributes and was curious to know what was currently and a foreseeable possibility
Thanks!
-HH.
-
Yankes, I have a problem with my X-Com Files mod: if I add battleType: 9 (like the Psi-Amp) to the alien deployment, it is ignored by the game and doesn't appear.
Meridian did some investigation and it appears that hostiles can carry battleType=9 items only in their hands (and if both are already full, it's just ignored):
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.0-plus-proto/src/Savegame/SavedBattleGame.cpp#L1300
It was apparently added by you on December 6th 2014:
https://github.com/Yankes/OpenXcom/commit/2df6b7cc454583444d058c465634785a246e7683
Is there a legitimate reason for this? If no, can it be changed?
-
Yankes,
I beg your pardon if I couldn't find it, but I was curious to know if their was an effect that could reduce TU % spent on firing, priming, throwing etc implemented.
In the same tact... is there effects to temporarily reduce or increase firing and throwing accuracy, strength etc.
and
is there such a thing as negative fatal wounds? What I mean exactly is there a healing effect of regeneration where a soldier or monster could rapidly heal over time so long as they weren't killed outright?
and what about sight distance?
I had a few ideas about "combat drugs" or enemy attributes and was curious to know what was currently and a foreseeable possibility
Thanks!
-HH.
There now way to change item use cost right now. My biggest problem with that option is that it would easy cripple game logic when it change its value between first test for cost and moment when units are spend. This is of corse doable but simply cost too much to add this compared to what it give.
For changing accuracy or other bonuses, I have plans to add this in one way or another.
Regeneration is already added, day and night visibility range too.
In near future I will add new script capabilities that will allow adding buffs and debuffs.
Yankes, I have a problem with my X-Com Files mod: if I add battleType: 9 (like the Psi-Amp) to the alien deployment, it is ignored by the game and doesn't appear.
Meridian did some investigation and it appears that hostiles can carry battleType=9 items only in their hands (and if both are already full, it's just ignored):
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.0-plus-proto/src/Savegame/SavedBattleGame.cpp#L1300
It was apparently added by you on December 6th 2014:
https://github.com/Yankes/OpenXcom/commit/2df6b7cc454583444d058c465634785a246e7683
Is there a legitimate reason for this? If no, can it be changed?
Because it would be dead weight and AI will not use it. If you are fine with it, this can be easy change.
-
Because it would be dead weight and AI will not use it. If you are fine with it, this can be easy change.
Yeah, I don't mind if the AI doesn't use it, as long as I can pry it from its cold, dead hands backpack.
-
I know it's not nearly as satisfying, but you could also put an item that isn't spent on research (since you can define that item by item now) and which you can then use manufacture to turn it into a proper psi-amp. Something like breaking the access codes or changing the interface (if it is carried by non-humans).
-
I know it's not nearly as satisfying, but you could also put an item that isn't spent on research (since you can define that item by item now)
Not jet in Extended, I plan add all goodies from master in 2.5
-
Greetings! Could anyone explain the "ERROR: bad conversion" message when I try to launch the OpenXcomEx, please? Playing latest Nightly version. No global modpack is activated...
-
Greetings! Could anyone explain the "ERROR: bad conversion" message when I try to launch the OpenXcomEx, please? Playing latest Nightly version. No global modpack is activated...
1. latest nightly of what? of OpenXcom or OpenXcomExtended... because this is not compatible with latest nightly of OpenXcom
2. did you copy the original game files into UFO directory?
-
Yes, of course, everything is copied and installed correctly. Latest build openxcom_git_master_2016_08_07. It's working just fine since morning.
I downloaded the latest version of openxcomextended for Win from openxcom.com/mod/openxcom-extended.
After that I placed the .exe file to my OpenXcom folder, launched it and got the error message.
What did I do wrong?
Oh, now I see.. I need 2016-01-02 version of the OpenXcom to play OpenXcomEx... Thanks for pointing it out.
-
Yes, of course, everything is copied and installed correctly. Latest build openxcom_git_master_2016_08_07. It's working just fine since morning.
I downloaded the latest version of openxcomextended for Win from openxcom.com/mod/openxcom-extended.
After that I placed the .exe file to my OpenXcom folder, launched it and got the error message.
What did I do wrong?
Oh, now I see.. I need 2016-01-02 version of the OpenXcom to play OpenXcomEx... Thanks for pointing it out.
Needed data are in first post of this thread.
-
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.
-
EDIT: discussion moved here: https://openxcom.org/forum/index.php/topic,4830.0.html
-
Many thanks for the response.
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.
And regarding custom factions in battles: considering the recent changes in the nightlies, which enable civilians to use guns, I guess handling it will be inevitable anyway. Better lay out some general objectives straight away than later.
(Possible implementations: multi-sided battles; savage animals which attack everybody.)
-
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.
Yeah, it's not difficult.
I did this so far, is it sufficient?
Node is called "randomizedItems" and it is a list.
Each item within this list contains:
- position - defult [0, 0, 0]
- amount - default 1
- mixed - default false
- itemList - default empty
Position says on which position the item(s) should spawn.
Amount says how many items should spawn.
ItemList is a list of items to choose from randomly.
Mixed says if one item should be picked and generated amount-times... or if each of the amount-number of items should be picked randomly.
Example below shows:
1. 30 identical items of type either STR_SOME_JUNK or STR_OTHER_JUNK spawned on [6, 2, 0]
2. 5 different items of type 1 or 2 (for example 4 items of type 1 and 1 item of type 2)
- 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?
-
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?
Exactly.
-
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.
I appreciate grouping all proposal in one place, it will be helpful to finding what to do next.
btw "Global damageAlter per type" I will probably never do something that could alter permanently basic damage types. This will simply introduce conflicts between mods and made impractical to create different subtypes for one damage type. I would prefer adding option for multiple global alter types that could be shared between items or different mods. This could be reused too for custom smoke effects on tiles but this will be added in further future :)
-
btw "Global damageAlter per type" I will probably never do something that could alter permanently basic damage types. This will simply introduce conflicts between mods and made impractical to create different subtypes for one damage type. I would prefer adding option for multiple global alter types that could be shared between items or different mods. This could be reused too for custom smoke effects on tiles but this will be added in further future :)
IMO trying to avoid conflicts between mods is a pipe dream - mods are conflicting and always will. But naturally you know the best how to adress that. But to be frank, lack of freely defined inheritances is the biggest pain in the ass (yaml anchors do very poorly in that aspect). However custom globals that don't touch the Holy 10 Damage Types are fine too.
-
However custom globals that don't touch the Holy 10 Damage Types are fine too.
You mean enabling global damageAlter per types, but only for custom types?
Yeah, it could work.
-
You mean enabling global damageAlter per types, but only for custom types?
Yeah, it could work.
Right now I see this different, you create new "default" based on original and after that you use it as you fit.
-
Quick question....
Is there definable and default inventory layouts for armor?
That is to say, if I had a guy with no armor on basically just a jumpsuit a soldier could have basically no space but his hands while a guy in crazy web gear or powered armor could have a ton more inventory space.
Is this possible? Pipe dream?
thanks!
Edited because of another question.
Is there an option for when being hit with a projectile weapon that doesn't penetrate armor to deal a fractional amount of stun damage instead?
-HH
-
Piratez does have a hack that allows to vary inventories based on armors: You define the largest one as the inventory, then armors with smaller inventories get "black squares" items that cover up the slots that you don't want the armor to have. Sounds weird, maybe, but it works pretty well as far as the user is concerned.
Extended allows you to define armor penetration (ie ignore a % of armor) and to have multiple types of damage, so it might be possible. If not, I expect Yankes' answer will be: Scripts! ;)
-
Cool,
Thanks Arthanor!
I'll have to pick through code/ script to figure it out... If I understand right you could have API (armor piercing incendiary), or HEIAP(High-explosive incendiary/armor-piercing) rounds. Fuck. Yeah.
I'll let yankes chime in.
Now to hope for an airstrike mod.
I'd love to designate a target with a laser and then x turns later it gets a paveway hammered on top of it... that would be sweet.
-HH
-
Yankes, when can we expect an update to newer nightlies?
It's not that I'm impatient, I would simply like to know, in order to plan my work better.
-
Yankes, when can we expect an update to newer nightlies?
It's not that I'm impatient, I would simply like to know, in order to plan my work better.
I plan do two releases without it (2.3 and 2.4) and after that I will do 2.5 that primary focus will be merges (with nightly and some functionality from Meridian branch).
2.3 is now half done, I finished new lighting and now I start working on my version of custom visibility. After that I will add some small functionality requested here.
Hard to say how much exactly time will take to do 2.3 and 2.4, I guess that will take around 1 month to 2.5 and merge with nightly.
-
Like a flashlight?
I wait with baited breath.
-
Like a flashlight?
I wait with baited breath.
I do not jest check if this will be possible (aka how many changes is needed to remove all glitches caused by this). But I still plan do this in 2.3.
-
If you do I'll send you a fruit basket...
;D
-
A short question on scripts:
Is it possible with them to define secondary explosions?
Example: A demolition pack is lying around and hit by a grenade. The grenade then triggers the demolition pack to explode with its normal strength.
-
A short question on scripts:
Is it possible with them to define secondary explosions?
Example: A demolition pack is lying around and hit by a grenade. The grenade then triggers the demolition pack to explode with its normal strength.
Right now you can't. In future it will be probably possible.
-
using the latest nightlies and oxce i seem to get a crash upon display of the cryssalid weapon icon from terror.png be it from debug mode or MC, other 3 terror units show correctly. bug?
-
lasted nights aren't supported. Correct data need by extended is in first post of this thread.
-
quoted from the first post:
Download available on mod site (require latest nightly):
https://www.openxcom.com/mod/openxcom-extended
perhaps just edit that line?
Great work though! I LOVE all the new fuctionality
-
Right, this line is not accurate right now but I plan fix it in near future by making its true again.
Probably most important line in readme is "OpenXcom date: Nightly 2016-01-02" this is exact version of nightly that Extended was build on.
-
I have a functionality request.
Auto shot weapons with long bursts increase their accuracy per shot after the first 3 shots by a few percentage points with each shot.
hopefully to simulate correcting or " walking" the fire onto a target.
so as an example you have an LMG with a 8 shot burst starting with a base accuracy of 25% and moving up ...all these numbers are hypothetical. so it looks like
25/25/25/28/31/34/37/40
thoughts?
-
@HelmetHair - the increasing accuracy is somewhat doable with the changes to make shotgun pellets configurable in OXCE+. The old behavior was that the pellets were kind of like an auto shot that decreased in accuracy after each one, and the amount that it decreases can now be set it the ruleset. Make it a negative number and voilà, increasing accuracy shot, as long as you're okay with no bullet travel time and setting autoShots to 1 with shotgunPellets equal to the number of shots you want.
-
Right, this line is not accurate right now but I plan fix it in near future by making its true again.
Probably most important line in readme is "OpenXcom date: Nightly 2016-01-02" this is exact version of nightly that Extended was build on.
Currently, this version of the nightly is unavailable. Would it be possible to link a copy in the first post?
What I did to get extended running ( and I'm going to produce a video on this for tutorial purposes unless its not correct ) is:
- use a recent nightly,
- copy in the Data file from the first post,
- copy over original files from steam,
- copy in the latest OXCE executable.
The game launched OXCE when I did that, but I didn't try to check it for bugs (like chryssalid weapon bug).
Please let me know, Yankes, if those previous steps are incorrect.
-
-
@HelmetHair - the increasing accuracy is somewhat doable with the changes to make shotgun pellets configurable in OXCE+. The old behavior was that the pellets were kind of like an auto shot that decreased in accuracy after each one, and the amount that it decreases can now be set it the ruleset. Make it a negative number and voilà, increasing accuracy shot, as long as you're okay with no bullet travel time and setting autoShots to 1 with shotgunPellets equal to the number of shots you want.
I would personally do not touch "shotgun" mechanic and add new thing to it. It can't have explosive ammunition and flying projectiles. It should be rewritten from the scratch to be usable.
For the feature itself, there is barley difference between flat chance for each shoots and increasing chance for each shoot. Nobody will notice it and over all effective of weapon will be same (of corse if we assume that average chance of each weapons is same).
Currently, this version of the nightly is unavailable. Would it be possible to link a copy in the first post?
What I did to get extended running ( and I'm going to produce a video on this for tutorial purposes unless its not correct ) is:
- use a recent nightly,
- copy in the Data file from the first post,
- copy over original files from steam,
- copy in the latest OXCE executable.
The game launched OXCE when I did that, but I didn't try to check it for bugs (like chryssalid weapon bug).
Please let me know, Yankes, if those previous steps are incorrect.
-
You do not need current nightly only data folder from first post.
Simply extract "data.zip" to destination folder where you want have extended version.
Extract exe to that folder. Copy UFO or TFTD to correct subfolders and after that it should work.
-
For the feature itself, there is barley difference between flat chance for each shoots and increasing chance for each shoot. Nobody will notice it and over all effective of weapon will be same (of corse if we assume that average chance of each weapons is same).
I said the numbers were hypothetical. So what if we increase the chance more, and from every shot from the beginning? that would be noticeable I would think and changes the chanches a little.
25/30/35/40/45/50/65/70
The effectiveness would increase with implementation of autoshot reaction fire and would be noticeable over time if balanced correctly I believe.
-
If you have that big step then this weapon become frustrating in use. Not mentioning losing lot of ammo on first shoots.
-
Are you trying to tell me that you don't like the idea because you think I am asking you to replace the existing auto shot?
That is not the case.
or
is it because of the hypothetical numbers I have listed? they are just a silly example to try to explain the idea.
perhaps I should explain the reasoning better and maybe I should of instead be asking for an additional new fire mode... let's call it long burst.
A light machine gun such as the SAW usually has a very large ammo capacity so wasting ammo is less of a frustration ingame.
With a weapon of this type the idea is a trade off of accuracy for volume of fire. The reason is for a slightly better reflection and viability of common real world tactics like suppressive fire and overwatch.
Suppressive fire, used to deny an enemy vision or mobility and over watch is to protect or warn men from threats they might not see.... I know you know this, but I'm writing it out for my own benefit.
Most of this will be accomplished already through improvements I belive are planned on existing auto fire.
However, why I am asking for an incremental increase in accuracy is that when you shoot a machinegun; the results of your fire can give clues on where to aim to hit what you want.
-
I simply think this is not worth effort. Answer one question, what is difference in long run between 10/20/30/40/50 and 30/30/30/30/30?
-
I simply think this is not worth effort. Answer one question, what is difference in long run between 10/20/30/40/50 and 30/30/30/30/30?
If I understand correctly it was about difference between 30/40/50/60/70 and 30/30/30/30/30.
Which is a bit of a difference.
But I agree, it's just a nice to have, maybe after OpenXcom 5.0 is out :)
-
I simply think this is not worth effort. Answer one question, what is difference in long run between 10/20/30/40/50 and 30/30/30/30/30?
Expected number of landed hits:
1.5 for either configuration
Chance to fail to land a hit:
with 10/20/30/40/50: 0.9*0.8*0.7*0.6*0.5 = 0.1512 ~ 15%
with 30/30/30/30/30: 0.7^5 = 0.16807 ~ 17%
Chance to land all shots:
with 10/20/30/40/50: 0.1*0.2*0.3*0.4*0.5 = 0.0012 ~ 0.12%
with 30/30/30/30/30: 0.3^5 = 0.00243 ~ 0.24%
Alright, it's not that different, but it is different. The results will also vary for other numbers of hits, but those are more complicated and I'm at work. The point is, although both weapons have the same expected number of shots, one is more reliable to land a hit, while the other is more likely to land many hits. We tend to just consider averages (average outcome is the same, everything is the same), but there's more to distributions of numbers than that.
Now is it worth the extra coding? I can't tell because my coding for OXC has been minimal and it would be a lot of work for me (discover how to add new ruleset item properties, amongst other things). Using a simple quadratic formula like we have for damage scaling, but instead defining chance to hit as "F*(a + b*i + c*i^2)" where "i" is the shot number in the autoshot (so i = 2 means the 2nd shot) would enable one to define the effect of "walking your shot" (or alternatively, recoil messing up with your aim on rifles, thus decreasing accuracy as more shots are fired by defining negative parameters, or both) for autoshots.
-
If I understand correctly it was about difference between 30/40/50/60/70 and 30/30/30/30/30.
Which is a bit of a difference.
Then this would be equal comparing two weapons that have 50 and 30 accuracy.
I ask about that have similar performance.
Expected number of landed hits:
1.5 for either configuration
Chance to fail to land a hit:
with 10/20/30/40/50: 0.9*0.8*0.7*0.6*0.5 = 0.1512 ~ 15%
with 30/30/30/30/30: 0.7^5 = 0.16807 ~ 17%
Chance to land all shots:
with 10/20/30/40/50: 0.1*0.2*0.3*0.4*0.5 = 0.0012 ~ 0.12%
with 30/30/30/30/30: 0.3^5 = 0.00243 ~ 0.24%
Alright, it's not that different, but it is different. The results will also vary for other numbers of hits, but those are more complicated and I'm at work. The point is, although both weapons have the same expected number of shots, one is more reliable to land a hit, while the other is more likely to land many hits. We tend to just consider averages (average outcome is the same, everything is the same), but there's more to distributions of numbers than that.
Fully agree, there are different but is this difference big enough to be something more that some kind of flavor?
Now is it worth the extra coding? I can't tell because my coding for OXC has been minimal and it would be a lot of work for me (discover how to add new ruleset item properties, amongst other things). Using a simple quadratic formula like we have for damage scaling, but instead defining chance to hit as "F*(a + b*i + c*i^2)" where "i" is the shot number in the autoshot (so i = 2 means the 2nd shot) would enable one to define the effect of "walking your shot" (or alternatively, recoil messing up with your aim on rifles, thus decreasing accuracy as more shots are fired by defining negative parameters, or both) for autoshots.
Implementing this is not problem, 90% code would be boilerplate needed to propagate valuer form ruleset to place where accuracy is calculated.
Its simply too shallow, there no gameplay there. Proper version of this should look like:
a) Your accuracy affect positive bonus per shoot (your good eye allow you fix your aim).
b) Your strength affect negative bonus per shoot (your steel grip don't move when you split hot lead).
c) using one hand for two hand weapon give you 0 accuracy after first shoot (Rambo exists only in moves).
But this would need lot more work.
-
Yes, I agree that the difference doesn't affect gameplay much, but over 10-20 shots (not uncommon in XPiratez), seeing the last few shots always hit instead of everything being scattered equally could be more satisfying. Also seeing rifles with multiple shots deteriorate as the autoshot goes would be funny. It does contribute to the experience even if it doesn't affect the stats much. Even better if somehow hit location of the previous bullet can be factored in, maybe reusing some code of the shotgun fix.
I also agree that a deeper implementation would be much more interesting. It would help further diversifying if the a, b, c coefficients I suggested could themselves depend on strength, firing accuracy and setup (flying makes recoil worse as you have nothing to stabilize against, kneeling makes it better as you are braced). But constant coefficients are a first (baby) step that already enables a little bit of something (and might be able to placate the request, as I have seen it multiple times already).
As I think that changes of distribution do affect player experience, I just wanted to chime in and support the idea. I fully understand why it isn't (and shouldn't) be a priority. But it shouldn't be entirely dismissed either. As Meridian said, for 5.0! ;)
-
Thank you,
to you both.
-
Yankes,
I have a feature request. I'm pretty sure that this is not anything anyone else but me would want... but whatever!
I would love to see smoke that causes damage, smoke that is rapid stunning, smoke that causes panic/berserk state, smoke that robs TUs, more smoke density or visibility states, and
So basically... trick smoke and improved smoke behavior.
The reason I am asking is because of some of the great possibilities that are forthcoming with features like armed civilians and I feel that more types of smoke could lead to some cool stuff.
So we can have things like a SWAT cop throw a CS grenade into a building and smoke out sectoids or We can have alien enemies that use poison gas a la Signs.
We could better simulate toxic smoke or fumes from burning chemical barrels.
There would be a whole range of things that would be wonderful and add depth to the battlefield.
Thoughts?
-HH
-
Yankes,
I have a feature request. I'm pretty sure that this is not anything anyone else but me would want... but whatever!
I would love to see smoke that causes damage...
That's easy, just play the dos version and launch some incendiary rounds ;)
-
That's easy, just play the dos version and launch some incendiary rounds ;)
(https://www.troll.me/images/brick-tamland/oh-you.jpg)
;D
-
Yankes,
I have a feature request. I'm pretty sure that this is not anything anyone else but me would want... but whatever!
I would love to see smoke that causes damage, smoke that is rapid stunning, smoke that causes panic/berserk state, smoke that robs TUs, more smoke density or visibility states, and
So basically... trick smoke and improved smoke behavior.
The reason I am asking is because of some of the great possibilities that are forthcoming with features like armed civilians and I feel that more types of smoke could lead to some cool stuff.
So we can have things like a SWAT cop throw a CS grenade into a building and smoke out sectoids or We can have alien enemies that use poison gas a la Signs.
We could better simulate toxic smoke or fumes from burning chemical barrels.
There would be a whole range of things that would be wonderful and add depth to the battlefield.
Thoughts?
-HH
Other people ask for this too. Right now its on my "far" todo list (far as in far future :>).
-
I think the Craft Screen in OpenXcom Nightly is much better than in OXCE. What do you think?
-
I think the Craft Screen in OpenXcom Nightly is much better than in OXCE. What do you think?
The screen in OXCE in more tightly spaced, because it can support 4 gun slots... unlike OpenXcom nightly, which has only 2 slots maximum.
-
Wrong order in UFOpedia
-
Erhm.. ufopaedia articles have their own listOrder to sort them. It is in no way related to the listOrder of the baseFacility. Have a look here (https://www.ufopaedia.org/index.php/Ruleset_List_Order_(OpenXcom)#Ufopaedia).
-
How I see, the listOrder in the facilities is related to UFOpedia articles. Look on the ordered and unordered (default) screens.
-
I do not touch (at least consciously) order handling of articles in ufopedia, there is difference between OXC and OXCE? (this screens are from different versions? with exactly?)
-
I do not touch (at least consciously) order handling of articles in ufopedia, there is difference between OXC and OXCE? (this screens are from different versions? with exactly?)
How I realize, there are no differents between OpenXcom 1.0, OpenXcom nightly and OXCE in this situation. Both OpenXcom-s have same behaviour like OXCE.
-
Is there a possibility to define custom "Throwing Sounds" in OXCE?
So that different items (grenades) make a different sound when they fly through the air.
-
Is there a possibility to define custom "Throwing Sounds" in OXCE?
So that different items (grenades) make a different sound when they fly through the air.
Not sure if it helps, but you can design a 1 bullet weapon which disappears after shooting and give it arcing shot... That's how many weapons work in Piratez. Then you can have custom fireSound.
EDIT: I forgot, but you'll probably have to add max range too.
-
Is there a possibility to define custom "Throwing Sounds" in OXCE?
So that different items (grenades) make a different sound when they fly through the air.
Doable, but it will need wait because my queue is full right now.
-
Doable, but it will need wait because my queue is full right now.
No problem, I will do it with the method Solarius suggested.
-
Yankes,
would you be willing to share your feature queue? I'm having a shit week and need something to smile at.
-HH
-
Not sure if it helps, but you can design a 1 bullet weapon which disappears after shooting and give it arcing shot... That's how many weapons work in Piratez. Then you can have custom fireSound.
EDIT: I forgot, but you'll probably have to add max range too.
Good idea.
Is the maxrange always a fixed value, or can I define it as strength dependent?
Something like:
maxRange: 0.5* strength
-
Yankes,
would you be willing to share your feature queue? I'm having a shit week and need something to smile at.
-HH
This week releasing version 3.3 with:
new lighting (next week will I will probably spend on optimization of this based of people feedback)
scripted visibility
option for reserving more space for mod in common sets like HandOb
I had plans to add some other small features but because other take me too much time to finish, I push it to next release.
This was global throw properties and directional lights/flashlights.
In 3.4 I plan add scripts that will be able directly change state of unit (it will be call at end of each turn or when unit get hit).
After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.
Hard to say when 3.4 and 3.5 will be ready, usually my prediction miss a lot.
Good idea.
Is the maxrange always a fixed value, or can I define it as strength dependent?
Something like:
maxRange: 0.5* strength
Right now its fixed value.
-
Great news, Yankes!
Will 3.3 include newer nightlies?
Is the maxrange always a fixed value, or can I define it as strength dependent?
AFAIK it's not possible yet. Unless Yankes could write a script or something.
-
Great news, Yankes!
Will 3.3 include newer nightlies?
AFAIK it's not possible yet. Unless Yankes could write a script or something.
After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.
This mean that 3.3 will still based on old nightly.
-
This mean that 3.3 will still based on old nightly.
Right, I thought it could be something half-way. But nevermind, thanks!
-
After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.
I'd like to ask for some time (cca 1-2 months) between updating OXCE to latest nightlies (3.5) and picking stuff from my branch (maybe 3.6?).
I'd like to review all my commits, make a new branch and prepare new commits worthy picking and maybe even going to vanilla.
The cleanup would include:
- full translation support
- full interface support (i.e. separate ruleset for colors and similar stuff on new GUIs)
- full TFTD suppport
- merged multiple commits together (like original commits + its bugfixes)
- reorder commits a bit for easier cherry-picking
- split some commits (into OXC-compatible part and OXCE-extension)
- etc.
Basically I'd like to make a branch, which wouldn't be called "prototype" anymore... but I need OXCE 3.5 (with latest nightlies) for this work... for which I am waiting patiently, no rush.
-
I'd like to ask for some time (cca 1-2 months) between updating OXCE to latest nightlies (3.5) and picking stuff from my branch (maybe 3.6?).
I'd like to review all my commits, make a new branch and prepare new commits worthy picking and maybe even going to vanilla.
The cleanup would include:
- full translation support
- full interface support (i.e. separate ruleset for colors and similar stuff on new GUIs)
- full TFTD suppport
- merged multiple commits together (like original commits + its bugfixes)
- reorder commits a bit for easier cherry-picking
- split some commits (into OXC-compatible part and OXCE-extension)
- etc.
Basically I'd like to make a branch, which wouldn't be called "prototype" anymore... but I need OXCE 3.5 (with latest nightlies) for this work... for which I am waiting patiently, no rush.
Ok, no problem. I think if you wait for 3.5 I will skip thing I want do in 3.4 and start right now with 3.5 (I could use 3.4 number for that but I prefer "round" version number for that milestone :D).
-
Ok new version 3.3 is ready:
New light system.
Option for reserving more space for mod in common surface/sound sets.
Visibility scripts that determine visibility of targets.
I mostly interested in how my new light system is performing on peoples machines.
-
FYI, I got many conflicts in rather sensitive functionality, so OXCE+ will be updated a bit later (2-3 weeks depending on my time allowance).
I will need to revert, reimplement an retest night vision, heat vision and psi vision.
On the bright side, I have cherry-picked the option to increase modOffset for mods, so at least that can be implemented in XFiles/XPiratez and tested.
-
FYI, I got many conflicts in rather sensitive functionality, so OXCE+ will be updated a bit later (2-3 weeks depending on my time allowance).
I will need to revert, reimplement an retest night vision, heat vision and psi vision.
On the bright side, I have cherry-picked the option to increase modOffset for mods, so at least that can be implemented in XFiles/XPiratez and tested.
Right, I probably need cheery pick your visibility changes as promised that my will be compatible with yours.
Any thing else was conflicted?
-
Right, I probably need cheery pick your visibility changes as promised that my will be compatible with yours.
Any thing else was conflicted?
There was something around calculate line/trajectory, I didn't check it in detail, it might conflict with Karadoc's bow fix... to be confirmed.
Other than that it looks fine.
-
Small recap what is possible with new visibility scripts:
a) Some unit can be visible only to some other units, something like A can see B, C can see D but A cant see D and C cant see B.
b) Items in hands can affect visibility of units, you can add NV googles that need be held in hands to allow see in darkens or masking device that will cloaking you.
c) Effectiveness of visibility is stored as integer value. Greater than zero mean that other unit is visible. This allow gun scope that add value to that number increasing effective sight radius of unit. Alternative you can subtract to recreate some camouflage. As IR visibility should not be affected by scopes or normal camouflage, I added option for distinguish between different visibility modes. Normal visibility (in visible light lengths) is defined by empty value `null` other types can be defined by new tag in `BattleUnitVisibility`.
d) You have access to raw data of smoke and fire density, this allow you to change how smoke affect visibility or allow fire to prevent use of IR.
e) You can add penalty for NV googles if target is in bright spot, or simply add bonus/penates based on relative lighting level of tiles where units stand (current and target) to simulate that you can't see thing in shadow.
f) All units stats can contribute to visibility. You can made cloaking device that will fall or reduce it effectiveness when unit lose hp (or current TU).
Things I would like to add in some future:
a) Visibility that ignore walls.
b) 360 degree visibility (right now it sill use old FOV cone).
c) Drawing of unit will get info how other units see it, e.g. "Is this unit normally visible?", "I can see it only using IR or Psi?".
-
Yankes, please consider below features:
1) object like crafts or bases displayed on geoscape can have custom sprite, also size other then 5x5 pixels. Also different one in case hyperwave decoder is used (unknown ship / known ship), maybe even different sprite based on current ship status.
2) crafts can have optional weight limit, that could limit how much items weight can carry. This is opossite to number of items in original game. This could lilmit items that can be take for battle but also items salvaged from battle (like elerium).
3) damage inflicted to unit can be displayed as number on the top of the unit (like in many RTS games)
4) base defence buildings have N shots not just one. This could be used for cannons that fire many Times with minimal hit Chance.
5) damage taken to alien craft durig base assult should define number of aliens that will die in turn 1 of the battle.
6) alien intelligence can be splitted into two variables:
Alien will remember any soldier he spots in his field off view for N turns where N = intelligence, other aliens are not aware of these soldiers
Alien will make other aliens remember any soldier he spots in his field of view for K turns where K = group intelligence (new alien stat)
Alien will pass his memory of soldiers to any other alien that is with his field of view for M turns, where M = telepathy (new alien stat, optional, very complex to implement but could be helpfull to create chain of memory strategy for aliens, so xcom can pass grenades and aliens could pass positions of xcom soldiers that way)
So IQ = 5 and Group IQ = 1, means that alien will remember spotted soldier for 5 turns + he will make other aliens remember them for additional 1 turn
Using this engine we could implement standard behavior from X-COM but also bring much more for mods.
More here https://github.com/Bladum/OpenXcom/commits/master
Thanks
Tom
-
There was something around calculate line/trajectory, I didn't check it in detail, it might conflict with Karadoc's bow fix... to be confirmed.
Other than that it looks fine.
So, this is what I had to revert to get a clean merge:
- camouflage and anti-camouflage
- heat and psi vision
- night vision by Stoddard
- LoF fix by karadoc
I'll try to add them on the merged version again, but I may need some help from Stoddard and karadoc on their commits... we'll see.
-
So, this is what I had to revert to get a clean merge:
- camouflage and anti-camouflage
- heat and psi vision
- night vision by Stoddard
- LoF fix by karadoc
I'll try to add them on the merged version again, but I may need some help from Stoddard and karadoc on their commits... we'll see.
I will look on this too. In my case half work is done because I write part of it.
btw did you play with my new lighting? Do you have any feedback about how it work or its performance?
-
So, this is what I had to revert to get a clean merge:
- camouflage and anti-camouflage
- heat and psi vision
- night vision by Stoddard
- LoF fix by karadoc
I'll try to add them on the merged version again, but I may need some help from Stoddard and karadoc on their commits... we'll see.
Push a branch to github, I'll merge and do pull requests as needed. There wasn't anything complicated in the night vision though, I think I got off with int shade parameter in reShade().
-
Yankes, please consider below features:
1) object like crafts or bases displayed on geoscape can have custom sprite, also size other then 5x5 pixels. Also different one in case hyperwave decoder is used (unknown ship / known ship), maybe even different sprite based on current ship status.
2) crafts can have optional weight limit, that could limit how much items weight can carry. This is opossite to number of items in original game. This could lilmit items that can be take for battle but also items salvaged from battle (like elerium).
3) damage inflicted to unit can be displayed as number on the top of the unit (like in many RTS games)
4) base defence buildings have N shots not just one. This could be used for cannons that fire many Times with minimal hit Chance.
5) damage taken to alien craft durig base assult should define number of aliens that will die in turn 1 of the battle.
6) alien intelligence can be splitted into two variables:
Alien will remember any soldier he spots in his field off view for N turns where N = intelligence, other aliens are not aware of these soldiers
Alien will make other aliens remember any soldier he spots in his field of view for K turns where K = group intelligence (new alien stat)
Alien will pass his memory of soldiers to any other alien that is with his field of view for M turns, where M = telepathy (new alien stat, optional, very complex to implement but could be helpfull to create chain of memory strategy for aliens, so xcom can pass grenades and aliens could pass positions of xcom soldiers that way)
So IQ = 5 and Group IQ = 1, means that alien will remember spotted soldier for 5 turns + he will make other aliens remember them for additional 1 turn
Using this engine we could implement standard behavior from X-COM but also bring much more for mods.
More here https://github.com/Bladum/OpenXcom/commits/master
Thanks
Tom
1) Maybe
2) This probably will cause lot of problems when you reach limit after mission. Without special UI it will not work and I prefer not change UI.
3) Again this is UI change that I avoid.
4) Maybe
5) This could be useful
6) Probably too complex for small grain, difference to current behavior will be probably not visible for player.
-
btw did you play with my new lighting? Do you have any feedback about how it work or its performance?
Not yet. I'm not at home, I'll try over the weekend.
Push a branch to github, I'll merge and do pull requests as needed. There wasn't anything complicated in the night vision though, I think I got off with int shade parameter in reShade().
I've seen the playmix3.3 branch.
I guess that was done in a hurry. The night vision shading method code is duplicated in two almost identical methods and the conflicting changes from Yankes were semi-reverted/semi-duplicated.
I'd like to avoid that and use the change from Yankes rather than going around it.
I'll give it a try myself first this week, and if it doesn't work, I'll push what I have and ask for help.
-
I've seen the playmix3.3 branch.
I guess that was done in a hurry. The night vision shading method code is duplicated in two almost identical methods and the conflicting changes from Yankes were semi-reverted/semi-duplicated.
I'd like to avoid that and use the change from Yankes rather than going around it.
I'll give it a try myself first this week, and if it doesn't work, I'll push what I have and ask for help.
Yes, it was a rush job, just to take a look. It didn't randomly crash and that was enough. Of course it should be redone properly. I'll be redoing all my branches after this merge anyway, I'm doing them wrong right now.
-
I'll be redoing all my branches after this merge anyway, I'm doing them wrong right now.
I'm planning that too, sigh. It's a mess by now.
I guess it's a curse of being a fork of a fork... or a fork of a fork of a fork in your case :P
-
@Yankes: There has been a change in map rendering from 3.2 to 3.3, which I don't fully understand... can you explain why did it change?
Or, at least, where should I put the night vision re-shade functionality within the getWallShade() method... on individual components (if so, which ones exactly) or at the end on the return value?
Comparison attached. Hopefully understandable enough.
PS: there are together 4 such places with the new getWallShade() method.
-
This was added to allow light "bleed" through doors. Without this you will never see doors if you approach them from behind.
-
OK, I have finished merging yesterday.
Looks quite good.
I tried doing some performance measurements, but doing it properly would take many different scenarios and a lot of time.
Just as example, I measured:
1. the drawTerrain() method
2. and a walking animation using full TUs
Results were in average about 10% worse on v3.3 compared to v3.2.
drawTerrain(): 10 measurements
- v3.2: times between 2900 and 4000 micro seconds... averaged ~3350 micro seconds
- v3.3: times between 3300 and 5800 micro seconds... averaged ~3700 micro seconds
But given the big spread, it might also be just a measurement error :(
walking animation: 5 measurements, with much smaller spread, so probably a good/reliable test
- v3.2: times between 2000 and 2200 milli seconds... averaged ~2125 milli seconds
- v3.3: times between 2350 and 2650 milli seconds... averaged ~2475 milli seconds
This was a much more consistent test, so I guess I can safely say that on this particular scene (see attachment) with these particular settings on this particular PC (high end from 2016)... v3.3 is about 10% slower overall.
I don't know how much of the whole walking animation can be credited to FOV-related stuff. If most of it, then the degradation of 10% is probably acceptable; if only a fraction of it, then the FOV-related stuff might have a much bigger degradation, which would not be desirable... but I don't know how to effectively measure only FOV-related part.
Finally, the test should be done on slower PCs; on several different (complicated) scenes and with several different video settings too I guess.
I however don't have time for it... so I'll try to play real campaign with v3.3 and if I see something slower than usual, I'll make a save and try the same with v3.2 to see if there's any noticeable difference.
-
`drawTerrain` is not bottleneck, biggest offender should be `calculateLighting`. I attach save on with I test performance degradation.
Opening and closing doors need recompiling shadows for every layer. Adding lot of fire that is independent light source made it even slower.
-
Yeah, I did drawTerrain() test mostly because of night vision... which also seems OK.
I'll try your save later too... and I have a quite nice save from Siberia Mission in PirateZ too (with lots of doors and tons of fire), I'll try that too.
-
Yankes, another ideas
1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.
3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.
4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.
7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.
8) define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.
PS: new lightning system works fine for me regarding performance. I haven't noticed any perfo issues.
Regards
Tom
-
1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
That's a highly personalized request, but I can imagine it being useful to someone.
2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.
Nah... What would you have to hold in your hands to prevent you from using one hand to pick up something? A concrete mixer? ;)
3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.
Yes, that would be useful in a million ways, but I imagine it would be difficult to code.
4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.
And also separate TUs per tile, separate aiming times... This is going nowhere. We can limit their TUs by armour already, this translates to kneeling as kneeling always has the same TU cost.
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).
This has been discussed to death over the years and ultimately always rejected, so... :P
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.
That would lead to sorting your soldiers into categories such as "useless", "disappointing" and "perfect" (the latter encompassing maybe 1% of your people) and sacking most of them on straight away, because they aren't very promising. This would be dull and to be honest also quite unrealistic. Sorry, it's just bad design.
7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.
Why? What's the point?
It's a new complex mechanic, but I have no idea what it is trying to represent, or how to make the game better.
8) define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.
And you can't send more than 2 big ships because the sky is too small or what? :P
No, seriously, this is one of the proposed features that make me go "wait, what"?.
PS: new lightning system works fine for me regarding performance. I haven't noticed any perfo issues.
Same here. I love it!
-
Solarius Scorch have in 97% same answer as me :)
Yankes, another ideas
1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
[...]
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).
This could be done as part of bigger functionality added is some future. This is similar to overriding game over conditions, as standalone feature is not useful or even bad for game but as part off bigger system I could shine. Image you start only with one country and need conquer/convince other to join you cause.
End game then could be that all countries join XCOM :)
This would need wait until I finish adding scripts to battlescape, after that I could work on geoscape.
2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.
Right now you can made that weapon need empty second hand to shoot and I think this is best way to model that behavior. Name one real weapon that need both hands to use but can't be hold in one hand (not shoot!).
3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.
At some point I could add something like that.
4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.
[...]
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.
This more like tweaking that new gameplay mechanic.
7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.
This wound not have good impact on gameplay. Only thing that players will do is to dump all solders that have less than 100%. Without UI it would be even worser because you don't know who to sell.
8) define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.
This will not work, game only support 4 craft interception windows and changing this is outside of OXCE scope.
-
After few days of extensive tests, I like the 3.3. Even if someone isn't into scripting, the new light effects alone are worth upgrading. I found no bugs either. Highly reccomended.
-
7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.
This wound not have good impact on gameplay. Only thing that players will do is to dump all solders that have less than 100%. Without UI it would be even worser because you don't know who to sell.
i was thinking about soldiers section. Standard soldier, cyborg or hybrid like in apocalypse could use such system. Cyborg wont be able to learn at all.... hybrid would learn faster.
9) Another idea to have 2 images for alien ship during interception. One after research, second before research of this particular alien ship.
-
i was thinking about soldiers section. Standard soldier, cyborg or hybrid like in apocalypse could use such system. Cyborg wont be able to learn at all.... hybrid would learn faster.
That's dumb. Thinking that any "Cyborg" wouldn't have a team constantly making upgrades and refinements that translate to enhanced performance is naive. You are neglecting the "organism" portion of a cyborg, in that in definition there are organic and inorganic parts parts merged together. Biological systems respond to stimulus, artificial ones can be programmed and so those two facts together make the case that if there was enough mastery of the technology to create a cyborg, then it could learn or be "taught".
-
Maybe not this one, but cases can be made for slower and faster learning soldier types. Whereas it's robots that have a longer development cycle than humans learn (indeed, an improvement on all robots should be as good for all robots of the same series, a process better represented by a patch/upgrade mechanic in the workshop than by battlefield learning).
I could also see a limit of craft number for interceptions, because airspace is not unlimited even if it is big. For something really fast and maneuverable (so changing directions a lot), trying to have many crafts following would expose pilots to errors and collisions, a situation best avoided by: reducing/capping the number of crafts trailing to a safe number.
But the kneeling one shows a misunderstanding of the TU system. Firing has a relative cost: it's the same % of your turn and it is the reference for an action in the game. An armor that gives more TUs means a soldier is moving/kneeling faster, an armor that removes TUs means that you move/kneel slower. Tweaking kneel costs, door opening cost or moving cost is meaningless.
-
Maybe not this one, but cases can be made for slower and faster learning soldier types. Whereas it's robots
All right, heresy time:
How about we turn HWPs into a soldier type instead of HWP type? And various turrets as armours for them?
They would either be unable to learn (caps the same as starting stats) or maybe they would learn only in some areas (like Reactions). And it should make HWP management easier, as you would only change the armour (which must be produced first, of course).
-
heresy time :)
i am just throwing ideas, maybe you will use it one way or another.
1) I assume changing armour during battle is very big change and wont be able to implement. It could be big inventory slot of type 3 (armour) and then just drag and drop armour just like any other item.
2) display armour weight somewhere on the soldier inventory screen. Now to check what is armour weight the only way is to remove all inventory / items from soldier. it may be also displayed as a "mouse over" event when mouse cursor is over the soldier image then item description is shown "Personal armour [12]" just like any other item.
3) any easier way to unload weapon on the soldier inventory screen (like RMB on weapon to auto unload). If clicked on ground then unload would be done on ground. If clicked on inventory then it would be added to same place if applicable, if not then to hand, if not then to the ground.
4) action on UI to reload weapon automatically, so you can choose snap / auto / aim / throw / reload option now (commit here https://github.com/Bladum/OpenXcom/commit/53b1b1fb03479759c7c0877a5afa859d9bc90851)
5) display more complex item action information box once choose item action during battle (commit https://github.com/Bladum/OpenXcom/commit/53b1b1fb03479759c7c0877a5afa859d9bc90851), it display smaller font with more detailed information about action performed. Also with smaller font more actions could be added in the future.
Sorry for no screens for UI changes but i made commits some time ago.
-
All right, heresy time:
How about we turn HWPs into a soldier type instead of HWP type? And various turrets as armours for them?
They would either be unable to learn (caps the same as starting stats) or maybe they would learn only in some areas (like Reactions). And it should make HWP management easier, as you would only change the armour (which must be produced first, of course).
Isn't this already somewhat possible due to Meridian's work on manufacturable soldier types? It's possible to define a soldier type that has minStats, maxStats, and statCaps all the same, not count towards promotions, have a default armor that looks like a HWP chassis and can only equip certain armor types (turrets or upgrades for the chassis), and the armor can block out the inventory as necessary. It's not HWP->soldier conversion, but we pretty much have the soldier->HWP conversion.
-
Isn't this already somewhat possible due to Meridian's work on manufacturable soldier types?
Yes, I only realized it after I wrote it. :P
And a +1 for armour weight display!
-
great Solar that you like at least one thing :)
few another ideas
1) aiming level of details that are displayed when soldier is aiming at the enemy
level 0 - reduced vision, no percentage chance displayed
level 1 - current vision, percentage chance displayed
level 2 - improved vision, percentage chance to hit + potential damage (for wall ? object etc)
level 3 - total vision, chance to hit + potential damage + current life or weakness etc
This similar to perk system in Fallout.
Level may be related to either skill of soldier (accuracy) or his promotion level or equipment (custom tags) or race / soldier / armour type.
2) some items are not designed to be thrown at all. Therefore either it should be modifier to weight or to throwing accuracy. Grenade 3 (3) but high explosive is 6 (12) effective for throwing so it rather should be . It may also be done as a flag, not designed for throwing and changing weight for throwing by 50% or 100%.
3) in closed rooms when ceiling is low, there is problem to throw far away as item is being blocked by ceiling. Possible to implement alternative way of throwing working similar like bullet but with shorter range ?
4) ability to recover unit from battle based from enemy or neutral unit that survived battle (stunned or alive). It would generate x-com soldier (based on one of selected types in "soldier") inside transporter based on data defined in unit class itself. It would be useful for rescue mission or to get single / unique soldiers.
-
great Solar that you like at least one thing :)
Hey, I liked many! Some of your ideas are on the Solar's Wishlist! :)
1) aiming level of details that are displayed when soldier is aiming at the enemy
level 0 - reduced vision, no percentage chance displayed
level 1 - current vision, percentage chance displayed
level 2 - improved vision, percentage chance to hit + potential damage (for wall ? object etc)
level 3 - total vision, chance to hit + potential damage + current life or weakness etc
This similar to perk system in Fallout.
But we don't have perks in OXC... We have a more continuous human model. So saying "soldiers with Accuracy 50+ will see X" is not the right path.
But I can imagine some sort of super-scanner that displays enemy HP or something.
2) some items are not designed to be thrown at all. Therefore either it should be modifier to weight or to throwing accuracy. Grenade 3 (3) but high explosive is 6 (12) effective for throwing so it rather should be . It may also be done as a flag, not designed for throwing and changing weight for throwing by 50% or 100%.
Yes, accuracy for throwing would be useful.
3) in closed rooms when ceiling is low, there is problem to throw far away as item is being blocked by ceiling. Possible to implement alternative way of throwing working similar like bullet but with shorter range ?
Maybe not like a bullet, but some sort of "low" trajectory would be useful... But only if the AI could do it too.
4) ability to recover unit from battle based from enemy or neutral unit that survived battle (stunned or alive). It would generate x-com soldier (based on one of selected types in "soldier") inside transporter based on data defined in unit class itself. It would be useful for rescue mission or to get single / unique soldiers.
Potentially powerful feature. Rescue missions are much needed!
Yankes, are turnLimit and chronoTrigger flags in OXCE? I think they're pretty old, so I'd expect them to be in, but they don't work for me.
-
Not yet, I will soon start on merging recent changes from master and it will be added.
-
This was added to allow light "bleed" through doors. Without this you will never see doors if you approach them from behind.
I still think it is not compatible with vanilla... the indexes used are just different.
For example the doors are not shown anymore, even though it's day and they are clearly visible, see attached.
-
It should work it that case. This is only case or this happens for other doors too? If this only case then this my fault and I will fix it.
-
It should work it that case. This is only case or this happens for other doors too? If this only case then this my fault and I will fix it.
I played first time with 3.3 yesterday and only for a few hours... but I'll check some other situations soon.
Did you mean other doors in this UFO or other doors in other UFOs/buildings?
In this UFO (very large battleship), all doors to the east and south are not visible.
-
I played first time with 3.3 yesterday and only for a few hours... but I'll check some other situations soon.
Did you mean other doors in this UFO or other doors in other UFOs/buildings?
In this UFO (very large battleship), all doors to the east and south are not visible.
In other buildings.
-
In other buildings.
Yes, happens everywhere.
Two examples with test saves attached.
-
While I was going through my TFTD playthrough, I found myself in the situation where I had to buy a Triton for every base just so I could easily equip weapons and armor on my troops who only existed to rebuff retaliations. It felt like an awkward, unneccessary step. Since there is the option to remove the arbitrary item limits on crafts, could there be a possibility to allow the crew equipment screen without a craft? Just allowing soldier equips straight from base stores would be such a phenomenal time saver in the long run.
-
Yes, happens everywhere.
Two examples with test saves attached.
I find cause of bug, `getWallShade` -> `isDiscovered` check wrong part. I will release fix in this week (with another one that fix corpse bug).
While I was going through my TFTD playthrough, I found myself in the situation where I had to buy a Triton for every base just so I could easily equip weapons and armor on my troops who only existed to rebuff retaliations. It felt like an awkward, unneccessary step. Since there is the option to remove the arbitrary item limits on crafts, could there be a possibility to allow the crew equipment screen without a craft? Just allowing soldier equips straight from base stores would be such a phenomenal time saver in the long run.
This more fit Meridian branch when he add lot of UI improvements.
-
I find cause of bug, `getWallShade` -> `isDiscovered` check wrong part. I will release fix in this week (with another one that fix corpse bug).
Is it the same one I wrote here: https://openxcom.org/forum/index.php/topic,2915.msg72679.html#msg72679
Or a different one?
This more fit Meridian branch when he add lot of UI improvements.
While I was going through my TFTD playthrough, I found myself in the situation where I had to buy a Triton for every base just so I could easily equip weapons and armor on my troops who only existed to rebuff retaliations. It felt like an awkward, unneccessary step. Since there is the option to remove the arbitrary item limits on crafts, could there be a possibility to allow the crew equipment screen without a craft? Just allowing soldier equips straight from base stores would be such a phenomenal time saver in the long run.
You do get the equipment screen before base defense :)
What more do you need?
Anyway, I was also thinking about it for my LP, so that I can do the equipment in-between episodes and don't need to do it just before the mission to save viewer's time... I'll put it on the list.
EDIT: done, wasn't all that hard... in the "Soldiers" UI, press "I" (or whatever hotkey you have for opening inventory). Download: https://drive.google.com/open?id=0B8itkFQbhj-YT015SlZXS2FJTzA
-
Is it the same one I wrote here: https://openxcom.org/forum/index.php/topic,2915.msg72679.html#msg72679
Or a different one?
Exactly this, `part` should be less by 1.
-
EDIT: done, wasn't all that hard... in the "Soldiers" UI, press "I" (or whatever hotkey you have for opening inventory). Download: https://drive.google.com/open?id=0B8itkFQbhj-YT015SlZXS2FJTzA
*man-hugs*
-
*sandwich!*
-
*man-hugs*
There is a small, but critical bug is that version, please don't use the new feature until I release a new version (or your missions will randomly start failing at the end).
-
That may or may not affect my current mission fail rate ;)
-
I have a heretical proposal: a mod defined option for shared global vault space for all the loot and weapon items.
Soldiers/tanks and interceptors/transports would still have to be transfered, but all the other stuff can be accessed from any Base at any time, be it for manufacture, selling or loading into a craft.
-
I'm absolutely certain I'm an idiot right now...
That out of the way, how exactly does a potential user acquire this in an already usable file or installer? I've found the compilable code, and tried and failed to DL it on openxcom.com.
Thanks in advance, but please take it a bit easy on me. My connection sucks where I live, so I can't look as well for myself as I would like to.
And yes, I checked the first page.
-
If you want Meridian's version of it, he has downloads for Windows and a link to pre-compiled versions for Linux. See here for his post. (https://openxcom.org/forum/index.php/topic,4187.0.html)
-
If you want Meridian's version of it, he has downloads for Windows and a link to pre-compiled versions for Linux. See here for his post. (https://openxcom.org/forum/index.php/topic,4187.0.html)
Thanks much. Interested in seeing first-hand what all this is capable of over the main branch.
Though unfortunately now that I've tried, it will not run. I tried it with the version I had been running the game with, the most recent nightly, and the one before that one. Unfortunately the link mostly had a changelog, and no instructions of any sort. Even the file was just an exe in a zip file. So I'm not sure what to do at this point...
-
Thanks much. Interested in seeing first-hand what all this is capable of over the main branch.
Though unfortunately now that I've tried, it will not run. I tried it with the version I had been running the game with, the most recent nightly, and the one before that one. Unfortunately the link mostly had a changelog, and no instructions of any sort. Even the file was just an exe in a zip file. So I'm not sure what to do at this point...
Because I did couple of big project (scripts), and now I lag couple of moths behind nightly. This mean currently is not compatible with recent nightly.
From first post:
OpenXcom date: Nightly 2016-01-02
This is needed version as it not available right now I added needed data to first post ("Data31.zip") that have all require data to run OXCE.
Overall I plan fix this situation by updating to recent nightly (it will be done in 2 - 3 weeks), this will made my exe simply drop in replacement of official exe from recent nightly.
-
in SavedBattleGame.cpp, _alienCustomDeploy and _alienCustomMission are loaded, but not saved: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/SavedBattleGame.cpp#L119
a/ is saving missing?
b/ is loading not necessary and can be removed?
c/ have I missed something?
-
a)
-
I think we may have found a rather critical issue in OXCE 3.3: https://openxcom.org/forum/index.php/topic,4822.msg73841.html#msg73841
Please have a look if what I say there is right or not.
-
Dunno if this is as much a feature request as it is a bug, but I noticed this while playing x-piratez and since there wasnt an option for turning it off I must assume its the engine:
If a soldier sees an alien (or more than one) it stops them in place.
But it does it more than just the 1st time the alien has been seen, it does it every time somebody sees them (individually) for the first time. Even though the alien has already been seen by the player's forces.
Now I understand its worth the caution but if the critter has already acted, or has melee only, or if they've got their back turned... and especially if there are a BUNCH of aliens (like 4, 6, or even 10) then I have to keep CLICKING over and over and over again for every soldier I want to move through spotting territory. I even end up mis-clicking and moving them somewhere I dont want to because I just get so frustrated with it.
*I* as the player already know the aliens are there, I know where they are because of the indicator. Its good to stop the soldier when they spot one ... but then its up to me whether ive got the brains to move my soldiers through beaten zones. The soldiers themselves dont need to keep stopping over and over again.
Vanilla does not have this feature, it notifies and stops your soldier when an alien has been seen for the first time that round (it can even eat up some time units by stopping them), but after that nobody else is going to freeze in their tracks.
In X-Pirates for example all my soldiers have melee weapons usually, there may be like 4 or 6 enemies in plain view but I have to rush up to get to cover close to them and that means moving the soldiers through seeing all of those guys, over and over and over again.
This is like a Nag Screen on a dos game.
This is Artificial Difficulty and it takes away from the enjoyability of the game.
Ive tried to hold down the Alt key, the Ctrl key, the Shift key while moving to do a "forced move" like other tactical games have but it doesnt bypass the behavior. Its infuriating.
I understand its a good design/safety feature, but pleeeeeease provide an option to turn it OFFF
EDIT:
The other thing id like an option to turn off is the "pausing" in motion between units moving from one tile to another. Vanilla xcom didnt do this, it just started moving them immediately to the new tile as soon as they reached a tile, the movement speed just dictated how quickly they moved between tiles.
Again just an on/off option, not to remove the feature because I think it is useful, but it feels like the game is stuttering even if it isnt.
-
OXCE+ has it set that running (CTRL) or holding SHIFT does ignore sighting new enemies, what you might be experiencing is a reaction check on a range-limited weapon or an arcing weapon that can't actually make the shot.
-
If a soldier sees an alien (or more than one) it stops them in place.
But it does it more than just the 1st time the alien has been seen, it does it every time somebody sees them (individually) for the first time. Even though the alien has already been seen by the player's forces.
It doesn't stop because it sees the alien... that works like in vanilla... only stops 1st time.
The soldier stops because there is reaction fire from the aliens (you can easily check that by pressing Ctrl+H if you don't believe me).
There have been reaction checks (causing soldiers to stop) for weapons with limited range (which didn't exist in vanilla). You just couldn't see this because they could not fire from these weapons.
I have fixed that in v2016-11-05 .... so the newest piratez version 0.99e should not suffer from that (you must have ufo extender accuracy option turned on tho, I hope everybody does).
https://openxcom.org/forum/index.php/topic,4830.msg73772.html#msg73772
If I missed some other case, please let me know and attach a save.
EDIT:
The other thing id like an option to turn off is the "pausing" in motion between units moving from one tile to another. Vanilla xcom didnt do this, it just started moving them immediately to the new tile as soon as they reached a tile, the movement speed just dictated how quickly they moved between tiles.
Again just an on/off option, not to remove the feature because I think it is useful, but it feels like the game is stuttering even if it isnt.
This is not a feature. It's a performance problem.
Vanilla had max vision range 20, Piratez has max vision range 40... which on slower computers and bigger maps gets stuttery.
-
EDIT:
The other thing id like an option to turn off is the "pausing" in motion between units moving from one tile to another. Vanilla xcom didnt do this, it just started moving them immediately to the new tile as soon as they reached a tile, the movement speed just dictated how quickly they moved between tiles.
Again just an on/off option, not to remove the feature because I think it is useful, but it feels like the game is stuttering even if it isnt.
As Meridian said this is performance problem, this is always happening? If you run normal XCOM using piratez exe its works same? What processor you have in your comp?
Stian put lot of work to speed up this but there is some limitation what you could do. If problem is with weak hardware then is not many things to fix without rewriting big parts of engine.
-
Based on what you guys said that sounds like it might be the issue. Ive noticed some enemies turn while im moving and it stops then, but they're not firing anything just turning (the enemies have pistols I think, ive rarely run into any enemies in piratez that throw things, even ratmen with bows are able to fire a long distance).
Ive got a netbook so performance *might* be an issue. It takes over a minute for the program to load with the mod (and normal openxcom takes about 30 seconds to load).
I also have no video card, OpenGL is locked at v1.4 so I cant use shaders. But I dont try, so no biggie (that locks OXC up so bad I have to delete the config otherwise it never runs).
Unrelated: is there a wiki or documentation of the new ruleset functions for OXCE+? Its nice to look through piratez' ruleset for how some things were done but I might be missing cool stuff (somebody mentioned terrainDamage multiplier though its probably not implemented yet).
-
The best documentation, if a bit difficult to parse sometimes, is the OXC readme that comes with it and Piratez. There's a description of pretty much everything, including damage to terrain that is available no through damageAlter.
-
A short question on scripts:
Is it possible with them to define secondary explosions?
Example: A demolition pack is lying around and hit by a grenade. The grenade then triggers the demolition pack to explode with its normal strength.
This can be solved with a simple boolean switch, in fact the same one used for the bio-drone and cyberdisc. When it dies, it explodes. All the switch needs to do is be applicable to other items as well.
Also this reminds me of a Linked Attack, common mechanic in alot of rpg games for tricking out their equipment. Basically check to see if the attack does any damage/effect to the target at all. If so then the Linked Attack/Weapon is applied (or an entire chain of them if it has more than one), though in the case of OXC it should still apply armor to all of the linked attacks because modders can make armor effectiveness 0 against them if they wish.
For example: Chryssalid hits, main attack does normal damage but has a linked zombification weapon. If the attack does any damage (health) to the character, they get hit with the linked weapon and wouldnt you know, they turn into a zombie. But unless they can be hurt (stung) it doesnt do anything because the linked attack isnt triggered.
Same idea for a Harpoon Tranquilizer, can make it do 20 AP but the 50 Stun is a linked attack. If the target takes so much as 1 health damage from the dart they take the 50 stun damage roll (a kind modder can still give the armor some effectiveness against it, maybe 0.2, that way the dart gets stuck in but not deep enough to fully inject).
In a similar way I guess explosives could be attached to a package, or an incendiary, or a stun bomb, but unless some additional switch was present the secondaries wouldnt trigger unless the primary did damage (that be like alwaysLinked = true, then you're pretty much sticking a bunch of different things on the same projectile for hellish results, and for giggles the linked weapons also trigger linked weapons if they are likewise activated or have alwaysLinked).
Some things would always trigger though just because they cause an area of effect (HE and Inc). This would allow a true shaped charge - the explosive goes off, and then a linked AP shot hits also and can maybe divide armor by 2, the explosive could be small but the direct hit damage as a result could be high.
The best documentation, if a bit difficult to parse sometimes, is the OXC readme that comes with it and Piratez. There's a description of pretty much everything, including damage to terrain that is available no through damageAlter.
Thanks man, didnt even know it had that info.
Edit: also didnt know it was in YAML either
-
This can be solved with a simple boolean switch, in fact the same one used for the bio-drone and cyberdisc. When it dies, it explodes. All the switch needs to do is be applicable to other items as well.
Sometimes "simple" solution are very hard. You need consider structure of OXC code. You could have your bool and place where you want use it far apart. Linking this two parts will require lot of "digging". This will in long run reduce quality of code base because each change like that made next change harder to implements.
Great example of this is shotgun mechanic. Because it was written as simple bool switch now is impossible to add lot of behavior available for other items.
This is because its logic was handled in wrong place in code. Fixing it need rewriting whole code responsible for shooting bullets.
Corpse explosion is handle completely in different place, when unit die it detonate its own corpse item as if it was grenade, other items do not have dying units to trigger it.
Aside of that. I have plans to add that capabilities to allowing remote detonating or chain detonating of items.
Also this reminds me of a Linked Attack, common mechanic in alot of rpg games for tricking out their equipment. Basically check to see if the attack does any damage/effect to the target at all. If so then the Linked Attack/Weapon is applied (or an entire chain of them if it has more than one), though in the case of OXC it should still apply armor to all of the linked attacks because modders can make armor effectiveness 0 against them if they wish.
For example: Chryssalid hits, main attack does normal damage but has a linked zombification weapon. If the attack does any damage (health) to the character, they get hit with the linked weapon and wouldnt you know, they turn into a zombie. But unless they can be hurt (stung) it doesnt do anything because the linked attack isnt triggered.
Same idea for a Harpoon Tranquilizer, can make it do 20 AP but the 50 Stun is a linked attack. If the target takes so much as 1 health damage from the dart they take the 50 stun damage roll (a kind modder can still give the armor some effectiveness against it, maybe 0.2, that way the dart gets stuck in but not deep enough to fully inject).
This is too on my TODO list.
-
New version 3.5 ready, biggest change is update to recent nightly.
Dioxine now you will have fun with fixing all incompatibilities caused by over half of year of changes :D
-
New version 3.5 ready, biggest change is update to recent nightly.
Dioxine now you will have fun with fixing all incompatibilities caused by over half of year of changes :D
........Holy shit. Here it is. Thanks, Yankes!
So much work! :D But Meridian goes first. ;)
-
What are the incompatibilities? What has been changed? Do you happen to have any comprehensible log? :)
-
What are the incompatibilities? What has been changed? Do you happen to have any comprehensible log? :)
After posting it I check changes in basic rulesets, and probably it wont b so bad. One that I find that is incompatible is waypoint weapons (instead of bool is number).
Tomorrow I will prepare something like that.
-
Thank you! I'll be very grateful, and probably not only I :)
-
w h o a a a
After posting it I check changes in basic rulesets, and probably it wont b so bad. One that I find that is incompatible is waypoint weapons (instead of bool is number).
Tomorrow I will prepare something like that.
does that mean that we dont get # of waypoints anymore, or did we go to a number rather than a yes/no? (vanilla limit was 9 so this is not a problem if the boolean was removed, can just set it to 9 if desired)
-
It means that if you don't change your ruleset, it will crash, since it'll look for integer and find a boolean.
-
........Holy shit. Here it is. Thanks, Yankes!
So much work! :D But Meridian goes first. ;)
Holy shit indeed. Now it's my turn I guess.
Bad news is that unless it merges "nicely", it may take me a while too... read: a few weeks.
EDIT: yeah, 67 files with merge errors... this will take a while
-
Holy shit indeed. Now it's my turn I guess.
Bad news is that unless it merges "nicely", it may take me a while too... read: a few weeks.
EDIT: yeah, 67 files with merge errors... this will take a while
No worries, let the players enjoy for a while the missions with time limits which aren't really limited. 8)
-
I filter out some less interesting commits. But still over 200 lines.
-
Thanks, an interesting read.
Is there anything besides Blaster Launcher waypoints which absolutely needs to be changed to work properly?
-
Thanks, an interesting read.
Is there anything besides Blaster Launcher waypoints which absolutely needs to be changed to work properly?
Hard to say, I added changes form ruleset used by basic ufo. aside form `waypoints` the `destroyItem` was added that change behavior of research.
-
I have a feature suggestion:
Add a tile property that reduces sight distance, but does not block walking or shooting through. With this a modder could add tiles that represent fog (on part of map), sand storms (on part of map), waterfalls, thin curtains, illusionary walls, etc... for more interesting maps.
I think there are several possibilities to implement this, but I cannot judge how much work it will be:
1. There is LOS mcd (no 31), which can be switched to block line of sight to terrain but it does not block line of sight to units. Change the behavior that it also blocks sight to units (not sure if this would change vanilla gameplay???).
2. Add completely new mcd value which can be added to a tile via ruleset with 'mcdpatch'. The new mcdvalue could be an integer that, if switched to non-zero, reduces sight range similar to smoke.
3. Make it possible that units can shoot through very 'soft' tiles. That means tiles with sight blocking LOFT,but very small damage resistance (zero or less?) do not block projectiles and melee attacks.
-
I have a feature suggestion:
Add a tile property that reduces sight distance, but does not block walking or shooting through. With this a modder could add tiles that represent fog (on part of map), sand storms (on part of map), waterfalls, thin curtains, illusionary walls, etc... for more interesting maps.
I think there are several possibilities to implement this, but I cannot judge how much work it will be:
1. There is LOS mcd (no 31), which can be switched to block line of sight to terrain but it does not block line of sight to units. Change the behavior that it also blocks sight to units (not sure if this would change vanilla gameplay???).
2. Add completely new mcd value which can be added to a tile via ruleset with 'mcdpatch'. The new mcdvalue could be an integer that, if switched to non-zero, reduces sight range similar to smoke.
3. Make it possible that units can shoot through very 'soft' tiles. That means tiles with sight blocking LOFT,but very small damage resistance (zero or less?) do not block projectiles and melee attacks.
In some future I plans add something like that.
-
I do not know what you've done, but the problem with the latest version. In the version of September 2015, everything works fine. Change to the last - not even included in the menu. Buggy on missionScripts line. I do not know that there can fail, because under the old version of the game still works fine.
Can the same be done so that the original logic is not much changed, or changed, but at the request?
Не знаю, что вы сделали, но с последней версией проблемы. В версии сентября 2015 года, всё работает отлично. Меняю на последнюю - даже в меню не входит. Глючит по линии missionScripts. Не знаю, что там может глючить, ибо при старой версии в игре всё работает отлично.
Можно-же было сделать так, что бы логика оригинала не сильно менялась, или менялась, но по желанию?
-
You do not updated data folder.
-
I tried to use the
fuseTimerType: 0
and
fuseTimerType: 2
options on a normal grenade to restrict the timing posiibilities, but the grenade bahavior was not changed.
How do I get this working?
fuseTimerType: -2 #set how prime granade works.
# -3 -> no priming, flare always work.
# -2 -> can prime, unlimited time. Granade explode only after throw. Flare work only after prime.
# -1 -> can prime, can set time. Granade explode after set time. Flare and Proxy disappere after set time.
# 0 -> can prime, set fixed time of 0 turns.
# 1 -> can prime, set fixed time of 1 turns.
# 2 -> can prime, set fixed time of 2 turns.
# ...
# 22 -> can prime, set fixed time of 22 turns.
# 23 -> can prime, set fixed time of 23 turns.
-
I tried to use the
fuseTimerType: 0
and
fuseTimerType: 2
options on a normal grenade to restrict the timing posiibilities, but the grenade bahavior was not changed.
How do I get this working?
I made bug in documentation, proper name is: "fuseType".
-
I made bug in documentation, proper name is: "fuseType".
Thanks, it works. Great feature!
From option '-1', I expected that grenades would explode even in hand or inventory, when time is up. Would be a nice feature for those demolition charges.
There is no option, which mimicks the 'instant grenade' effect (instant explosion after throw), right?
-
Thanks, it works. Great feature!
From option '-1', I expected that grenades would explode even in hand or inventory, when time is up. Would be a nice feature for those demolition charges.
There is no option, which mimicks the 'instant grenade' effect (instant explosion after throw), right?
"-1" is default behavior. "-2" is instant grenade.
And in some future I will add option for grenades exploding in inventory.
-
And in some future I will add option for grenades exploding in inventory.
queue XComFiles crazy mission where there is an explosive set for 25 turns somewhere on the map, with enough power and radius to raze the whole place, which you must find and throw in a deep, deep hole somewhere on the map to save everyone. :D
-
You do not updated data folder.
Thank you. I lag behind a bit of life. :)
Could explain respected professionals, what are the default values for the damage to ground facilities to all types of damage? I'm trying to maneuver parameter "damageAlter: - ToTile:", but it is impossible to balance properly, because they do not know the original values. Could you in the next version, in the Readme.txt, specify the values for the damage on the ground?
Спасибо. Отстал я от жизни немного. :)
Не могли бы пояснить, уважаемые профессионалы, каковы значения по умолчанию для урона по объектам местности, для всех типов урона? Я пытаюсь маневрировать параметром "damageAlter: - ToTile:", но не получается сбалансировать нормально, ибо не знаю исходных значений. Не могли бы вы в следующей версии, в Readme.txt, указать эти значения для урона по местности?
-
Thank you. I lag behind a bit of life. :)
Could explain respected professionals, what are the default values for the damage to ground facilities to all types of damage? I'm trying to maneuver parameter "damageAlter: - ToTile:", but it is impossible to balance properly, because they do not know the original values. Could you in the next version, in the Readme.txt, specify the values for the damage on the ground?
Спасибо. Отстал я от жизни немного. :)
Не могли бы пояснить, уважаемые профессионалы, каковы значения по умолчанию для урона по объектам местности, для всех типов урона? Я пытаюсь маневрировать параметром "damageAlter: - ToTile:", но не получается сбалансировать нормально, ибо не знаю исходных значений. Не могли бы вы в следующей версии, в Readme.txt, указать эти значения для урона по местности?
0.5 is default for most of damage types. Stun, and other that do not do damage to tiles have 0.
Adding this info to readme is indeed good idea.
-
Thanks, it works. Great feature!
From option '-1', I expected that grenades would explode even in hand or inventory, when time is up. Would be a nice feature for those demolition charges.
There is no option, which mimicks the 'instant grenade' effect (instant explosion after throw), right?
Although it would be nice to force it, there is a game option that allows for grenades to explode immediately if set to 0 Turns fuse. You could combine this with just giving the grenade a fuse of only 0 Turns.
Over in XPirates the way it was usually done was making grenade items that are actually a Hand Weapon (like a gun) but with 1 shot internal magazine, and Arcing behavior like the deep one. So when you throw it, it expends itself, and it flies like a projectile and then explodes when it hits. Also made it so that it trains throwing accuracy instead of firing accuracy, and the accuracy for the shot goes off of Throwing instead of Firing. Its not all that complicated but would generally be impossible without the added options here. (along with a custom projectile for the object being thrown, since it wont use a sprite for the flying arc, but some neat stuff can be done with this too)
-
Although it would be nice to force it, there is a game option that allows for grenades to explode immediately if set to 0 Turns fuse. You could combine this with just giving the grenade a fuse of only 0 Turns.
Over in XPirates the way it was usually done was making grenade items that are actually a Hand Weapon (like a gun) but with 1 shot internal magazine, and Arcing behavior like the deep one. So when you throw it, it expends itself, and it flies like a projectile and then explodes when it hits. Also made it so that it trains throwing accuracy instead of firing accuracy, and the accuracy for the shot goes off of Throwing instead of Firing. Its not all that complicated but would generally be impossible without the added options here. (along with a custom projectile for the object being thrown, since it wont use a sprite for the flying arc, but some neat stuff can be done with this too)
"-1" is default behavior. "-2" is instant grenade.
And in some future I will add option for grenades exploding in inventory.
-
Bugreport for OXCE 3.5:
This will CTD for some missions (e.g. TFTD ship terror):
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/AlienMission.cpp#L185
PirateZ has lots of such missions...
In vanilla, this is taken care of separately:
https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/AlienMission.cpp#L186
-
Bugreport for OXCE 3.5:
This will CTD for some missions (e.g. TFTD ship terror):
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/AlienMission.cpp#L185
PirateZ has lots of such missions...
In vanilla, this is taken care of separately:
https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/AlienMission.cpp#L186
Fix is remove `true` from `getDeployment`. This option is for early caching bugs with missing data. In that case I wrongly assume that this data was required.
-
Is there an easy way to turn on the vanilla lighting?
-
Is there an easy way to turn on the vanilla lighting?
Right now not, but what is a problem?
-
Right now not, but what is a problem?
Simple answer is, I just don't like it at all and want vanilla back.
I gave it a try in the last 2 months, playing piratez, and I like it even less than at the beginning. It's unnecessary and visually disturbing (for me). I guess some people like it, that's why I'm asking for an option, but I will definitely turn it off for me.
Also, now that we are back on nightlies, I would like to play some vanilla mods using oxce (e.g. Area51), which are not optimized for this kind of lighting... and throwing flares absolutely everywhere is a total fun-killer.
-
Simple answer is, I just don't like it at all and want vanilla back.
I gave it a try in the last 2 months, playing piratez, and I like it even less than at the beginning. It's unnecessary and visually disturbing (for me). I guess some people like it, that's why I'm asking for an option, but I will definitely turn it off for me.
Also, now that we are back on nightlies, I would like to play some vanilla mods using oxce (e.g. Area51), which are not optimized for this kind of lighting... and throwing flares absolutely everywhere is a total fun-killer.
Ok, I will add option for that.
-
Thanks!
Also, testing 3.5, I found some funky unit animation.... not sure if it's because of OXC or OXCE, but it doesn't do this in 3.3.
Example here: https://youtu.be/vEJZsesymKA
Don't know how to describe it, hopefully it's visible enough.
EDIT: seems to be an issue with 2x2 units... tanks suffer similar effects
-
I will look on this too
-
Simple answer is, I just don't like it at all and want vanilla back.
Wait, you mean you want transparent walls back? Or something else?
-
Wait, you mean you want transparent walls back?
Yes.
After trying both, I must say that vanilla lighting is better for me. Don't know how others feel... I might be the only one for all I know.
-
Yes.
I'm not really trying to tell you how to play the game, but you are also and LP-er, and that would be a gross misrepresentation of how the actual mod works.
To be honest I have no idea why you wouldn't like this feature that simply removes a gross simplification of the original engine; to me that is like saying that you'd prefer all maps to only have one level, because having multiple levels is "unnecessary and visually disturbing". I'm not judging, but this sentence is just completely out there to me, I just can't accept it as it is because it sounds... completely random. But okay, people have different needs, maybe there's someone who can only play X-Com when wearing blue slippers or something - I don't have a problem with that. But not having this obvious engine improvement in the LP will in my opinion be harmful for said LP, and with no good reason whatsoever that I could understand and accept.
So yes, as a LP viewer I do have a real problem with this.
-
The old lighting system literally looks like shit compared to the new one, it is also very unnatural (drop a flare on the roof, get the whole building illuminated; and, when you want to hide, the only option is to run, instead of simply stepping into a dark corner), but to each their own... What's need to be done is some ironing out of the new system (light getting trapped in some light-generating objects, only illuminating the floor but not the object or surroundings).
-
@Solarius
I didn't invent this five minutes ago just to start a flamewar or something.
This is my honest assessment, after playing quite a lot.
All maps with artificial lighting look total crap at the moment (sorry for the expression) and maps with natural lighting also look just bad to me. The jagged edges of the cone of light (when going diagonally along the tiles) are pretty irritating and sudden bursts of bright light when opening the doors are also disturbing me (not to mention sometimes they form most weird patterns).
I don't consider this an "obvious" improvement... not everything that is more complicated or more realistic is always an improvement.
I like simple things and many times they work for me a lot better than complicated ones... btw. that's how this game (=xcom) (in my opinion) got so great... by simplifying an immensely complicated alien invasion simulator. Xcom is not a military-grade simulator, nor some kind of "Matrix".
During my time on the forum, I've noticed how you crave for "realism" and come up with things like "many types of alien containment" or "everybody can do everything"... and I respect your opinions... it's just my opinion on this is exactly the opposite. What you call "gross simplification", I call "clever abstraction"... at the end, only thing that counts is the "game experience". And my game experience with the new lighting is worse than is was before.
Lastly, "harmful for the LP" is really just a desperate cry... there's tons of xcom LPs and people watch them now and will continue watching them in the future... with or without this particular game element.
-
I don't consider this an "obvious" improvement... not everything that is more complicated or more realistic is always an improvement.
I like simple things and many times they work for me a lot better than complicated ones... btw. that's how this game (=xcom) (in my opinion) got so great... by simplifying an immensely complicated alien invasion simulator. Xcom is not a military simulator, nor some kind of "Matrix".
Absolutely agreed, but all depends what you consider clever simplification and what you consider dumb simplification... And this will naturally vary between people.
-
I'm not sure if we're supposed to continue this discussion here or on your LP thread, but it does concern features, so...
Okay, so I'm a bad designer, fine. But it's not really a question of "realism", which is obviously impossible in this kind of game - I am well aware of that, I've been making mods for 10 years. I just think the old lighting system looks really bad, and the new one looks way better. Sure, everyone has their standards, but that's not really good enough, otherwise there would be nothing to talk about whatsoever. And I remember many people lauding the new system and not a single voice against it, until now, so I thought it would be worthwhile to speak up.
Anyway, I stated my honest opinion, that's it. I really don't think this is a subject worth a flamewar, especially since I respect you immensely Meridian and that's why I am speaking my mind openly.
-
Talking about LP's, just don't disable it while doing underwater missions in Piratez. The whole visual effect of them depends on this dynamic lighting. Without it, they will look just like any other missions. Normally the ligting is not even noticeable, since the player either fights at night, with the NV, or at day, when everything is fully lit.
-
Talking about LP's, just don't disable it while doing underwater missions in Piratez. The whole visual effect of them depends on this dynamic lighting. Without it, they will look just like any other missions. Normally the ligting is not even noticeable, since the player either fights at night, with the NV, or at day, when everything is fully lit.
It's unlikely that the option will be implemented before I finish the LP :)
It's not my priority and I guess also Yankes has other priorities at the moment. But once I start playing Area 51 (which will be probably the next LP), I'd like to have that option available.
-
Concerning the light engine:
Sometimes there are strange things happening where units apparently are illuminated that appead to be standing in darkness. Picture and save attached. The selected girl just got reaction fired on. I would guess the light responsible is coming from the bush?
-
I will look on this.
-
In Piratez it can be pretty hard to tell when a unit is illuminated or not, because there are many weak light sources and low illumination is sometimes indistinguishable from darkness on some terrains (despite counting as fully illuminated).
-
Thanks!
Also, testing 3.5, I found some funky unit animation.... not sure if it's because of OXC or OXCE, but it doesn't do this in 3.3.
Example here: https://youtu.be/vEJZsesymKA
Don't know how to describe it, hopefully it's visible enough.
EDIT: seems to be an issue with 2x2 units... tanks suffer similar effects
Commit that fix bug with big unit animation: https://github.com/Yankes/OpenXcom/commit/64168e2befa7cf249cf9b549405ce5bef05d88f8
You can cherry-pick it or wait week or two for next version of OXCE
-
Thanks, I'll wait for 3.6.
In the meantime, there is one more CTD bug, probably in OXCE code: https://openxcom.org/forum/index.php/topic,4187.msg75619.html#msg75619
Tested on your "develop" branch.
-
I will look on this.
-
I filter out some less interesting commits. But still over 200 lines.
A bit more readable changelog from 3.3 to 3.5 (merged stuff from vanilla).
New ruleset:
- alienDeployment.cheatTurn ... custom cheat turn
- alienDeployment.turnLimit ... custom turn limit
- alienDeployment.chronoTrigger ... what to do when mission timer expires (win, abort, lose)
- alienDeployment.isAlienBase ... just to mark what is alien base mission, deployment used from alienMission.siteType (not hardcoded "STR_ALIEN_BASE_ASSAULT")
- more info: https://colabti.org/irclogger/irclogger_log/openxcom?date=2016-06-08#l167
- alienDeployment.genMission ... weighted table of missions generated for alien bases (e.g. supply)
- alienDeployment.genMissionFreq ... frequency for these (check xcom1 ruleset for examples)
- mod.defeatScore ... unhardcoded defeat conditions
- mod.defeatFunds ... unhardcoded defeat conditions
- alienMission.siteType ... unhardcoded what site spawns for alien base missions or infiltration missions
- craft.radarChance ... unhardcoded detection chances
- item.waypoints ... changed from boolean to integer
- research.destroyItem ... replacement for user option to spend researched items
- ufo.missionScore ... amount of points awarded every 30 min when UFO is flying (double when landed)
- unit.psiWeapon ... unhardcoded alien psi weapon
- unit.builtInWeaponSets ... before there was only one set
Updates in existing ruleset:
- alienDeployment.markerIcon ... can be custom (ID bigger than vanilla)
- craft can be used as manufacturing requirement
- unhardcoded recovery points for fuel (item.recoveryPoints)
New options:
- QoL: hotkey for soldier autoequip (Z)
- added option to disable soldier diaries (=less stuff in the save file)
- added option for touch interface.... not sure what it is for
- TFTD manufacture rules is now used also for UFO
- removed spend researched items option; added retain corpses option
- predict UFO trajectory option => I don't recommend this, it's slow, sometimes completely wrong and poorly implemented
New GUI:
- added end-game stats screen
Other:
- added mod version to saved games
- unified hostile AI and neutral AI
- changed font format
- added kneel indicator
- disabled reaction fire from beyond range
- changed how infiltration "pact" score is awarded (at month end)
- a lot of soldier diaries/commendations stuff -> can now be tested again and fixed/updated for OXCE
-
Hey Yankes, I've got a CTD bug using OXCE+ 3.5 to play TFTD on Ubuntu, I first checked with Meridian here (https://openxcom.org/forum/index.php/topic,4187.msg76048.html). I've narrowed it down to getTerrainLevel() in Savegame/Tile.cpp. Would you mind taking a look at it?
Edit: With the debugger, it happens at line 300 of Tile.cpp, when checking if a specific tile has a floor - "_object[O_FLOOR]" during a call from TileEngine::addLight, at line 491. In this specific instance when I get the CTD, the position 'center' points to a tile with a memory address of 0x0... which doesn't seem right at all. However, I was able to prevent the CTD by causing the USO to land in a different geoscape texture, so a different map was generated.
More Edit: The position of the tile, 'center', was at x = 54, y = 6, z = 0, but the map size in x was 50, so it was trying to place a light source out of bounds. I'm attaching a save a bit closer to the crash.
-
https://openxcom.org/forum/index.php/topic,4187.msg75725.html#msg75725
-
https://openxcom.org/forum/index.php/topic,4187.msg75725.html#msg75725
It's something else, I get the crash too now with a better save, see attached.
-
Yeah, I've updated my previous post with some more information I was able to get from the crash. The lighting engine is trying to place a source (it looks like it's a tile on fire) out of bounds.
-
ok, I will look on this too.
-
Yeah, I've updated my previous post with some more information I was able to get from the crash. The lighting engine is trying to place a source (it looks like it's a tile on fire) out of bounds.
that was result of completely different bug elsewhere. `init` was call multiple times in `generateMap`. In normal OXC it cause memory leak, in my version it mangle tile data:
https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/SavedBattleGame.cpp#L510
https://github.com/Yankes/OpenXcom/blob/master/src/Savegame/SavedBattleGame.cpp#L483
There is commit for cherry-pick that fix it:
https://github.com/Yankes/OpenXcom/commit/01047ce61a0cba0ea70a517b093d17f9c7a5091b
-
Huh, that's a really strange bug for just moving that line down a few spots. Thanks for looking into it!
-
Huh, that's a really strange bug for just moving that line down a few spots. Thanks for looking into it!
strange is why it surfaced now, not year ago when I made switch from pointers to vector for tiles.
-
So, is this wrong in vanilla too? (it does look wrong to me) We should probably report it if yes...
-
So, is this wrong in vanilla too? (it does look wrong to me) We should probably report it if yes...
Yup, overall `if (!_nodes.empty())` condition is bit dodgy. It hard to say if `_mapDataSets.clear();` should be cleared or not in that case of `case MSC_RESIZE:` in "BattlescapeGenerator.cpp".
-
I tried getting the current git version to run on Ubuntu 64bit. Compiled with CMake, and building & install went fine.
I copied the UFO files, but when I try to start, I get this in the log:
[18-12-2016_13-49-36] [INFO] Data folder is: /usr/local/sharehttps://openxcom/
[18-12-2016_13-49-36] [INFO] Data search is:
[18-12-2016_13-49-36] [INFO] - /home/thesheeep/.local/share/openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/share/ubuntu/openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/share/gnome/openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/local/sharehttps://openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/sharehttps://openxcom/
[18-12-2016_13-49-36] [INFO] - /var/lib/snapd/desktop/openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/local/share/openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/share/openxcom/
[18-12-2016_13-49-36] [INFO] - /usr/local/share/openxcomhttps://
[18-12-2016_13-49-36] [INFO] - ./
[18-12-2016_13-49-36] [INFO] User folder is: /home/thesheeep/.openxcom/
[18-12-2016_13-49-36] [INFO] Config folder is: /home/thesheeep/.config/openxcom/
[18-12-2016_13-49-36] [INFO] Options loaded successfully.
[18-12-2016_13-49-36] [INFO] SDL initialized successfully.
[18-12-2016_13-49-36] [INFO] SDL_mixer initialized successfully.
[18-12-2016_13-49-36] [INFO] requested file not found: openxcom.png
[18-12-2016_13-49-36] [INFO] Attempting to set display to 640x400x8...
[18-12-2016_13-49-36] [INFO] Display set to 640x400x8.
[18-12-2016_13-49-36] [INFO] Loading data...
[18-12-2016_13-49-36] [INFO] Scanning standard mods in '/usr/local/sharehttps://openxcom/standard'...
[18-12-2016_13-49-36] [INFO] Scanning user mods in '/home/thesheeep/.openxcom/mods'...
[18-12-2016_13-49-36] [INFO] no master already active; activating xcom1
[18-12-2016_13-49-36] [INFO] Mapping resource files...
[18-12-2016_13-49-36] [INFO] Resources files mapped successfully.
[18-12-2016_13-49-37] [WARN] disabling mod with invalid ruleset: xcom1
[18-12-2016_13-49-37] [ERROR] failed to load 'UFO: Enemy Unknown / X-Com: UFO Defense'; mod disabled for next startup
Sprite Set BIGOBS.PCK not found
Not exactly sure what to make of that.
-
You probably copy UFO data to wrong place, check if you do it correctly (it should be placed in same place as in normal version of OXC)
-
Well, it says:
Data folder is: /usr/local/sharehttps://openxcom/
and there is an UFO folder in that folder containing the game data.
It works perfectly fine with the normal nightly (Ubuntu package) like that - no worries, I removed that before building OXE.
I just wanted to get Piratez to work on my Ubuntu (there is no prebuilt download for OXE that I could find), but it seems that is out of the question for now.
-
For PirateZ, you will need OXCE+ (OpenXcom Extended Plus), which is a fork of OXCE (OpenXcom Extended).
And there are pre-built executables (also for Linux) here: https://openxcom.org/forum/index.php/topic,4187.0.html
Or directly here: https://lxnt.wtf/oxem/
For current PirateZ version (0.99e2) you will need version 3.3, not 3.5.
-
Well, it says:
Data folder is: /usr/local/sharehttps://openxcom/
and there is an UFO folder in that folder containing the game data.
It works perfectly fine with the normal nightly (Ubuntu package) like that - no worries, I removed that before building OXE.
I just wanted to get Piratez to work on my Ubuntu (there is no prebuilt download for OXE that I could find), but it seems that is out of the question for now.
how look nightly log? It should look exactly same and work sane but as we see is not. you compiled my OXCE yourself and nightly is downloaded?
and for Piratez as Meridian said it use this branch that is based on my. Biggest difference is lack of UI improvements from Meridian, another some new gameplay mechanics added but not yet ported to my brach (I plans get most of them to my branch at some point).
-
For PirateZ, you will need OXCE+ (OpenXcom Extended Plus), which is a fork of OXCE (OpenXcom Extended).
Ah, no wonder I got confused about that.
Well, I'll have a shot at it then with the prebuilt ones.
Edit: Works!
-
Earnest request, specify the option, or come up with a way to turn off the aliens berserk. And just berserk. Since the aliens at Berserker still attack the nearest target player and from their usual activities, in this case, the berserker no different. Panic option in MC destroyer, totally and absolutely useless. In addition, strongly tired explosions berserk inside the ships, which deprive prisoners of frags and valuable.
Убедительная просьба, указать опцию, или придумать способ отключения берсерка у пришельцев. Причём только берсерка. Поскольку пришельцы при берсерке всё равно атакуют ближайшую цель игрока и от обычных их действий, в этом случае, берсерк не отличается ничем. Опция паники в МК разрушителе, полностью и абсолютно бесполезна. Кроме того, сильно надоели взрывы берсеркующих внутри кораблей, которые лишают фрагов и ценных пленных.
-
I interested in adding gameplay mechanics than removing ones. I see little value in only removing berserker. I could only do something like this as part of bigger change, but right now I don't have plans do anything around this parts of game.
-
I interested in adding gameplay mechanics than removing ones. I see little value in only removing berserker. I could only do something like this as part of bigger change, but right now I don't have plans do anything around this parts of game.
It is a pity. But I meant no total elimination berserk, and the option to "units.rul" like "noBerserk: true", which can be switched on and off at will.
By the way, if you develop the idea and "noBerserk:" add "noPanic:" and "noMindControl:", It can get interesting combinations. For example Mouton is so fierce that he never panic, just go crazy. And so on.
Очень жаль. Но я имел ввиду не тотальную ликвидацию берсерка, а опцию для "units.rul" вроде "noBerserk:: true", которую пожно включить и выключить по желанию.
Кстати, если развить мысль и к "noBerserk:" добавить "noPanic:" и "noMindControl:", могут получится интересные комбинации. Например Мутоны настолько свирепы, что никогда не паникуют, а только сходят с ума. И так далее.
-
Yup, overall `if (!_nodes.empty())` condition is bit dodgy. It hard to say if `_mapDataSets.clear();` should be cleared or not in that case of `case MSC_RESIZE:` in "BattlescapeGenerator.cpp".
initMap is also triggered on stage changes, so better safe than sorry. MSC_RESIZE is only intended to be used at the start anyways.
-
I tried to give some alien units a personal light with
personalLight: 15 #solder light radius.
but it had no effect.
Does the "personalLight" intentionally works only for units controlled by the player?
-
Hi Yankes,
another nasty bug in oxce or vanilla, where I need your help: https://openxcom.org/forum/index.php/topic,4058.msg76911.html#msg76911
In the meantime, I will try to reproduce:
- in vanilla (no piratez) using oxce
- in vanilla (no piratez) using oxc ... and report to warboy, if it happens there too
Thanks for any help.
-
Hi Yankes,
another nasty bug in oxce or vanilla, where I need your help: https://openxcom.org/forum/index.php/topic,4058.msg76911.html#msg76911
In the meantime, I will try to reproduce:
- in vanilla (no piratez) using oxce
- in vanilla (no piratez) using oxc ... and report to warboy, if it happens there too
Thanks for any help.
This is very similar to bug with stunning flying unit on edge of map, I will try fix it.
-
Happy New Year! New ideas, opportunities and mods!
-
I plan in this or next week release new version. Probably biggest change will be scripts that will be able to change how damage is apply to unit.
Possible usage:
a) Hand held shield that will boost front armor
b) Personal force field (armor or item in hand, limited use)
c) Toxin that work only on some units
d) Paint that will expose invisible units
e) Poison that will last couple of turn
f) Energy pack that will boost laser power when held in other hand
g) Laser weapons will have soft ammo limit after that it will do less damage (battery will run low, better buy some based on elerium :D )
-
Ok new version 3.3 is ready:
New light system.
Option for reserving more space for mod in common surface/sound sets.
Visibility scripts that determine visibility of targets.
The mod size feature doesn't work 100% yet.
Attached is a simple mod for vanilla that will crash (make sure it's the first/topmost mod in the list when testing).
I have prepared a fix too: https://github.com/MeridianOXC/OpenXcom/commit/258581e6378f53994e67364eda51e307bf4917be
Could you review if it's OK?
-
if (!modInfo.isMaster() && !modInfo.getMaster().empty() && modInfo.getMaster() != curMaster)
This `&&` are correct there? because you update `maxSize` when:
modInfo.isMaster() || modInfo.getMaster().empty() || modInfo.getMaster() == curMaster
If mod is not master but still will bump up `maxSize`.
-
Yes, that is correct.
There's one more check above, so together it is:
modIsEnabled && ( modInfo.isMaster() || modInfo.getMaster().empty() || modInfo.getMaster() == curMaster )
That means, maxSize is updated from:
- current (enabled) master
- all (enabled) mods without a master ("*" in metadata.yml)
- all (enabled) mods of the current master
PS: I copypasted these two conditions from mapResources() method
If mod is not master but still will bump up `maxSize`.
Yes, the idea is that the "root master" must have the same size as the biggest mod (regardless if the biggest mod is a master or not).
Example:
- root master = xcom1 = size 1
- piratez master by dioxine = piratez = size 3
- someone's mod for piratez = somecode = size 7
In this example, it is necessary to set the size of the root master (xcom1) to 7.
-
Ok, now I understand intend of this code. Over all code look fine, I will pull it to next release.
-
Hey Yankes, I'm trying to use your scripts to change a weapon's sprites based on the ammunition it has loaded. I've got it working for Bigobs in the inventory screen, but not the ones in the Battlescape UI or for Handobs. Is it possible to change handobs and the left/right hand weapon sprites not in the inventory with extended scripts? Here's what I have for the Bigobs:
extended:
tags:
RuleItem:
XPIRATEZ_ISRPG: int
XPIRATEZ_ISBABYNUKE: int
XPIRATEZ_ALTHANDOB: int
XPIRATEZ_MOD_OFFSET: RuleList
scripts:
selectItemSprite:
- offset: 1
code: |
var ptr BattleItem ammoItem;
var ptr RuleItem weaponRuleset;
var ptr RuleItem ammoRuleset;
var int rpgTag;
var int nukeTag;
var int modOffset;
if or eq blit_part blit_item_big eq blit_part blit_item_lefthand eq blit_part blit_item_righthand;
item.getRuleItem weaponRuleset;
weaponRuleset.getTag rpgTag Tag.XPIRATEZ_ISRPG;
if eq rpgTag 1;
item.getAmmoItem ammoItem;
ammoItem.getRuleItem ammoRuleset;
ammoRuleset.getTag nukeTag Tag.XPIRATEZ_ISBABYNUKE;
if eq nukeTag 1;
weaponRuleset.getTag sprite_index Tag.XPIRATEZ_ALTHANDOB;
weaponRuleset.getTag modOffset Tag.XPIRATEZ_MOD_OFFSET;
rules.getSpriteOffsetBigobs sprite_index modOffset;
return sprite_index;
end;
end;
end;
return sprite_index;
items:
- type: STR_RPG
tags:
XPIRATEZ_ISRPG: 1
XPIRATEZ_ALTHANDOB: 0
XPIRATEZ_MOD_OFFSET: current
- type: STR_BABY_NUKE
tags:
XPIRATEZ_ISBABYNUKE: 1
-
Ok, I look in code and I see that I didn't call script in that case. Sorry for that, I will fix in next release.
-
Yankes, how do I disable Panic and Mind Control on a psi weapon? I want to only use psi damage.
-
set time units to zero for each action e.g. `costMindControl`and `costPanic`.
-
set time units to zero for each action e.g. `costMindControl`and `costPanic`.
I tried it before and it crashes my game...
Here's the item:
- type: STR_STAFF_OF_HEART_GRIP
categories: [STR_HUMAN_TECH, STR_PSI, STR_OTHER, STR_UNDERWATER]
requires:
- STR_STAFF_OF_HEART_GRIP_USE
size: 0.3
costSell: 50000
weight: 5
bigSprite: 537
floorSprite: 438
handSprite: 1136
hitSound: 250
hitAnimation: 156
psiAttackName: STR_CRUSH_THE_HEART
damageType: 5
damageBonus:
psi: 0.02
damageAlter:
ResistType: 6
RandomType: 6
ArmorEffectiveness: 0
ToArmor: 0
ToMorale: 3.0
accuracyUse: 15
costUse:
time: 28
energy: 20
stun: 7
costThrow:
energy: 10
costMindControl: 0
costPanic: 0
clipSize: -1
battleType: 9
twoHanded: true
invWidth: 2
invHeight: 3
maxRange: 20
attraction: 10
-
this is complex property like `costUse` it should look like:
costUse:
time: 28
energy: 20
stun: 7
costMindControl:
time: 0
costPanic:
time: 0
btw "crashes" is not correct word in that context, probably better would be "its fail to load" or "yaml throw a error" :)
-
Thanks, it works!
btw "crashes" is not correct word in that context, probably better would be "its fail to load" or "yaml throw a error" :)
Yeah, sorry, it was really late when I wrote that. :P
-
Hey Yankes! Meridian and I have been trying to track down a bug with the auto-equip key, first reported in this thread: https://openxcom.org/forum/index.php/topic,5047.msg77589.html#msg77589
When pressing "Z" or whatever key auto-equip is bound to, the game Segfaults sometimes when trying to move or interact with an item that was moved by the auto-equip function. I've tested this in a clean Ubuntu build of your OpenXcomExtended branch, no mods loaded. This seems to be an issue with how the items are moved between classes when auto-equipping, and I think it has to do with the 'dummy' SavedBattleGame you use when calling this function (https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/InventoryState.cpp#L821). I was able to prevent the CTD by changing 'dummy' on this line to '_battleGame,' but this causes issues later when the SavedBattleGame is cleaned up. My guess is that when the dummy SavedBattleGame is removed at the end of InventoryState::onAutoequip, this re-allocates the memory for the pointers to the BattleItems (dummy's _items list is deleted), and so the pointer to the item may or may not be available after this function call.
To replicate:
- Delete options.cfg and battle.cfg
- Run game and load quick battle
- Click 'OK' to bring up the briefing, then inventory screen
- Press 'X' to clear the current soldier's inventory, then 'Z' to autoequip
- Either trying another action (clicking or key press), or even waiting for a few seconds, causes Segfault for me
The above does not work in all cases though - Meridian hasn't been able to reproduce the bug this way, and some other Windows users have been able to use it just fine, but I get CTD on Linux every time I try using auto-equip. Would you mind testing this?
Edit: As a matter of curiosity, what was the reasoning behind moving addItem from BattlescapeGenerator to SavedBattleGame during the merge with the nightly to include this feature?
-
For end:
Because you can add items during battle too. Extended can spawn any item on new crated unit not only terror weapons like basic version.
Windows is probably in exactly same way broken, difference is how systems handle released memory if it not send back to operating system you can still access values in it even if object is deleted.
Overall your analyst is probably right, I will try fix it tomorrow.
[ps]
did you trying clearing `_items` without deleting them?
[ps2]
commit with fix for cherry pick: https://github.com/Yankes/OpenXcom/commit/a4d390083ca5ce0fd2d9c175a6026f5b52e7efc2
-
Hello Yankes
I was curious to know if there was a few things that could be added as features eventually. I've searched the forums, so if this has been mentioned before, I'm sorry but the search can be picky about terms.
Have you considered the possibility of adding a second ammo type(s) for alternate fire possibilities?
For example an M4 with a grenade launcher or underslung shotgun
https://en.wikipedia.org/wiki/M203_grenade_launcher
https://en.wikipedia.org/wiki/KAC_Masterkey
Thanks
-
That would probably be hard, code-wise... But I would certainly welcome such an addition.
The problem from the modder side would be limited space for firing selection menu. If a weapon has all three firing modes and a melee attack, and of course it can be thrown, it already takes pretty much the entire screen. Adding more would only be possible for higher resolutions, but that would go against vanilla.
But it would be a cool feature to play with. I do miss it sometimes.
-
If a compromise had to be made, why not let it be if there is an alternate fire mode then melee is disallowed?
-
After some thoughts I decide that I will implements it after 3.6. One important aspect will be that you will be still limited to only 3 attacks, and each one will have option to decide what "ammo slot" it will use. This will require small unification of each attack type. Another thing is how will be second ammo reloadable, I think best way will be "hot swap", when you drop new ammo item on weapon in hands then it will unload current one and load new one.
-
Very Clever!
I think a hot swap is a great idea... but would that mean the unload button does nothing?
or
would that mean that if you "unload" a weapon that only the primary ammo would come out leaving the secondary until you pressed unload again, where then the secondary ammo would come out?
also
Two, with hot swap ammo if you were to attempt to reload an HE grenade on top of a Smoke grenade we would seamlessly see a swap and pay the cost of unload and reload? or reload only, or something else?
You know.
I actually think this will be REALLY cool.
Yankes, as I'm writing this you've got me thinking.... What about a "tactical" reload option that I guess would piggy back on the back of the idea hot swap.
That is to say. If you drop a fresh magazine onto a weapon it swaps the magazines for reload cost. You know for like when you have 2 bullets left and know there are lots of dudes in a building so you pop in a fresh magazine but with less hassle since you don't have to Unload and then reload.
thoughts?
-
For unload button I think best would be that it will try first remove normal ammo and if is already removed it will do it for second one.
For "hot swap" I think about this as combination of unload & load in one move with cost equal of sum of both.
Tactical will probably need to wait for another time :)
-
Hi Yankes, I have to say this is an awesome mod! But sadly I can't seem to get it working right.. For some reason it conflicts with the Equal Terms 2.0 mod by KingMob4313 (https://openxcom.org/forum/index.php/topic,3680.0.html (https://openxcom.org/forum/index.php/topic,3680.0.html)). Whenever I enter a soldier's inventory, all the grenades or explosives seem to be tagged with a massive black shadow. Strangely the smoke grenades seem to be untouched. Is there any way around this? Really hope to be able to play through a campaign with both mods operating!
Ps. I tried it with various nightlies and various versions of OXCE+ from Nov 16 till today but no combination seems to solve it :'(
-
Ps. I tried it with various nightlies and various versions of OXCE+ from Nov 16 till today but no combination seems to solve it :'(
Well, if you tried vanilla nightlies, OXCE and OXCE+... and none worked... then the problem is in the Equal Terms 2.0 mod, no?
EDIT: yup, images in the mod have wrong palette, sample attached
-
Well, if you tried vanilla nightlies, OXCE and OXCE+... and none worked... then the problem is in the Equal Terms 2.0 mod, no?
EDIT: yup, images in the mod have wrong palette, sample attached
Thanks for the quick reply, Meridian. Sorry I'm quite new to Xcom Modding so would that mean that it is too time consuming or even impossible to fix? If it's possible to make it work in a reasonable amount of effort, I wouldn't mind giving it a go.
-
Thanks for the quick reply, Meridian. Sorry I'm quite new to Xcom Modding so would that mean that it is too time consuming or even impossible to fix? If it's possible to make it work in a reasonable amount of effort, I wouldn't mind giving it a go.
It's definitely possible.
I don't know how long it would take... 1 to 5 minutes per image? Depending on your tools and practice. Basically all you need to do is convert all images to correct palette(s).
-
It's definitely possible.
I don't know how long it would take... 1 to 5 minutes per image? Depending on your tools and practice. Basically all you need to do is convert all images to correct palette(s).
Oh that's a relief! I found an old thread on palettes so will give it a go in the morning, although it sure has been a while since I've dabbled with paint programs lol. Thanks again.
EDIT: All fixed and can't be happier!
-
Hi Yankes, I was wondering if you had any plans to adding in a visual for explosion blast radius as like in https://openxcom.org/forum/index.php/topic,1532.0.html (https://openxcom.org/forum/index.php/topic,1532.0.html)? I think it would be quite useful seeing there are so many different explosives in the game now.
-
Hi Yankes, I was wondering if you had any plans to adding in a visual for explosion blast radius as like in https://openxcom.org/forum/index.php/topic,1532.0.html (https://openxcom.org/forum/index.php/topic,1532.0.html)? I think it would be quite useful seeing there are so many different explosives in the game now.
I do not have any, overall I try focus on game mechanic than UI improvements.
-
I do not have any, overall I try focus on game mechanic than UI improvements.
Oh that is true, mechanics would be a bigger priority, but thanks anyhow.
-
What about external ECMA scripts support with duktape (https://duktape.org/), for example.
I dream about openxcom with JSON instead yml, ECMA bindings for most engine function and all not heavy/critical logic in scripts.
-
What about external ECMA scripts support with duktape (https://duktape.org/), for example.
I dream about openxcom with JSON instead yml, ECMA bindings for most engine function and all not heavy/critical logic in scripts.
If you propose this two years ago I could use it, right now I'm rolling my own script engine.
btw yaml is supporting JSON syntax.
-
btw yaml is supporting JSON syntax.
Good!
If you propose this two years ago I could use it, right now I'm rolling my own script engine.
Not good :'(
What you think about airstrikes in tactical battles? I want do code for this.
Also I have some code for AI indirect/suppressive fire. Interesting?
-
What you think about airstrikes in tactical battles? I want do code for this.
Needs more explanation.
Depending on what it is exactly, it may be supported in OXCE/OXCE+ already.
Also I have some code for AI indirect/suppressive fire. Interesting?
Again, please give more info.
-
Needs more explanation.
If craft with weapon in begin of assault ufo mission and located at same with ufo point, it can do airstrike in battlescape. At first turn virtual unit move from edge to edge of map and fire along flight path. We can select point for attack, type of strike (hedgehop with long attack path/dive with one point of attack). Craft weapon must have reference to battlescape weapon for this.
Again, please give more info.
Some old code. Aliens can do suppressive fire and use explosives indirect. If xcom agents use smoke and aliens see it, they may use firearm/grenade. If xcom agents fire they discover his position for aliens. It is looks like real war. See this branch: https://github.com/Crutchmaster/OpenXcom/tree/ai_tweaks
-
If craft with weapon in begin of assault ufo mission and located at same with ufo point, it can do airstrike in battlescape. At first turn virtual unit move from edge to edge of map and fire along flight path. We can select point for attack, type of strike (hedgehop with long attack path/dive with one point of attack). Craft weapon must have reference to battlescape weapon for this.
This have low grain/cost ration, lot of code to add one feature that will not be used in any other place. I prefer other way around.
Probably at some point this will be possible as side effect of other changes I will made (e.g. script spawning explosions on the whim).
For AI changes, its hard to tell how it will affect gameplay. If other people would like have it too then I could add this.
-
Sneak peek of new feature of 3.6:
-
I've watched it like 10 times and still no idea what the feature is. What's new about this clip (apart from non-vanilla unit)?
-
Did you see that enemy change look when hit? This will allow:
You can have visual feed back when you do damage to unit (it will flash read for second if you do more than 1% damage)
Force field will flash when it block damage
Custom dead animations based for kill weapon
-
Did you see that enemy change look when hit?
To be honest, I did not. I expected to see something like this, and I've seen the colours change, but I couldn't link it to events that happened. I thought the unit changed colour after being targeted with cursor, but it didn't seem quite right. Only after you explained that it changed colour after being hit I could see it happening, but it's not obvious at all.
This will allow:
You can have visual feed back when you do damage to unit (it will flash read for second if you do more than 1% damage)
Force field will flash when it block damage
Custom dead animations based for kill weapon
Yes, these are all useful effects to have. I'm especially interested in the last one.
How is these effects achieved? With scripts or ruleset settings?
-
by script, that was hole point :)
For simply recoloring you need add one script and mark weapons witch color use to paint unit/corpse.
Overall goal is you add one script or two and then using `tags:` like it was builtin ruleset settings.
-
Hey Yankes, perhaps you could make a thread in this sub-forum to post examples of scripts with a description of what they do? I think it would be helpful if we had a compilation of scripts so modders can either copy-paste what functionality they want into their mod or get an idea of how to write their own scripts. For example, we could start with your night vision items, animated flying sprites, and hit indication scripts, and I have one to change weapon sprites based on ammo loaded.
-
Hey Yankes, perhaps you could make a thread in this sub-forum to post examples of scripts with a description of what they do? I think it would be helpful if we had a compilation of scripts so modders can either copy-paste what functionality they want into their mod or get an idea of how to write their own scripts. For example, we could start with your night vision items, animated flying sprites, and hit indication scripts, and I have one to change weapon sprites based on ammo loaded.
Good idea, if you want right now some example are include in readme file.
-
New version 3.6 is ready:
Config for new lighting system.
New map script options made by ohartenstein23.
New scripts for items and units.
Add option for grenades to explode in hand.
Changes in handling items with prime.
Primed grenades are not recoverable if consumable property is set.
-
Could you elaborate what config for lighting system means?
I'm very curious, as the lighting system/ night vision systems are very cool and I think there is still a whole lot more development to be done that area.
-
Could you elaborate what config for lighting system means?
I'm very curious, as the lighting system/ night vision systems are very cool and I think there is still a whole lot more development to be done that area.
On/off and some limits for performance.
-
Hey Yankes (and for Meridian too), I realized I forgot to update my documentation in Extended.txt when I re-did the alternate terrain code to use only vanilla map script commands - here's a link to a commit updating the documentation to reflect the changes (https://github.com/ohartenstein23/OpenXcom/commit/4a0f3c1403b9b29a19974f926304e4f0797cd504).
-
https://github.com/Yankes/OpenXcom/commit/a3313b37e3576abf47038ec19baa8740746a6a36#diff-fdb750f79815e6f226fa1b1569ac12e4
Why change the timer from 125 to 100 ms?
Feels quite weird now :/
-
Because you can now animate whole item HandOb sprite in inventory and on battle screen. To made both run on same pace I need adjust it in inventory.
If it too much off putting then I could tweak it a bit to restore original behavior.
-
Because you can now animate whole item HandOb sprite in inventory and on battle screen. To made both run on same pace I need adjust it in inventory.
If it too much off putting then I could tweak it a bit to restore original behavior.
Don't know... just noticed it immediately after upgrading... let me play with it for a few days, maybe I'll get used to the new one quickly.
-
Hey Yankes, I have a question about item ruleset tags in scripts - when I initialize an int variable in a script without setting a value to it, then use getTag on a weapon ruleset to get a value, what does it default to when the weapon is missing that tag? That is, can I check to see if the variable got a tag value with something simple like this?
If neq variableWithTagValue 0
... # continue with rest of script if tag exists on weapon
Edit: Nevermind, I checked it and it works fine like that. Another question though - how do I get the proper mod offset for handobs? There's a function to get the offset for bigobs and floorobs, but not for handobs.
More Edit: Sorry for all the questions, but I ran into another issue with re-selecting the sprites for a weapon handob. Is there a way to check whether or not the weapon is being fired when re-selecting the sprite with selectItemSprite? I'm working on a script that changes the sprite based on loaded ammunition, but when firing a two-handed weapon, the sprite for turning the weapon from the 'held' to the 'firing' position remains in the 'held' position, so it looks like my soldier is firing out the side of the gun.
Even More Edit: Ah, sprite_offset handles all of the handob direction stuff. Got the previous question figured out then, and I used rules.getSpriteOffsetBigobs for the mod offset for handobs - will that have any unintended consequences?
-
Hey Yankes, I have a question about item ruleset tags in scripts - when I initialize an int variable in a script without setting a value to it, then use getTag on a weapon ruleset to get a value, what does it default to when the weapon is missing that tag? That is, can I check to see if the variable got a tag value with something simple like this?
If neq variableWithTagValue 0
... # continue with rest of script if tag exists on weapon
Edit: Nevermind, I checked it and it works fine like that. Another question though - how do I get the proper mod offset for handobs? There's a function to get the offset for bigobs and floorobs, but not for handobs.
More Edit: Sorry for all the questions, but I ran into another issue with re-selecting the sprites for a weapon handob. Is there a way to check whether or not the weapon is being fired when re-selecting the sprite with selectItemSprite? I'm working on a script that changes the sprite based on loaded ammunition, but when firing a two-handed weapon, the sprite for turning the weapon from the 'held' to the 'firing' position remains in the 'held' position, so it looks like my soldier is firing out the side of the gun.
Even More Edit: Ah, sprite_offset handles all of the handob direction stuff. Got the previous question figured out then, and I used rules.getSpriteOffsetBigobs for the mod offset for handobs - will that have any unintended consequences?
sh***, very big fail on my part not adding handob offset function :/ This will be first thing I will add to 3.7, same for aiming status.
This offset function are separate because each graphic set can have different number of graphic that belongs to base mod. If you use wrong one It could select incorrect graphic from set.
[ps]
If you want you can grab commits with missing functionality:
https://github.com/Yankes/OpenXcom/commit/1b872dd22fc84f6b0cad82033bdb4e5e6922e3c9
https://github.com/Yankes/OpenXcom/commit/122d749fdd330d00b15e2bcc66ba7a3af4f1489e
-
When are newTurnItem and createItem scripts run? I can see tags set by newTurnItem in a saved game, but only at the beginning of turn 2, not at the start of a battlescape instance, and I can't see any tags set by createItem in the save file at all.
Edit: I have another question too - when I use a newTurnItem script, item is a ptre pointer to a BattleItem - how is this different from a ptr, and is there a way to use item.getTag? Right now I get an error in my log file saying that getTag only works on ptr's to BattleItems, not ptre's.
-
I will probably release bug fix version :/ Again I forget call `createItem` script in code. Sorry again for that, and I very thankful for your testing.
`newTurnItem` is call for each change of current fraction, e.g.
xcom turn, newTurnItem, alien turn, newTurnItem, neutral turn, newTurnItem, xcom turn, ... etc.
`createItem` should be called before battle when items are created.
same as similar unit functions.
`ptre` - is pointer to editable object
`ptr` - is pointer to readonly object
`getTag` should work on both, difference is `setTag` that only work on `ptre` because you change state of object.
Could you show error you get?
-
For AI changes, its hard to tell how it will affect gameplay. If other people would like have it too then I could add this.
I try, but I don't have so much language skills:) If aliens shoot you from house, for example, you destroy this house with explosives and/or automatic weapons. This path add something like this for AI.
https://github.com/Crutchmaster/OpenXcom/tree/oxce_indirect_fire
This code says better. Build them and play some battles on farm.
-
Sorry I haven't posted that error yet - I forgot about it. I'll post it later today.
Could I make some requests for new script features? If it's not there, I think it would be nice to have an RNG function available in script, either between two ints or simply between 0 and 100, and we can rescale with math as necessary. Also, could damage type and resist type from an attack be passed to hitUnit and damageUnit?
A bit more out there, but would it be possible to let a tag hold a pointer to a RuleItem or a RuleArmor? Something like TAG_POINTING_TO_ARMOR: STR_SOME_ARMOR? I was thinking of creating something like a metal shield that reduces incoming damage and has its own damage resistances, and having a 'dummy' armor for it would be nicer than making a new tag for each damage type.
Edit: I can't re-create the previous error I was getting, it's working just fine now. I'll let you know if I see it again.
-
Sorry I haven't posted that error yet - I forgot about it. I'll post it later today.
Could I make some requests for new script features? If it's not there, I think it would be nice to have an RNG function available in script, either between two ints or simply between 0 and 100, and we can rescale with math as necessary. Also, could damage type and resist type from an attack be passed to hitUnit and damageUnit?
A bit more out there, but would it be possible to let a tag hold a pointer to a RuleItem or a RuleArmor? Something like TAG_POINTING_TO_ARMOR: STR_SOME_ARMOR? I was thinking of creating something like a metal shield that reduces incoming damage and has its own damage resistances, and having a 'dummy' armor for it would be nicer than making a new tag for each damage type.
Edit: I can't re-create the previous error I was getting, it's working just fine now. I'll let you know if I see it again.
I plan add random in 3.7. For damage type I will add this is bugfix release in this week.
For "pointer to armor" I have long term plans to add some thing like that.
-
Okay, thanks!
-
Bugreport:
This: https://github.com/Yankes/OpenXcom/commit/3b8032f80d4c1bafd86310009185ddf7c2649458 doesn't actually remove all parts of a big unit.
And causes recovery of twice as many corpses as side effect when unconscious unit on the ground is killed.
To fix I guess it's enough to put "++it;" inside "else { }" clause.
-
Bugreport:
This: https://github.com/Yankes/OpenXcom/commit/3b8032f80d4c1bafd86310009185ddf7c2649458 doesn't actually remove all parts of a big unit.
And causes recovery of twice as many corpses as side effect when unconscious unit on the ground is killed.
To fix I guess it's enough to put "++it;" inside "else { }" clause.
Good catch, I will fix it.
-
There's a bug with pre-primed grenades and the new exploding in hand code: vanilla grenades, which should not explode in hand, do so when pre-primed before a mission with 0 timer, but only when the battle is first started from the geoscape. Saving during the first turn and reloading prevents them from going off until thrown.
-
There's a bug with pre-primed grenades and the new exploding in hand code: vanilla grenades, which should not explode in hand, do so when pre-primed before a mission with 0 timer, but only when the battle is first started from the geoscape. Saving during the first turn and reloading prevents them from going off until thrown.
Fixed, tomorrow or in next day I will publish new bugfix version of 3.6a.
For more impatient people there is source code available: https://github.com/Yankes/OpenXcom/commits/OpenXcomExtended
-
Bug fix version 3.6a is read:
Fix couple of bugs.
Add some missed scripts.
Add damage type param to unit damage script.
-
I have a feature request.... a big one.
Definable minimum attributes of soldiers. That is to say that they the rookies recruited will meet a player defined stat criteria. With the more stringent the requirements defined, the more you pay initially and the longer the wait time on receiving new recruits.
It is cookie season so I'll even ship you a couple of boxes of thin mints from the girl scouts :)
-
This is doable already, also in vanilla.
You can define soldier types with higher minimum stats and bigger initial pay/salary.
-
Bugreport: hit script engine "randomly" overwrites side and bodypart
e.g.
front/torso hit gets overwritten with left/head hit
rear/torso hit by left/leftarm hit
etc.
Tested on vanilla without any scripts.
-
I mess up order of this two parameters side <=> bodypart I will fix it right away.
[ps]
bug fix: https://github.com/Yankes/OpenXcom/commit/b2125b7a00bbedb8ee4ec8ecd90b67999907a78a
[ps2]
new version is up
-
Hey Yankes, is it possible to get the type of action used during hitUnit or damageUnit? That is, can I use a script to differentiate between being hit by melee, aimed shot, auto shot, snap shot, and throwing actions?
-
Hey Yankes, is it possible to get the type of action used during hitUnit or damageUnit? That is, can I use a script to differentiate between being hit by melee, aimed shot, auto shot, snap shot, and throwing actions?
I have plans to add this in future, same as adding shooting weapon too.
-
This is doable already, also in vanilla.
You can define soldier types with higher minimum stats and bigger initial pay/salary.
Yes, but not in a way I find to be mechanically or aesthetically representative of what I am looking for. I cannot define recruitment parameters of soldiers and then recruit soldiers from a single soldier entry. Instead I must add multiple entries or types of soldiers.
I instead would like base the cost of percentile chance of a particular stat category. I could post some clever math about it, but I won't bother if you don't think it is worth it.
thanks
btw, is energy recovery still initial TU/3?
-
Yes, but not in a way I find to be mechanically or aesthetically representative of what I am looking for. I cannot define recruitment parameters of soldiers and then recruit soldiers from a single soldier entry. Instead I must add multiple entries or types of soldiers.
I instead would like base the cost of percentile chance of a particular stat category. I could post some clever math about it, but I won't bother if you don't think it is worth it.
To be honest, I don't understand what you just said at all... like, really don't understand.
If you have just one "entry", then you have just one "price" and one set of (min-max) parameters.
Can you make a few annotated screenshots/mockups to illustrate your ideas? Maybe that could help me understand...
btw, is energy recovery still initial TU/3?
By default, yes.
But you can override it... PirateZ already changed that long ago for example.
-
Sure!
It will be tomorrow.
-
Hi Yankes,
quick question: when is this code (in mapdata.cpp) used? and for what?
https://github.com/Yankes/OpenXcom/commit/fff64519ec2703df7995773816992d714157b6fa#diff-c89e1363278b09061cd6d81fca7e79eeR176
-
Explosion propagation, overall when you add 10 more damage types it should be refactored to two ifs.
-
Explosion propagation, overall when you add 10 more damage types it should be refactored to two ifs.
That's exactly why I asked :)
I was wondering if that "default:" branch is important or if it could return _block[2] as well?
-
That's exactly why I asked :)
I was wondering if that "default:" branch is important or if it could return _block[2] as well?
default probably should be removed, previously it handled not used in this contexts damage types and now when nearly everything use `_block[2]` it lost its meaning.
-
"You can train your solders basic skills."
How can i do this? Need building? Where is this option?
-
"You can train your solders basic skills."
How can i do this? Need building? Where is this option?
You can do this by writing your own mini-mod... or using an existing mod which is already doing it.
Yes, you need a building (either new or existing one).
It's not an option.
-
You can do this by writing your own mini-mod... or using an existing mod which is already doing it.
Yes, you need a building (either new or existing one).
It's not an option.
Sorry can you give me the steps? I load my save from openycom nightly and i dont see building? Whish mod is this? Or need new game?
Thank you!
-
Or need new game?
No, you can use your existing save.
Which mod is this?
For example "PirateZ" or "X-Com Files" have training facilities.
I load my save from openxcom nightly and i dont see building?
You need OpenXcom Extended (OXCE) or OpenXcom Extended Plus (OXCE+) for this feature; OpenXcom nightly is not enough.
Sorry can you give me the steps?
1. Install OXCE+
2. Write a small mod that adds training capacity for example to living quarters (see OXCE documentation or inspire yourself by mods I listed above)
3. Enable mod
-
No, you can use your existing save.
For example "PirateZ" or "X-Com Files" have training facilities.
You need OpenXcom Extended (OXCE) or OpenXcom Extended Plus (OXCE+) for this feature; OpenXcom nightly is not enough.
1. Install OXCE+
2. Write a small mod that adds training capacity for example to living quarters (see OXCE documentation or inspire yourself by mods I listed above)
3. Enable mod
Thank you!
But, OCXE feature this:
1.6:
You can train your solders basic skills.
Aliens weapon types/weapons can have different turn restriction.
You can rename weapon slot names in geoscape craft info.
So, why need other mod for training? Its not inside OCXE?
-
I give up.
Somebody else please answer Biggieboy's question...
-
With engine edits, most of what's being added is the possibility to do these things through mods; the mechanics of training soldier stats besides Psi Skill at a base facility are in OXCE, but are not used until a mod defines a facility that uses them. Examples of mods that do this are Piratez and X-Com Files, since they both run on the OXCE+ engine. In order to use this feature in the base game, you need to write a small mod that tells the engine you want a facility to train your soldiers.
-
I understood the question as "Do I need OXCE+, or is OXCE enough?". AFAIK this feature is available in OXCE.
If the meaning is something else, then I give up too. :P
-
"You can train your solders basic skills."
How can i do this? Need building? Where is this option?
Think in this way. OpenXcom is a engine that have some improvements, but it is basically "vanilla" Xcom we all know and love. It let you run the game, and yes, some mods too, but only in the framework of the original game mechanism.
OXCE and OXCE+ are modifications, addons, improvements, or whatever you want to name it, that let you do some other stuff that in "vanilla" OXC is not possible. This is, it add some other mechanisms that are not in the normal game. But, you need a mod that use those mechanisms for these to work. OXCE and OXCE+ are not mods for the game, but for the engine.
One example of this is the possibility to add pilots to the ships. It is not a vainilla feature, and is very hard that you will see it in OpenXcom in the short place (Or ever). But OXCE+ add this possibility. The thing here is the word possibility. If you´re a modder, you can use it in your mod, but if you don´t want, you don´t. It is the same with OXCE and training soldiers.
I hope this help to clarify some misunderstandings.
-
With engine edits, most of what's being added is the possibility to do these things through mods; the mechanics of training soldier stats besides Psi Skill at a base facility are in OXCE, but are not used until a mod defines a facility that uses them. Examples of mods that do this are Piratez and X-Com Files, since they both run on the OXCE+ engine. In order to use this feature in the base game, you need to write a small mod that tells the engine you want a facility to train your soldiers.
Thats correct answer!
And need to chang this:
"You can train your solders basic skills."
To this:
"You can train your solders basic skills. (with mod)"
-
Sorry, I don't see a reason to add " (with mod)." after each line in the changelog.
... because yes, it applies to everything.
-
Think in this way. OpenXcom is a engine that have some improvements, but it is basically "vanilla" Xcom we all know and love. It let you run the game, and yes, some mods too, but only in the framework of the original game mechanism.
OXCE and OXCE+ are modifications, addons, improvements, or whatever you want to name it, that let you do some other stuff that in "vanilla" OXC is not possible. This is, it add some other mechanisms that are not in the normal game. But, you need a mod that use those mechanisms for these to work. OXCE and OXCE+ are not mods for the game, but for the engine.
One example of this is the possibility to add pilots to the ships. It is not a vainilla feature, and is very hard that you will see it in OpenXcom in the short place (Or ever). But OXCE+ add this possibility. The thing here is the word possibility. If you´re a modder, you can use it in your mod, but if you don´t want, you don´t. It is the same with OXCE and training soldiers.
I hope this help to clarify some misunderstandings.
Im not modder, im just user. So this "You can train your solders basic skills." meaning for me "You can play a game, click th soldier, train it. Or build/research building for training". I dont know how i know need mod. But now understand.
-
Im not modder, im just user. So this "You can train your solders basic skills." meaning for me "You can play a game, click th soldier, train it. Or build/research building for training". I dont know how i know need mod. But now understand.
I suggest you to read this post, where Meridian explain what is OXCE and OXCE+.
https://openxcom.org/forum/index.php/topic,5251.msg78299.html#msg78299
I hope this help.
And enjoy the game.
-
Sorry, I don't see a reason to add " (with mod)." after each line in the changelog.
... because yes, it applies to everything.
Its simple, write the first line "all features need mods" or somthin.. Sorry, not everybody modder.
-
Its simple, write the first line "all features need mods" or somthin.. Sorry, not everybody modder.
Yes, but it was said long ago here that you need to mod in a building to use this feature... But you kept pushing on, so I think we just got confused. Certainly I did.
Let's say it was a misunderstanding.
-
Its simple, write the first line "all features need mods" or somthin.. Sorry, not everybody modder.
Yes, it's really simple ... there is a huge sticky dedicated post at the top explaining this.
I don't expect anyone to be a modder... I doubt that more than 5% of users on this forum are modders.
95% of people here are users, just like you... just look around with your eyes open.
PS: And I explicitly told you, twice, that you need a mod.
-
Yes, it's really simple ... there is a huge sticky dedicated post at the top explaining this.
I don't expect anyone to be a modder... I doubt that more than 5% of users on this forum are modders.
95% of people here are users, just like you... just look around with your eyes open.
PS: And I explicitly told you TWICE, that you need a mod.
First: This thread 1st post nothing explained. (just version number and feature list).
Second. I try to search some info this soldier training. Nothing. So, after write here. But i see its big mistake..
-
You're really stubborn.
First: Here it is: It's sticky, it's dedicated, it's huge and it's a post: https://openxcom.org/forum/index.php/topic,5251.0.html
It's also pretty clearly named, easy to find, you name it... as I said, with eyes opened please.
Second: This forum is here for those who seek help. But I start to feel that you're not looking for help, but try to troll us.
If several clear answers are not enough, there's nothing more I can do.
-
You're really stubborn.
First: Here it is: It's sticky, it's dedicated, it's huge and it's a post: https://openxcom.org/forum/index.php/topic,5251.0.html
It's also pretty clearly named, easy to find, you name it... as I said, with eyes opened please.
Second: This forum is here for those who seek help. But I start to feel that you're not looking for help, but try to troll us.
If several clear answers are not enough, there's nothing more I can do.
omfg.. "relax don't do it"
-
Hey Yankes, what does BattleItem.getOwner return in damageUnit when the damaging_item is the ammunition for a weapon? I'm trying to get and set the stats of the unit firing the weapon, but when I use getOwner and the damaging_item is a standard pistol clip, all of my tags on the unit and its armor return 0, as if the owner is a null pointer.
-
null, right now owner is clear when clip is loaded.
I will add in 3.7 weapon and shooter to damage script.
-
Yankes, are you going to include Ohartenstein's code for vertical buildings any time soon? I am using this feature for my mod, and it's rather crucial, so I need it badly. Seems to work fine... :)
-
I will look at that.
[ps]
ohartenstein23 said that will take few weeks to finish all things he plan in that functionality.
When he will be done I will grab it and release with next version of OXCE.
-
Has anything changed about the terrain damage formulas, over what's written about the OG in UFOpaedia?
The reason I'm asking this is that I've broken terrain damage in some way, and since I'm not exactly sure what the current formulas are, I'm not able to fix things I don't understand.
Specifically, I've changed all Alien(-inspired) explosives to ResistType: 5 (plasma). The end result is, these explosives now do their nominal damage against terrain, resulting in hilarity like blowing the whole top off a Terror Ship with a Blaster Bomb.
Fiddling around with ToTile damage modifiers, I can resolve this on a weapon-by-weapon basis. A bit hackish, but fine. As a corollary, I tentatively conclude that terrain has 50% armor against explosives and 0% against plasma.
Now comes the weird part. I have two plasma projectile weapons, one with 100 power and the other with 120, both using the 2d100 damage model. If UFOPedia is to be believed, neither should be able to pierce outer UFO walls (armor 100), since 120 * 0.75 = 90 < 100. In practice, the 120-damage weapon pretty much obliterates UFO walls at will and the 100-damage version does so with great regularity, maybe 50-60% of the time as a guesstimate.
I've also seen Dioxine claim that projectile damage is 2/3 - 4/3 of nominal damage. That would make it 50% and 75% chance to blow holes in flying saucers, respectively. Given that I did not do any rigorous testing, this is pretty consistent with my experience. So far, so good.
I then changed the ToTile damages to 60%, making these two weapons effectively do 60 and 72 damage against terrain. Dioxine's formula now disallows any UFO wall destruction: 100*0.6*4/3 = 80, 120*0.6*4/3 = 96, both less than 100. UFOpedia obviously does so as well. But in reality I was still blowing away walls, a small trial run gave me 4 penetrations/28 hits and 7 penetrations/29 hits, making the destruction chances of vvery roughly 10% and 25%.
Since my base is Solarius's X-COM Files, an extensive mod in itself, plus a lot of fiddling with parameters I don't apparently understand well enough, it's entirely possible that there's another factor here that I'm not aware of that screws up the calculations. I'd really like to understand what exactly is going on, though. I'm unable to post ruleset snippets right now, but can do so tomorrow if requested.
Oh, and all these plasma weapons have ToArmorPre: 0.1, but as I understand it, walls and other terrain don't really have any armor values that this would apply to.
-
a) In case of explosions, damage done to tiles is not randomized by `RandomType` property. Is only can be by `RandomTile` that is for default false.
b) HE and PLASMA both have `ToTile: 0.5` by default.
c) Armor of tile is not affected by damage type.
d) `ToArmorPre` and `ToArmor` affect only unit armor. And this stat determine DAMAGE to armor not effective of armor (`ArmorEffectiveness` is for that).
This is rough code flow how explosions damage tiles:
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2129
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2132
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2243
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2296
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2316
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2340
-
Damn, almost ninja'd. ;D
a) This is fine, I understand and can work with it. My problem is with non-explosive plasma weapons which are too powerful for some reason, either because I'm misunderstanding the formulas or another mistake like the one in b). What is the non-explosive damage algorithm? It's obviously randomized, but beyond that I can't really tell.
b) Perhaps I left in ToTile: 1.0 by accident. That would do it. By the way, which 0.5 is inherited for DamageType: 3 and DamageAlter: ResistType: 5. I'd guess the HE one?
c) So tile 'armor resistance' is effectively made up of the default ToTile values of various damage types? Good to know.
d) Yeah, that's what I thought. I just wanted to cover all bases.
I have another lower-priority problem as well. There's something wrong with my grenades, and I can't for the life of me figure out what it is. Or rather, I think I know what the problem is, but I have no idea how to go on about solving it. As far as I can tell, sometimes when an Alien tries to use a grenade, it just CTDs the game. This idea is supported by the crash going away when I delete all the grenades from the save. There may be several changes responsible for it, because I've modified quite a number of related aspects (really low strengths to limit unrealistic throwing, changed priming and throwing costs of grenades, etc.) But there are no sneaky features inherent to the grenades, like TU damage going into negatives that I've also caught causing CTDs.
Does it look like some known problem or is there a way to trace the problem? Straight crashes usually don't give much log info.
-
a) Biggest difference is that it use random range of damage (from `RandomType`) and hit only one element of tile.
b) `damageAlter` is overwritten when you set `damageType`, in your case it will have `damageAlter: ToTile: 0.5`, `ResistType` will be only use when unit is hit.
To find cause of crash best way is prove save and ruleset need to run it. Logs are not many times useful because only information is "its crashed".
-
a) Biggest difference is that it use random range of damage (from `RandomType`) and hit only one element of tile.
Oh, I see. That’s where the Irwin-Hall distribution screws with my usual intuition. Thanks.
To find cause of crash best way is prove save and ruleset need to run it. Logs are not many times useful because only information is "its crashed".
Try the outdated mod from here (https://openxcom.org/forum/index.php/topic,5048.0.html) against the attached savegame. I’m 90% sure the save’s still compatible. If it’s not, I’ll make a special save for the older version.
-
Oh, it's the most egotic person on the planet again :)
If the crash happens when alien is about to throw a grenade, the cause is likely broken route map (nodes at z-1 or somesuch). Use OXCE+, it generates a message if something is wrong with the map. If there is, you need to repair RMPs (nodes exceeding map limits are what you're looking for).
-
Happens on plain vanilla maps, too, so it's unlikely. Otherwise Solarius would be hip deep in crash reports right now. :)
But I'll test anyway, it just in case... how do I get advanced logging, again? I recall there being command line parameters in OXCE, but a cursory search turns up nothing. And if you mean just plain openxcom.log, that one's got nothing, either.
It's a useful tip, though, so thanks. Off-topic, and I admit I've not looked for it, but has there ever been some sort of 'modding wisdom' thread where veteran modders share nontrivial tips they've learned over the years? To give you an idea what I mean, tips #1 and #2 would likely be 'if it crashes at midnight, it's probably faulty research' and 'getOneFree really only works on live Aliens... sometimes’.
-
Try the outdated mod from here (https://openxcom.org/forum/index.php/topic,5048.0.html) against the attached savegame.
The linked mod doesn't work for me, see attached.
EDIT: after fixing the bugs, I can confirm that the crash is caused by a node outside of map (coordinates: [6,11,-1]). If you upgrade to the latest OXCE/OXCE+, it will not crash anymore (any new battle that is, the one from the save is doomed already) and give you a nice warning in the log file.
-
It indeed was the desert terrain that was bugged. Solarius has already fixed this, inconveniently at exactly the same time as he updated to the new 3.5+ format. Note to self: test features on at least two different terrains before assuming the mistake is in the ruleset.
Sorry for needlessly wasting your time with an already resolved issue. I really do need to upgrade before asking for help again.
-
Why was default grenade unpriming removed? I get that it is covered by 'custom unprime', but removing option useful to 99% so they need to declare every fucking thing like that 1% who needs special unpriming? Why?
-
Why was default grenade unpriming removed? I get that it is covered by 'custom unprime', but removing option useful to 99% so they need to declare every fucking thing like that 1% who needs special unpriming? Why?
Primary because I made overhaul of handling of unpriming, now is same action like priming. Old code do not fit new one and I decide to remove it (old one was more a hack than proper feature). Probably I did it probably too hastily and I didn't ask how often it was used. I think that I can partially bring back it in next release.
Only difference will be that will have same TU cost as priming not half by default.
-
I tried to mod in a grenade that explodes instantly and if not thrown in the same turn should explode in hand:
fuseType: -2
isExplodingInHands: true
But the grenade does not explode in hand.
Is the "isExplodingInHands" tag only working for other fuseTypes?
-
Yes, `fuseType: -2` explode only when throw, image this as bottle of nitroglycerine, you can put it on ground and it will not explode but if throw is go boom.
If you want "real" grenade use fixed time: `fuseType: 0`it will explode at end of turn even if you keep in hand or throw (of corse if `isExplodingInHands: true`).
-
Yes, `fuseType: -2` explode only when throw, image this as bottle of nitroglycerine, you can put it on ground and it will not explode but if throw is go boom.
If you want "real" grenade use fixed time: `fuseType: 0`it will explode at end of turn even if you keep in hand or throw (of corse if `isExplodingInHands: true`).
If I understand correctly `isExplodingInHands: true` is doing currently nothing for `fuseType: -2`.
Would it be possible to change it so, that the grenade explodes at the turn it was primed, if `isExplodingInHands: true`?
The thought behind this is that I want to prevent pre-priming AND grenade-relay tactics with certain grenades.
-
If I understand correctly `isExplodingInHands: true` is doing currently nothing for `fuseType: -2`.
Would it be possible to change it so, that the grenade explodes at the turn it was primed, if `isExplodingInHands: true`?
The thought behind this is that I want to prevent pre-priming AND grenade-relay tactics with certain grenades.
Yes, its do nothing but this is consistent with behavior of this grenade on ground (`isExplodingInHands` == "inventory work same as ground").
I think proper solution for this is add different fuse type that will explode on impact and at end of turn.
-
I took a break from oxc/piratez and now that im back I noticed some changes. Piratez looks Alot better by the way.
Question I got is I saw a screenshot of a tech tree viewer built Into the game. But there arent any buttons or hotkeys listed for it - how to access?
Also even though its a cheat I cant find the option that turns off destroying items after they're researched. Has that option gone away and only applies to corpses now? I never played the recent xcom games and I prefer the vanilla rule for it (after you take it apart, they put it back together again)
-
Question I got is I saw a screenshot of a tech tree viewer built Into the game. But there arent any buttons or hotkeys listed for it - how to access?
Either middle-click on any research or manufacturing topic.
Or press Q in geoscape.
Also even though its a cheat I cant find the option that turns off destroying items after they're researched. Has that option gone away and only applies to corpses now? I never played the recent xcom games and I prefer the vanilla rule for it (after you take it apart, they put it back together again)
This option has been removed (also in vanilla).
It has been replaced by ruleset settings... and it doesn't apply only to corpses, but to anything the modder decides.
-
This option has been removed (also in vanilla).
It has been replaced by ruleset settings... and it doesn't apply only to corpses, but to anything the modder decides.
Thanks and Thanks.
Yeah for the latter I guess that makes more sense anyway.
-
I don't understand meleeAlter. I do (hopefully).
- type: MYALIEN_WEAPON # an alien terrorist
[...]
meleeSound: 136
clipSize: -1
power: 10
damageAlter:
RandomType: 2
IgnoreDirection: true
ArmorEffectiveness: 0.1
strengthApplied: false
damageType: 7
accuracyMelee: 100
tuMelee: 15
battleType: 3
fixedWeapon: true
invWidth: 2
invHeight: 3
recover: false
flatRate: true
..meleeAlter is not used for the kind of weapon above, right?
-
"meleeAlter" is used for guns melee attacks, melee weapons do not need this and use directly item power and alter damage.
-
getting a weird crash with OXCE+3.6 running X-Piratez
Its not so much piratez itself but check this out - rather than modifying the piratez mod I decided to make another one to patch over it.
The big trouble seems to come down to fireSound and hitSound. Because im wanting to change sound effects and alter items to use different sound effects.
Sometimes for seemingly no reason OXC will crash during a mission and say it cant find the sound but the sound id is really weird like 8000ish (for example if the item sound was 55 for the smg guns it will say 8055).
Ironically for the same sound effects it was NOT doing this before and there's nothing I changed to cause it. Other things which were behaving just fine are now messing up.
I even removed the extraSounds section from my mod and - and now its STILL crashing. I looked in my savegame and there's no mention anywhere in there about sounds.
-----
some other things - I noticed if I place resources in the same folder layout as (another mod) it will load those resources from mine instead thus patching over the ones from the other mod
which it worked successfully, but then I started getting errors
-----
The reason I started Doing This was because it was working just fine to have custom sounds defined in a (different folder path) with my own file names for it. Then I started getting this error out of the blue when the medical people went to shoot a Harpoon at me (the harpoon sound was crashing the game).
But the Harpoon was working just fine before that, and I didnt change anything about it to make it screw up.
Also I believe the Hunting Bow in piratez uses the same swoosh sound as the harpoon anyway and I was making shots with the hunting bow without a crash.
>inb4 it would crash while making a sound effect for one weapon, but not crash making the same sound effect for a different weapon
And this had nothing to do with the impact sound for the harpoon - this was the firing sound (crash as soon as the dude used it)
Edit - this is the line from the .log file
there are NO as in I repeat NONE of the sound effects designated in the 8000 range, this error was caused by a gun calling for sound effect 74 (the sniper hit sound)
[26-02-2017_22-01-37] [FATAL] A fatal error has occurred: Sound 8074 in BATTLE.CAT not found
[26-02-2017_22-01-41] [FATAL] OpenXcom has crashed: Sound 8074 in BATTLE.CAT not found
-
This is all normal.
You cannot use other mod's resources in your mod by reference.
E.g. for sounds, you can use numbers from 0 to 54 (vanilla)... which map to the same indices in all mods. You can also override them using these indices... and this will override them globally. If multiple mods override them, the last one loaded will win.
If you use custom sounds (55+) they will map into a different index for EACH mod.
For example 1055 for piratez and 2055 for your mod and maybe 8055 for some other mod... based on the mod's size and order of loading.
In other words, index 55 is only virtual and always maps to something else.
That's why when you wanted to use piratez's sound 55 (which is actually 1055), you have actually used sound 8055... which didn't exist, because you didn't define it in your mod (as 55).
Little confusing, I know.
PS: same applies to extraSprites
-
you have actually used sound 8055... which didn't exist, because you didn't define it in your mod (as 55). Little confusing, I know.
Okay I get it now. So any instance of a fireSound or hitSound that im selecting that isnt vanilla might as well just be a new sound that I provide. Otherwise I might as well not touch the sound it uses.
Thats not bad actually. I think this could work.
Im still overriding 22 (the vanilla bullet hit sound) but the rest I can just create new slot identifications for. It was just me being a little lazy.
Also - you said it applies to extrasprites, im not intending on changing sprite identifications but I do intend on replacing graphics. Having the graphic placed in the correct folder path and name wouldn't cause problems would it?
-
In order to use the enhanced lighting system, I had to add
lighting:
enhanced: 7
to the global variables.
However, the documentation suggests that 7 should be default. Instead, 2 is default.
Is it an error in the code, or the documentation?
-
In order to use the enhanced lighting system, I had to add
lighting:
enhanced: 7
to the global variables.
However, the documentation suggests that 7 should be default. Instead, 2 is default.
Is it an error in the code, or the documentation?
error in code, I made couple of iteration of how encode multiple modes of lighting and I forget to set correct value when I made final version.
All times I used override value for tests and I miss default case.
-
craftWeapons:
- type: STR_CRAFTWEAPON_TYPE #default config ...
weaponType: 1 #default value 0.
stats: #added to craft's stats.
[...]
radarRange: 0 #additive bonus to craft stats.
sightRange: 0 #additive bonus to craft stats.
What is sightRange? Is it used for spotting alien bases while radarRange is for UFOs?
What is the default-vanilla value a craft has?
Is it expressed using the same unit of measure as radarRange?
Sorry for the manyquestions. :-[
-
default is 1696 (for ufo is 268), and yes this is same unit as radar range.
-
is it used just for spotting bases?
-
is it used just for spotting bases?
Yest, both for aliens and xcom.
-
The following is making the game crash:
craftWeapons:
- type: STR_DIMENSIONAL_SCAN
sprite: 110
weaponType: 1 # irrelevant for the crash
stats:
radarRange: 1304
sightRange: 1304
I'm using OXCE+ 3.6
The sprite is not the culprit (is is used successfully in another craft weapon).
-
The following is making the game crash
The "launcher" attribute on craft weapons is mandatory.
-
thanks!
-
New versions is up!
3.7:
New params with shooting weapon and shooter to damage and hit script.
Merge chagnes from master.
Random functions in script.
Vertical map generation support.
As mod portal is down please use:
windows: https://www.mediafire.com/file/5k5emopkquq22ut/OpenXcomEx37.zip
linux ubuntu: https://www.mediafire.com/file/0e1mo7ho0vjuxzh/OpenXcomEx37Elf.zip
-
(https://i2.kym-cdn.com/photos/images/newsfeed/000/997/763/e28.jpg)
Were there any changes to the vanilla files that modders should be aware of?
-
primary bug fixes.
-
BattlescapeGenerator crashes before any mission, in visual studio in Debug mode, in 3.7.
(Doesn't crash in Release mode.)
-
BattlescapeGenerator crashes before any mission, in visual studio in Debug mode, in 3.7.
(Doesn't crash in Release mode.)
I will look at that.
-
This commit fix this bug: https://github.com/Yankes/OpenXcom/commit/f807f5213d4c5add50bea17025d9d0b7a61bc8df
-
This commit fix this bug: https://github.com/Yankes/OpenXcom/commit/f807f5213d4c5add50bea17025d9d0b7a61bc8df
Thx, that helped.
Not getting the crash anymore.
-
I made bug fix version 3.7a: https://github.com/Yankes/OpenXcom/commit/31a148714d23eee5699a26bd81114bbb40bbbc9c
btw VS in debug mode deliberate crash program in that case, in 99% of times this bug overwrite unused memory at end of vector that for perspective of OS is valid behavior. C++ do not mandate any checkings in that case and describe it as Undefined behavior, this mean sometimes work fine and other times wipe your drive (second things is real but need some helping hands of some "nice" people from internet :> ).
-
hi Yankes, hi Meridian,
does 3.7a fix the "one bullet causes an explosion"-bug?
https://openxcom.org/forum/index.php/topic,5047.msg80327.html#msg80327
https://openxcom.org/forum/index.php/topic,5359.0.html
-
Yes, that was whole point of releasing it.
-
Thanks for all the work! It's crucial to our mission.
-
@Yankes: could you please look at this post: https:https://openxcom.org/forum/index.php/topic,5296.msg80622.html#msg80622
I found a fix, but don't know if that's all or maybe something else could be missing...
-
This was merge error, you change is correct.
-
Yes, that was whole point of releasing it.
great! thank you!
-
Just discovered RandomType: 6 (two dice @ 50%)
Been wanting that for a really long time. Its how I thought TFTD did their damage calc before I found out otherwise. Kudos and thank you, its more like roleplaying damage now.
-
Can we expect (hope) two ammo weapons in the next version OXCE+?
-
Just discovered RandomType: 6 (two dice @ 50%)
Been wanting that for a really long time. Its how I thought TFTD did their damage calc before I found out otherwise. Kudos and thank you, its more like roleplaying damage now.
You're welcome.
Can we expect (hope) two ammo weapons in the next version OXCE+?
Assuming you're talking about two-dice roll, this was implement in OXCE+ originally, on 21st February 2016 (more than a year ago).
It was merged to OXCE later.
I recommend reading OXCE+ changelog :) You may find a lot more things you like.
-
I'm currently playing area 51 v0.93 using meridian's exe of 12th March and wondering about the following. I increased the statcap for strength to 80 in STANDARD/xcom1/soldiers.rul but I'm also using the oxce mod "training room"(attached), does this mod overide the statcap as one of my troops has a strength now of 91?
-
I'm also using the oxce mod "training room"(attached), does this mod overide the statcap as one of my troops has a strength now of 91?
No, it doesn't.
But probably one of the other 40 mods you have enabled does.
Seriously man, play as intended.
No fun, if you bastardize Area 51 with 40 other mods.
I increased the statcap for strength to 80 in STANDARD/xcom1/soldiers.rul
This can/will be overwritten by any mod (you have 40!), which changes the same value.
-
My mistake as it seems that it's the mod veteran soldiers is what's causing it with a strength statcap of 100, it's hard to mind all the mods you have on sometimes when you use a lot. Though the vast majority of them are relatively small or cosmetic and from what I can tell don't conflict with area 51.
-
I started combining mods to control them better... Et voila, FMP. :D
-
Can we expect (hope) two ammo weapons in the next version OXCE+?
This is still in plans for next version.
-
Hey Yankes, can I request some new script features? Would it be possible to let scripts modify the amount of ammo remaining in a clip or the amount of charges left in a medkit item? Right now we can read the amount remaining, but that limits some of the script use if we can't modify those values. Also, how difficult would it be to make script hooks for picking up and dropping items? Having those would simplify a number of otherwise complicated and convoluted scripts.
-
Speaking of, would it be possible for medikits to apply healing, painkiller and stun removal at once? I mean rum bottles in Piratez; it's weird that 1/3 of it is healing and so on. I mean, it's a bottle of rum!
-
Hey Yankes, can I request some new script features? Would it be possible to let scripts modify the amount of ammo remaining in a clip or the amount of charges left in a medkit item? Right now we can read the amount remaining, but that limits some of the script use if we can't modify those values. Also, how difficult would it be to make script hooks for picking up and dropping items? Having those would simplify a number of otherwise complicated and convoluted scripts.
All this things are on my TODO list, right now I can add updating ammo & medkit on turn change and when unit get hit (this one is not much useful in that case).
Speaking of, would it be possible for medikits to apply healing, painkiller and stun removal at once? I mean rum bottles in Piratez; it's weird that 1/3 of it is healing and so on. I mean, it's a bottle of rum!
You mean in case when UI is not available? If yes then I could add new case that will apply all at once.
-
All this things are on my TODO list, right now I can add updating ammo & medkit on turn change and when unit get hit (this one is not much useful in that case).
hitUnit is the exact case in which I'm looking to use it actually - Dioxine and I had been discussing how to make personal energy shields with a proper indicator of remaining shield HP to the player, and one idea that cropped up is using the ammunition count in a clip as the HP value.
-
hitUnit is the exact case in which I'm looking to use it actually - Dioxine and I had been discussing how to make personal energy shields with a proper indicator of remaining shield HP to the player, and one idea that cropped up is using the ammunition count in a clip as the HP value.
consider its done.
-
Speaking of, would it be possible for medikits to apply healing, painkiller and stun removal at once?
Speaking of which, is it possible to make an item or a medikit give you straight Health just like stimpacks in fallout?
I know its kinda evil, but I wanna make an item that lets you heal damage completely. Even if you dont have any fatal wounds, etc like when you get burned. This just forks you over +5 health plain and simple (it can be balanced, give you lots of stun instead, and not self-usable).
> in this case its listed as something you pour on the wounded area and it stabilizes the damaged area, while healing it up fully over time on the way back to base.
also gives me ideas for resident evil style herb mixes
-
Yes, it's possible; see for example Mushroom Beer in Piratez.
-
Also is it possible to set ShotgunPellets: 1 ?
Like make it shoot a single shot but do the instant hit thing so that the camera doesnt jerk back and forth trying to follow fast shots?
I suppose it would be great if we could make a weapon forceably turn off shot-following for the camera, and it would make sense too for weapons that are sneaky and you couldnt necessarily pinpoint where they come from - and from using machineguns where you cant honestly keep track of where the shots are going.
-
Yes, it is possible to set shotgunPellets: 1, it should do just the instant hit without following the rest of the pellet-spread code.
-
Hi Yankes,
can you please help with the following report: https://openxcom.org/forum/index.php/topic,5403.msg81586.html#msg81586
M.
-
Small update on current status, right now I'm near finishing multiple ammo weapons (I will probably be ready before or after Easter).
Primary goal is that each attack can have separate ammo types loaded independently e.g. instead of auto shot you will have grenade launcher shoot.
Secondary goal is have attachments to weapons like laser sight or scope, this will be handle by scripts.
Another change piggyback on this feature is multishot for every attack (you could have "short burst" and "long burst" attacks).
This will be only big change in that release, adding another one will postpone release even further.
-
Long tried to understand where to write ...
You can do so that the alien bases can appear only after the landing of the ship, which should build it, and not at the moment of its appearance? I.e; If the ship is destroyed - the base is not built, the infiltration is disrupted and the mission of the aliens is failed.
In the original UFO it was just like that. And here we see, extremely unsuccessful, the idea of the TFTD. The Inability to prevent build bases and infiltrations is annoying, up to editing the save files.
-
The Inability to prevent build bases and infiltrations is annoying, up to editing the save files.
Just to voice a different opinion, I think these mechanics are necessary, well-balanced and interesting... my heart and soul hurt every time I see people suggesting crippling already crippled aliens even more.
Regardless, the suggested features can be implemented, shouldn't even be too hard.
Just don't ask me to do it... I don't have the heart to do this to the poor aliens.
-
Just to voice a different opinion, I think these mechanics are necessary, well-balanced and interesting... my heart and soul hurt every time I see people suggesting crippling already crippled aliens even more.
Regardless, the suggested features can be implemented, shouldn't even be too hard.
Just don't ask me to do it... I don't have the heart to do this to the poor aliens.
if it would be per mission toggle and balanced by modder (put "hard" part in some other place) it could be useful.
I think good way would be percent property that represent chance of canceling mission if ufo is shoot down. It would affect all missions (but different default values for each type). You could add that at some point all missions have 0 chance to stop.
-
I think good way would be percent property that represent chance of canceling mission... snip
That's actually exactly what I already did for retaliation and infiltration.
There is a configurable percentage to stop infiltration mission (except the first pact).
And there is a configurable percentage to stop alien retaliation (except the first attack).
For alien base, it was not necessary, because it ends after first base anyway.
But cancelling a mission before it can even do anything??
As a side note, if you have tech to shoot down a Battleship... you certainly have tech to end the game... so just end the game. How many months do you have to play until they actually make a pact with all nations? Or even a half of them? A lot longer than a game should take...
Just my opinion.
-
Then I do not see any more space to improve/tweak in that.
-
As a side note, if you have tech to shoot down a Battleship... you certainly have tech to end the game... so just end the game. How many months do you have to play until they actually make a pact with all nations? Or even a half of them? A lot longer than a game should take...
In its modification, I implemented 3 technological levels. Initial, intermediate and final. On the intermediate there is more than to knock down the Dreadnoughts, but the opportunity to fly into space will appear only at the final level.
But cancelling a mission before it can even do anything??
This can be achieved by increasing the power of alien ships. The same modes with power shields for large ships, that low-tech weapons, just do not make it pierce.
-
I'm not sure what exactly are you talking about.
In the original post you're complaining about UFO and TFTD.
Now you're complaining about something else? Your own mod I presume?
If so, there are millions of ways how to fix this... the easiest is just to replace for example Infiltration mission with a mission that doesn't infiltrate... e.g. some sort of alien raid or alien patrol, or whatever you want to call it. Or you can just decrease the probability of Infiltration mission spawning to 25% of current setting and fill the remaining 75% with a similar mission without infiltration effect. You have full freedom defining any missions as you want, no need to ask for changes in existing missions (which were carefully designed the way they are).
-
If so, there are millions of ways how to fix this... the easiest is just to replace for example Infiltration mission with a mission that doesn't infiltrate... e.g. some sort of alien raid or alien patrol, or whatever you want to call it. Or you can just decrease the probability of Infiltration mission spawning to 25% of current setting and fill the remaining 75% with a similar mission without infiltration effect. You have full freedom defining any missions as you want, no need to ask for changes in existing missions (which were carefully designed the way they are).
Simpler - does not mean better. I already replaced the infiltration for the construction of bases... But still it's not right. Infiltration should be, but the player should be able to prevent it, like, however, and the construction of bases.
-
Simpler - does not mean better.
Exactly!
Your solution is too simple... if I give player a way to consistently prevent infiltration, he will just prevent infiltration every time. I might just as well remove it from the game completely.
Btw. if you're not happy with RNG or with the mission's periodicity or frequency, you can use mission script to remove all randomness and have infiltration on fixed date or dates you wish (e.g. only twice early in the game on March 23rd and June 6th, and then no more).
-
Exactly!
Your solution is too simple... if I give player a way to consistently prevent infiltration, he will just prevent infiltration every time. I might just as well remove it from the game completely.
You do not understand the idea. And it is that at the beginning of the game the player simply has nothing to fight with large ships. There are no ships capable of catching up with the enemy, no weapons to destroy it. And with the development of technology, it becomes possible to prevent the most aggressive alien missions. That's why new ships are needed. Otherwise, what is the point in the speed of interception, if in general, to prevent a mission impossible?
Otherwise, there is no point in developing them. You can play with one base and fly on interceptors with plasma cannons until the end of the game, since Is wasted in the of Lightning and Fire Storms inexpedient, and with the invention of the Avenger, build it in a single copy and immediately fly to Cydonia.
P.S. And in general - this is nonsense. Their ship was shot down, but they came on foot and built a base or organized infiltration. Why the hell are they ships if they walk at such a speed?
-
Small update on current status, right now I'm near finishing multiple ammo weapons (I will probably be ready before or after Easter).
Primary goal is that each attack can have separate ammo types loaded independently e.g. instead of auto shot you will have grenade launcher shoot.
Secondary goal is have attachments to weapons like laser sight or scope, this will be handle by scripts.
Another change piggyback on this feature is multishot for every attack (you could have "short burst" and "long burst" attacks).
This will be only big change in that release, adding another one will postpone release even further.
This is exciting. I'm looking forward to seeing all theses features.
-
This is exciting. I'm looking forward to seeing all theses features.
DIdn't know all these things are possible in OXC. Hype!!
-
Hi Yankes,
in this post: https://openxcom.org/forum/index.php/topic,4702.msg82679.html#msg82679
we have noticed there is a difference between OXC and OXCE in treating transparency (and possibly other effects?).
Basically OXC can also render transparency from a color index different than 0 (zero)... or at least it looks like it.
I looked in the code for a few minutes, but I couldn't find the difference.
Do you know what exactly it is... so that I don't have to debug to find out? :)
M.
PS: the attached picture shows OXCE with non-transparent background of the Multi-Launcher... whereas the same in OXC would be transparent
-
Me again,
there was another bug noticed here: https://openxcom.org/forum/index.php/topic,4187.msg82759.html#msg82759
Happens in OXCE and OXCE+, does not happen in OXC nightly.
Steps to reproduce in OXCE:
1. turn save scumming off
2. load attached vanilla save (nicola zanon.sav)
3. end turn
4. soldier Nicola Zanon will panic and drop items on the ground
5. save
6. load save from step 5
7. the dropped items on the ground have disappeared
M.
-
I will look on this
-
Ok I find bug, problem was that `moveToOwner` was call after `addItem` in `dropItem`, culprit was `_tile = nullptr`.
Simple fix is move code around to have:
_save->getTile(p)->addItem(item, getMod()->getInventory("STR_GROUND", true)); //move this line there
getTileEngine()->applyGravity(_save->getTile(p));
in `dropItem`.
Line that cleared tile I would leave alone because I add it to fix bugs in other places (equip phase do not clear properly tiles).
-
Ok I find bug, problem was that `moveToOwner` was call after `addItem` in `dropItem`, culprit was `_tile = nullptr`.
Line that cleared tile I would leave alone because I add it to fix bugs in other places (equip phase do not clear properly tiles).
Hmm, feels hacky.
But I guess it's not the end of the world...
-
Overall item movement is hacky because in each place is done differently. Best would be one function used in every place but this is hard because in some cases items vectors that would be change by this function are iterate over in this function caller parent.
btw during my fight with multi ammo weapons I find one line that can be incorrect and was added by you:
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Battlescape/BattlescapeGenerator.cpp#L705
As I look on other places I saw that value returned is different:
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Basescape/CraftEquipmentState.cpp#L620
This is correct?
-
Fast poll, what key (Shit, Ctrl, Alt) use to force "hot swap" of weapon clip?
"hot swap" mean that you have already loaded weapon and you try push new clip into it. With this new functionality weapon will be first unloaded and then loaded with new clip. This will be important when you will have multiple ammo types in one weapon and need reload only one type.
Another similar question is for unload button, what key use to reverse unload order of ammo clips?
-
Perhaps you could hot swap a clip by trying to load it into a loaded weapon a second time. Rather than have yet another obscure hotkey-based method to invoke new behavior, I'd rather get a properly descriptive message the first time ("Weapon is already loaded, click again to force load") and then get what I want the second time without jumping through some kind of hoop.
For unloading ideally I'd like to be presented with some sort of choice when dropping the weapon on the unload icon, buuuut I suspect that could be more trouble than it's worth.
-
btw during my fight with multi ammo weapons I find one line that can be incorrect and was added by you:
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Battlescape/BattlescapeGenerator.cpp#L705
As I look on other places I saw that value returned is different:
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Basescape/CraftEquipmentState.cpp#L620
This is correct?
It was correct at the time when I wrote it.
It is not correct anymore after TFTD changes.
Here's a fix: https://github.com/MeridianOXC/OpenXcom/commit/4fe8bb03d74df0e5cfd8f0a4c5d96337f88b20a3
Btw. what is the idea behind multiple ammo weapons?
I don't quite get it... can you explain what does it actually mean in more detail and how will it actually work? And why do we need it? :)
-
Grenade launcher for M16 :> With multiple ammo types you can add special attack to weapons, another easy change is not treat new slots as ammo but as accessories like scope or bayonet.
Another side effect is that all attacks will work more uniformly, this mean you will have short burst and long burst.
Each attack type will define with ammo slot (right now limit is 4 slots, each with different compatible ammo list) it is using.
-
Hi Meridian, thanks for OCXE+, I love the new features.
I'm using your exe for new_civilian's TFTD My_Mod (not related to piratez, sorry) where you can hire sectoid and enforcer (robotic) soldiers.
I'm also using Solarius "celebrate_diversity" flags mod.
I wanted to assign an unique flags to these kind of soldiers, but only the first flag (flag0, USA) is used. It's possible to change this behaviour?
To be more clear:
soldiers:
- type: STR_SOLDIER
...
soldierNames:
- 00_SoldierName/ # 40 files, flags 0..39 are used, OK
- type: STR_SOLDIER_VETERAN
...
soldierNames:
- 00_SoldierName/ # also flags 0..39 are used, OK
- type: STR_SOLDIER_ROBOTIC
...
soldierNames:
- 01_RoboName/ # only 1 file, flag 0 (USA) is used, I want flag 40
- type: STR_SOLDIER_SECTOID
...
soldierNames:
- 02_SectoidName/ # only 1 file, flag 0 (USA) is used, I want flag 41
I'm not a modder, just a player, so feel free to ignore my post, I will not get offended.
-
I wanted to assign an unique flags to these kind of soldiers, but only the first flag (flag0, USA) is used. It's possible to change this behaviour?
Yes, no problem...it's implemented (see below)... will be available in the next version.
soldiers:
- type: STR_SOLDIER_ROBOTIC
...
flagOffset: 40
soldierNames:
- 01_RoboName/ # only 1 file, flag 0 (USA) is used, I want flag 40
- type: STR_SOLDIER_SECTOID
...
flagOffset: 41
soldierNames:
- 02_SectoidName/ # only 1 file, flag 0 (USA) is used, I want flag 41
-
Hi Yankes,
could you please look at this crash: https://openxcom.org/forum/index.php/topic,5047.msg83553.html#msg83553
Thx,
M.
-
I have another crash/freeze for you: https://openxcom.org/forum/index.php/topic,4058.msg83575.html#msg83575
I found the difference in: https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/UnitWalkBState.cpp#L331
...where _parent->checkReservedTU() returns different values in vanilla and OXCE
Going deeper in: https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/BattlescapeGame.cpp#L1174
...vanilla returns true, because "return tu <= bu->getTimeUnits();" is 0 <=72
...however OXCE returns false, because "return cost.haveTU();" always returns false when Time == 0
One possible fix is to change it to "return tu <= 0 || cost.haveTU();" ... in which case the freeze doesn't happen anymore and AI works as in vanilla.
... but maybe the whole haveTU() method is not correct?
I mean
bool BattleActionCost::haveTU(std::string *message)
{
if (Time <= 0)
{
//no action, no message
return false;
}
...
This condition looks very weird... surely when Time == 0, you have enough TUs to perform the action (since it doesn't cost anything) and the method should return true, not false.
However just changing the condition would mean other conditions below it (for energy, etc.) won't be checked... so maybe better is to remove this first condition completely?
I don't know what the purpose of this condition is, so I would prefer if you had a look at it... and made a proper fix... so that I don't make it even worse than it is now.
-
0 mean there is not action at all, if weapon do not have TU is impossible to use it in vanilla:
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/ActionMenuState.cpp#L292
Because I unify nearly all tu spending in some cases inconsistent behavior for base game surfaced causing bugs in OXCE.
In case of reserved tu I think your suggestion of fix is correct, because if `tu <= 0` then there is no need for checking for cost because there is no action at all to reserve for.
btw other bug with light is near fixing, I only need double check that everything work as excepted.
-
Yankes, when is the next version coming up? Not trying to put pressure on you or anything, but the truth is, we need it. :)
-
some writer block/lack of time/lack of focus caused that final touch (and testing) get delayed. Main reason was that I was forced to made changes in places I do not wanted to changed. I will try made push in this weekend and release finally new version.
-
(https://s-media-cache-ak0.pinimg.com/originals/39/79/c6/3979c65a9b764c174a9ea61e01b95e1c.jpg)Fight, Yankes!(https://s-media-cache-ak0.pinimg.com/originals/39/79/c6/3979c65a9b764c174a9ea61e01b95e1c.jpg)
-
New version 3.8 is finally ready, primary change is multi ammo weapons, each weapon can have secondary ammo types (like grenade launcher).
With this some small changes like: change name of attack, auto shot of not auto shots, access attack action type in damage script.
-
Merge newest vanilla please? It has some stuff I wanna use, plus a good bunch of fixes.
-
I will merge with next version, this time I will choose simpler thing to implementing :>
-
0 mean there is not action at all, if weapon do not have TU is impossible to use it in vanilla:
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/ActionMenuState.cpp#L292
Because I unify nearly all tu spending in some cases inconsistent behavior for base game surfaced causing bugs in OXCE.
In case of reserved tu I think your suggestion of fix is correct, because if `tu <= 0` then there is no need for checking for cost because there is no action at all to reserve for.
btw other bug with light is near fixing, I only need double check that everything work as excepted.
Is this solved in 3.8?
-
New version 3.8 is finally ready, primary change is multi ammo weapons, each weapon can have secondary ammo types (like grenade launcher).
With this some small changes like: change name of attack, auto shot of not auto shots, access attack action type in damage script.
The primary change seems a bit underwhelming, unless I'm missing something. If we want to have combi-weapons, would need separate stat sets for each weapon (multiple weapons per item); ammo alone makes this a marginally useful gimmick as you can't change TU costs, accuracies, arcing/flat shot etc., so eg. a rifle with a grenade launcher is still unfeasible (as far as I understand these changes)
Secondary changes, very interesting.
-
Is this solved in 3.8?
this with light? yes.
The primary change seems a bit underwhelming, unless I'm missing something. If we want to have combi-weapons, would need separate stat sets for each weapon (multiple weapons per item); ammo alone makes this a marginally useful gimmick as you can't change TU costs, accuracies, arcing/flat shot etc., so eg. a rifle with a grenade launcher is still unfeasible (as far as I understand these changes)
Secondary changes, very interesting.
There is probably small misunderstanding how it will work.
First you can define additional "compatibleAmmo" and separate "tuLoad" and "tuUnload" for each new slot.
With this now weapon can have multiple different ammo items loaded at once, aside of that weapon work exactly same as normally.
After that you can choose in each attack type with ammo slot to use for that attack (or attack can work without any ammo and use "weapon" as "bullet" like in lasers).
This mean TU and accuracy is already configurable for each attack type. arcing/flat is not but I could add this as bug fix.
Any other properties you would like have configurable per attack type?
-
this with light? yes.
No, the endless loop during alien turn: https://openxcom.org/forum/index.php/topic,2915.msg83582.html#msg83582
-
ups.. I thought you will do it, ok I will release bug fix version with this fix.
-
First you can define additional "compatibleAmmo" and separate "tuLoad" and "tuUnload" for each new slot.
With this now weapon can have multiple different ammo items loaded at once, aside of that weapon work exactly same as normally.
After that you can choose in each attack type with ammo slot to use for that attack (or attack can work without any ammo and use "weapon" as "bullet" like in lasers).
This mean TU and accuracy is already configurable for each attack type. arcing/flat is not but I could add this as bug fix.
Any other properties you would like have configurable per attack type?
OK now I understand this better.
So what properties we need to make this fully functional?
1. arcing shot
2. bullet sprite
3. fire sound
4. snap/aimed/auto ranges
That is all I can think of for now.
Another question, and a rather crucial one, how are the additional ammo types handled by the GUI?
-
in battle screen you have additional numbers per ammo slot (visible only when used).
for inventory is it bit lacking, I did not made yet how best to display it, one solution is add loop in ammo popup that will show all loaded ammo in sequence (1s -> first slot showed, 3s -> second slot showed, 5s -> third, etc.)
another is add postfix to display name of weapon based on loaded ammo, something like that: "pistol (with explosive)".
other solution could be adding ammo count to each weapon in inventory (not in stack on ground) similar to battle scape.
-
I don't know how to do this. One thing that is obvious is problem with Ufopedia. How can one get it to display these extra ammo, with extra attack types? I think (and I said so before all this mess) that it would be better to make this separate weapons with separate ammo, treated as a single object, rather than multiple 'ammo' types...
-
Bug report for 3.8... inventory copying doesn't work, see screenshot before/after copying.
Tested on e4c8220, no mods.
-
I don't know how to do this. One thing that is obvious is problem with Ufopedia. How can one get it to display these extra ammo, with extra attack types? I think (and I said so before all this mess) that it would be better to make this separate weapons with separate ammo, treated as a single object, rather than multiple 'ammo' types...
Probably best solution for Ufopadia is automatically clone article with different title and text for each used weapon slot.
Simply you will get:
Pistol
Pistol (Grenade)
Pistol (Scope)
I will work on this in next days.
Bug report for 3.8... inventory copying doesn't work, see screenshot before/after copying.
Tested on e4c8220, no mods.
I will look on this too.
-
Bug with guns that have melee components: trying to hit with the melee component when the gun is out of ammo results in "NO AMMUNITION LOADED".
-
Thax for report.
-
I push new bug fix version to github that fix biggest bugs.
-
The tanks, on the mission disappear the first weapon. But the second has 4 ammunition consumed simultaneously. The terrorists who have 2 weapons, the same. The problem is solved by prescribing slots. Before, it was not necessary.
As before, the aliens killed by mines are not recorded in the counter of the killed and do not give experience to the soldiers.
-
I will look on this too.
-
Hey!
Is there a place which we can see every new things added by XCE+ with some info and how to do it?
Like a weapon item code with every new rules in it which i can use with a info sticked to it..
I read many nice things here but i don't have any idea how to use them when i mod.
I want to start to my mod but before i want to see all the option i can implement or use, and how to do them. I checked many links and i really get confused. I simply want somewhere to show show me what i can do, like https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom).
For example i read that you implemented the grenade launcher addition but i did not see any ruleset reference to that about how to use.
Please enlighten me..
-
Is there a place which we can see every new things added by XCE+ with some info and how to do it?
Ohartenstein and myself have answered this question already: https://openxcom.org/forum/index.php/topic,4784.msg84355.html#msg84355
There are the things mentioned in that post:
- Yankes' ruleset samples for OXCE
- my changelog for OXCE+
- and my release notes for OXCE+;
...and the ruleset of existing mods for OXCE+ like:
- PirateZ (piratez actually contains almost 100% of features from OXCE+, since they were mostly made for this mod)
- Xcom Files
- and a few more
...which is already a lot... it's not given to you on a silver platter, true, but I have only so much time and I rather spend it on development than on thorough documentation (for now)... time will come when the documentation will get a priority too.
In the meantime, same as for OpenXcom, everyone is welcome to help create a ruleset wiki...
For example i read that you implemented the grenade launcher addition but i did not see any ruleset reference to that about how to use.
Grenade launchers can easily be done in vanilla too, many mods have them.
You just need to set arcing trajectory on, like this:
items:
- type: STR_GRENADE_LAUNCHER
arcingShot: true
-
Sry for asking that again, i wanted to be sure to have all the resources and no misses. I will start to search those places and look to that big mods.
As grenade launcher, i mean to add a grenade barrel to normal guns.
I know and understand well, that you are coding and modding same time and there is only some people who can give time for big projects, so a proper wiki would be the last priority.
When you plan to make something big and detailed, you need to know everything before planning, or any single thing you missed will be a huge problem when trying to include it.
Thank you again.
-
As grenade launcher, i mean to add a grenade barrel to normal guns.
Here's an example, directly based on Yankes' ruleset samples.
It's a modded standard rifle:
- snap shot has been modded to fire 2 shots
- autoshot has been replaced by a grenade launcher
items:
- type: STR_RIFLE
confAimed:
shots: 1
name: STR_AIMED_SHOT
ammoSlot: 0
confSnap:
shots: 2
name: STR_SNAP_SHOT
ammoSlot: 0
confAuto:
shots: 1
name: STR_FIRE_IN_THE_HOLE
ammoSlot: 1
ammo:
0:
tuLoad: 10
toUnload: 20
compatibleAmmo: [ STR_RIFLE_CLIP ]
1:
tuLoad: 20
toUnload: 40
compatibleAmmo: [ STR_GL_HE_AMMO ]
When you plan to make something big and detailed, you need to know everything before planning, or any single thing you missed will be a huge problem when trying to include it.
Nah, this is not rocket science :)
OpenXcom wiki was also made more by volunteers than the developers.
-
So we can edit shooting types too now? It's great. Because i plan to make "rifle" type weapons more burst wise, like 3 shot snaps and 10 shot burst, like real life.. but it's very hard to balance at a game like this.
And i tried this but did not work. I think it's because i used XCE+ right? It does not have it as i see it's still ver 37 and this code is at 38..
-
And i tried this but did not work. I think it's because i used XCE+ right? It does not have it as i see it's still ver 37 and this code is at 38..
Yes, this functionality is only available in OXCE and OXCE+, version 3.8a or later
-
Yes, this functionality is only available in OXCE and OXCE+, version 3.8a or later
This is what my mind blows.. i don't know maybe heat made me stupier but i am really confused..
I am looking to:
-XCE topic of yankees and it says, it's ver38.. : https://openxcom.org/forum/index.php/topic,2915.0.html
-XCE+ topic of yours and it says ver37.. : https://openxcom.org/forum/index.php/topic,5258.0.html
-Nightly just get updated by your new research code.. : https://openxcom.org/git-builds/
So i see 3 different exe's.. and the final XCE+ at your topic is 37 and when i use it, this code does not work but you say, i need 3.8a which nowhere i can find.. there could be some type missing at this topics about version numbers maybe.
Can you show me where is the 3.8a XCE+ with this multi ammo code and your research fix.
Thank you again..
-
This is what my mind blows.. i don't know maybe heat made me stupier but i am really confused..
I am looking to:
-XCE topic of yankees and it says, it's ver38.. : https://openxcom.org/forum/index.php/topic,2915.0.html
-XCE+ topic of yours and it says ver37.. : https://openxcom.org/forum/index.php/topic,5258.0.html
-Nightly just get updated by your new research code.. : https://openxcom.org/git-builds/
So i see 3 different exe's.. and the final XCE+ at your topic is 37 and when i use it, this code does not work but you say, i need 3.8a which nowhere i can find.. there could be some type missing at this topics about version numbers maybe.
Can you show me where is the 3.8a XCE+ with this multi ammo code and your research fix.
Thank you again..
Yes, these are 3 different EXE's (vanilla (OXC), OXCE and OXCE+).
1. Latest vanilla is here: https://openxcom.org/git-builds/
- It doesn't have any version
- It contains my research fix
- It doesn't contain the multi-ammo code (and never will)
2. Latest OXCE is here: https://openxcom.org/forum/index.php/topic,2915.0.html
- It is version 3.8a
- It doesn't contain my research fix, because it hasn't been merged yet (earliest in 3.9)
- It does contain the multi-ammo code
3a. Recommended OXCE+ is here: https://openxcom.org/forum/index.php/topic,5258.0.html
- It is version 3.7
- It doesn't contain my research fix, because it hasn't been merged yet (earliest in 3.9)
- It doesn't contain the multi-ammo code, because it hasn't been merged yet
3b. Latest (not yet officially recommended) OXCE+ is here: https://openxcom.org/forum/index.php/topic,4187.msg84153.html#msg84153
- It is version 3.8a
- It doesn't contain my research fix, because it hasn't been merged yet (earliest in 3.9)
- It does contain the multi-ammo code... but there are known bugs... which is why I haven't updated the recommended download to this version yet
-
@drages: One way to look at it, is that you are surfing the cusp of development. You are trying to leverage improvements from three different Developer teams (Vanilla, OXCE-Yankes, OXCE+-Meridian). The benefit is all the great new features, the cost is un-discovered bugs and migration times as some features move back and forth between versions. And all this is limited by the amount of free time that these volunteer developers have to work on the project/features you are interested in.
-
@drages: One way to look at it, is that you are surfing the cusp of development. You are trying to leverage improvements from three different Developer teams (Vanilla, OXCE-Yankes, OXCE+-Meridian). The benefit is all the great new features, the cost is un-discovered bugs and migration times as some features move back and forth between versions. And all this is limited by the amount of free time that these volunteer developers have to work on the project/features you are interested in.
I know what they do for the public.. i am not a developer class but 3-4 years as a modder. This is a standard problem when there is many developers working together and alone at same time. It's just a bit complicated for just only modders with all exes, development diaries, scripts and more. I see the way much more clear now.
-
I will look on this too.
Hi Yankes, did you have time to check what it is?
If not, I am attaching a small mod (HwpTest.zip) for xcom1, extracted from piratez, where you can test 2 HWPs (Tank/Autocannon and Tamed Boomosaurus).
Differences illustrated in the attached picture.
-
Recently I do not find enough time to sit and analyze this bugs, but I will try fix them in this week and release new version (maybe with master merge what you waiting for).
-
Recently I do not find enough time to sit and analyze this bugs, but I will try fix them in this week and release new version (maybe with master merge what you waiting for).
No pressure, take your time.
EDIT: also, for completeness, this was reported on my thread: https://openxcom.org/forum/index.php?topic=4187.msg84402#msg84402
-
I fix all know bugs and merge with master, I will add couple of new small features and release new version.
-
One more similar, but different bug that needs a fix: https://openxcom.org/forum/index.php/topic,5047.msg84804.html#msg84804
A fatal error has occurred: Unsupported action (val: 12) for item STR_DOGE_TRACK
Notice val: 12 (BA_LAUNCH), not 8 (BA_SNAPSHOT) as in the earlier bug
-
And one request:
For damage preview, I would need a method BattleItem->needsAmmoForAction()
Could you add that to OXCE?
(or paste a code snippet that would do it here, I don't want to study the whole thing just to add one small method... call me lazy)
Currently only needsAmmoForSlot() is available.
-
And one request:
For damage preview, I would need a method BattleItem->needsAmmoForAction()
Could you add that to OXCE?
(or paste a code snippet that would do it here, I don't want to study the whole thing just to add one small method... call me lazy)
Currently only needsAmmoForSlot() is available.
Consider it done
-
One more potential bug report or at least a question.
I found this, when I could not load save from this post: https://openxcom.org/forum/index.php/topic,5047.msg84804.html#msg84804
Seem like clip loaded in weapons are not assigned to a correct slot... is that intended or not?
See attached picture.
-
Clip in weapon do not belongs to any inventory, it would be strange if ammo is in "hand" but weapon is in backpack.
In 3.8 I add clearing inventory slot when item is loaded to weapon.
I will look on this bug, probably my change expose place where game check slot for this that should not have a slot.
-
A minor improvement suggestion: hitting unconscious enemies shouldn't be giving experience.
-
A minor improvement suggestion: hitting unconscious enemies shouldn't be giving experience.
I can do that... but isn't it a bit harsh on the player?
-
A minor improvement suggestion: hitting unconscious enemies shouldn't be giving experience.
Perhaps was meant, the stun of conventional weapons, but not specialized stunning weapons? If so - totally agree.
-
I can do that... but isn't it a bit harsh on the player?
Why would anyone shoot an unconscious enemy, and expect to be rewarded for this to boot?
Have you ever done this? I probably haven't. And if I had, I certainly wouldn't have expected to get exp for this. It's just... weird.
-
Yes, I would.
It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?
-
It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?
I dunno, it's matter for perception. For you it is obvious that you should get XP, and would be surprised if you don't. For me it is obvious that you should not get XP, and would be surprised if you do.
We could theorize on why our perceptions differ, but I don't think it matters. For me it's just weird that you get XP for something that does not involve any kind of challenge. I certainly wouldn't give XP to my players in an actual RPG session, that's probably self-evident.
I don't really care either way at all, just musing.
-
For me it's just weird that you get XP for something that does not involve any kind of challenge.
Then I would need to remove exp for blindly using blaster launcher across the map, remove exp for blindly throwing grenades around, remove exp for randomly placing proxies and so on and so on... there's tons of ways and situations where you get xp for nothing, I just don't see why there should be particularly this one exception... especially since it happens so rarely (getting a live alien is preferred over killing them no?).
-
Which is exactly why I don't think it's an issue. :)
-
Clip in weapon do not belongs to any inventory, it would be strange if ammo is in "hand" but weapon is in backpack.
In 3.8 I add clearing inventory slot when item is loaded to weapon.
I will look on this bug, probably my change expose place where game check slot for this that should not have a slot.
OK, one more thing that was just found, maybe related to this.
Inventory copying doesn't work with loaded guns.
E.g. inventory copying with unloaded rifle works fine, but with loaded rifle it says "not enough items to copy template".
Reproducible without any mods.
-
OK, one more thing that was just found, maybe related to this.
Inventory copying doesn't work with loaded guns.
E.g. inventory copying with unloaded rifle works fine, but with loaded rifle it says "not enough items to copy template".
Reproducible without any mods.
Fast test show that this work partially fine, if you have only weapon (with ammo) in layout is work without errors.
This is why I miss this bug last time I fix bugs in coping.
[ps]
When saving again layout its behave different.
-
It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?
The same reason why throwing on empty tile doesn't... simply put, firing blindly if hits, is a matter of luck; shooting unconscious enemy is using fallen Merc to train xp by the whole crew taking turns emptying an smg clip into him (yes one player did boast of such a 'tactic'). If you don't think such behaviour shouldn't be rewarded, I don't know what to tell you. Also I won't take the usual 'you cannot completely stop players from abusing the system'. It is obvious that it is impossible, but increasing their suffering at every turn is a just goal :)
But I have come here with another question/request. There is an option to have a facility require items to be built. When not enough items are present, a message STR_NOT_ENOUGH_ITEMS displays. Is there a magical yaml trick to make this message display what items are needed? Because without this, there is a problem of communicating this to the player.
-
shooting unconscious enemy is using fallen Merc to train xp by the whole crew taking turns emptying an smg clip into him.
This can never be prevented. If shooting the unconcious merc doesn't give xp, simply use a medpack to get him back up.
I was thinking some time about another way to award XP that is more realistic/less abuseable. What I came up with is this:
You get no XP in combat. What you get is "participation" XP, like it is done now for health and stamina gain. If you "participated" in a mission, you then get a boost to stat gains from the gym of say 200% for the next 10 days. Because the stress of the mission really motivated you to work out harder. A new mission during that time extends the time of the bonus. You can train above training caps only if you have the bonus. So you can get to the statcaps.
This system would deal with two issues:
- Many missions in a short time for a soldier don't give huge stat increases. You would be encouraged to rotate your crew so everyone sees regular action.
- No worrys about spreading kills between soldiers so all get xp. No more micromanaging "I need to train throwing on this guy"
This system would need training to be enabled without the facilities. A gym would then just give a bonus or increase the training caps. Also, the right now non-trainable skills like reactions and bravery need to be handled somehow.
-
You realize that the "gain through performance" aspect of X-COM's stat system is an integral part of what made the game great in the first place. Replacing it with something else is not going to go over well with purists.
-
Hi Yankes,
2 more bugs reported by karadoc on discord for v3.8.
Here's the fixes: https://github.com/karadoc/OpenXcom/commit/1dc1e7d192a922b81885493b940cfefd2403b445
I didn't check them, just forwarding.
Attached also 2 piratez saves where it crashes.
-
But I have come here with another question/request. There is an option to have a facility require items to be built. When not enough items are present, a message STR_NOT_ENOUGH_ITEMS displays. Is there a magical yaml trick to make this message display what items are needed? Because without this, there is a problem of communicating this to the player.
Use {0} in the translation of STR_NOT_ENOUGH_ITEMS.
Only first missing item will be communicated.
-
For exp, I think best solution would be adding scripts (tm) :>
Best part would be that source code will not be pouted with every possible version how it should work (no exp from stunned/no exp for indirect fire/no exp for unarmed etc.).
Another this would be that you could create non combat enemy units what will not grain exp or some or some elite enemies what will give you more exp or enemy will have limited exp to give (only first couple of hits will grain exp).
@Meridian I will check it.
-
Here's another crash for you:
In the attached save, the game crashes after ending turn due to an 'unsupported action'.
I've looked into it, and found the problem is in `AIModule::psiAction()`
In particular, this part is causing the crash:
if (_visibleEnemies)
{
auto ammo = _attackAction->weapon->getAmmoForAction(_attackAction->type);
if (ammo && ammo->getRules()->getPowerBonus(_attackAction->actor) >= weightToAttack)
{
return false;
}
}
The `getAmmoForAction` crashes in this cause because the _attackAction is BA_RETHINK, which doesn't have associated rules, and hence causes a crash.
This seems easy enough to fix, but the best way to fix it depends a bit on coding style and on what you are actually trying to achieve with this bit of code.
For example, I personally think it's a bit weird that `const RuleItemAction *BattleItem::getActionConf(BattleActionType action) const` throws an exception when the result is NULL. If the result is never allowed to be NULL, then the return type should be a reference, not a pointer. So I'd probably fix the problem by not throwing the exception in `getActionConf`, and instead checking for NULL elsewhere. In this case, if `getActionConf` returns NULL, then `getAmmoForAction` should also return NULL.
If `getActionConf` no longer throws, then it would probably be wise to check for NULL every time it is used. But since no one is trying to catch the exceptions anyway, it won't really make any difference even it does return NULL an no one checked. It will just seg-fault instead of having a uncaught exception.
Anyway, as I said, the best way to fix this crash depends on how you like your code to behave. I'll leave it up to the people in charge. But I will say that in my view, `getAmmoForAction` should not crash no matter what 'action' is given to it. So I suggest that the bug should be fixed in that part rather than in the AI.
--
[edit]
On closer inspection, the code already has a function called `getActionConfNullable`, which is the same as `getActionConf` except that it returns null instead of throwing. As I said before, no one is trying to catch these exceptions... so I really don't know why the exception throwing version of the function even exists. In any case, here's a simple patch for the bug. Enjoy.
https://github.com/karadoc/OpenXcom/commit/0b1a95322c15ef61d40e2b6cc9a0499191bb5f2d
-
Right, fast fix is to not throw in `getActionConf`, but what point is then checking for ammo in that weapon then if always it will return `null`?
I added this throw to catch logic bugs like this situation when code ask for ammo for some unrelated action.
Proper fix would be check correct action type (aim/auto/snap/hit) otherwise we could remove this check completely.
-
Right, fast fix is to not throw in `getActionConf`, but what point is then checking for ammo in that weapon then if always it will return `null`?
The point is that it allows you to ask for the ammo type without having to first check if the action is an attack, if the attack needs a weapon, if the weapon is loaded, and whatever else comes up. Apparently the AI code in this particular case just wants to know if their weapon attack power is above some arbitrary threshold to overrule their decision to use psi. If there is no ammo, that's fine - it just means that the attack power is not above the threshold, because there is no attack. It certainly isn't a case where we'd want to throw an exception. And I imagine there could be many other similar situation. There is no problem with getAmmoForAction returning null when there is no ammo associated with the action. That's exactly what I'd expect it to do, and it's a meaningful return value.
[edit]
By the way, if you are trying to catch logic bugs, I suggest that using something similar to `assert` would be nicer than using `throw`. As I player, I don't mind being warned that something unexpected has happened - but it is very annoying to lose playtime because of it. I mean, I think it would be nicer if there was a message saying that something has gone wrong without the game immediately crashing.
-
Proper fix would be check correct action type (aim/auto/snap/hit) otherwise we could remove this check completely.
"Launch" is probably also a valid action type...
Btw. are you going to publish some hotfixes in near future? Solarius (against recommendation) used 3.8 version in xcf and it's crashing a lot.
-
Solarius (against recommendation) used 3.8 version in xcf and it's crashing a lot.
Er, no, I haven't. Some players upgraded, though.
-
The point is that it allows you to ask for the ammo type without having to first check if the action is an attack, if the attack needs a weapon, if the weapon is loaded, and whatever else comes up.
For that I added for Meridian new function in next version `needAmmoForAction` that have wide contract and can accept any action type and any item.
Apparently the AI code in this particular case just wants to know if their weapon attack power is above some arbitrary threshold to overrule their decision to use psi. If there is no ammo, that's fine - it just means that the attack power is not above the threshold, because there is no attack. It certainly isn't a case where we'd want to throw an exception. And I imagine there could be many other similar situation. There is no problem with getAmmoForAction returning null when there is no ammo associated with the action. That's exactly what I'd expect it to do, and it's a meaningful return value.
Problem is that in this case it will never return any ammo, because action type is always rethink. This line is not checking what it suppose to check. Returning null will only hide bug that I introduce there.
[edit]
By the way, if you are trying to catch logic bugs, I suggest that using something similar to `assert` would be nicer than using `throw`. As I player, I don't mind being warned that something unexpected has happened - but it is very annoying to lose playtime because of it. I mean, I think it would be nicer if there was a message saying that something has gone wrong without the game immediately crashing.
`assert` terminate program too (if is enable, otherwise will not do anything). You are right that `throw` is annoying for player but flip side is that if error would be only logged then user will never report it because game run "fine".
I will think about better solution that will not f*** up user and force him to report bugs, right now I think about big read text on top of screen. This will be annoying enough to force player to report bug but will not interrupt his game.
"Launch" is probably also a valid action type...
Btw. are you going to publish some hotfixes in near future? Solarius (against recommendation) used 3.8 version in xcf and it's crashing a lot.
And it is supported like other ones.
And for new version, it will be released today or tomorrow, it will be with new goodies from master and fix for all reported bugs.
-
New version is ready, primary change is merge last changes from master and bug fix.
New functionality is script that can alter exp grain (as multiplier on top of Meridian system).
-
From what I can tell, you haven't included a fix for the crash we were just discussing; the one fixed by this (https://github.com/karadoc/OpenXcom/commit/0b1a95322c15ef61d40e2b6cc9a0499191bb5f2d).
For the particular save file that I uploaded, it was faulty AI which caused the crash - as you pointed out - but nevertheless, the patch that I've posted would prevent this crash and potentially prevent other similar crashes. The patch makes the behaviour of `getAmmoForAction`consistent with the new `needsAmmoForAction` function, in that neither should crash if the action does not have rules set.
Of course, you'll probably want to fix the AI problem as well. If you use my patch, then you can just leave the AI alone and fix it later. Alternatively, if you don't like my patch, you could just delete the problematic block from the AI and it will make no difference (other than avoiding the crash).
Here's the relevant bit of code
if (_visibleEnemies)
{
auto ammo = _attackAction->weapon->getAmmoForAction(_attackAction->type);
if (ammo && ammo->getRules()->getPowerBonus(_attackAction->actor) >= weightToAttack)
{
return false;
}
}
else if (RNG::generate(35, 155) >= weightToAttack)
{
return false;
}
If you delete that inner if block, that will avoid the crash. (That condition will never be true anyway, because the attack action never has ammo.) Perhaps it would be even better to delete the entire `_visibleEnemies` block though, just leaving the final random number test.
--
In other news, I've been making some tweaks to how items are arranged on the ground. Check out the attacked picture comparing the current unorganised equipment pile vs the sorted equipment pile from my code. I'll upload a patch for that soon if you have interest in it.
-
One more similar, but different bug that needs a fix: https://openxcom.org/forum/index.php/topic,5047.msg84804.html#msg84804
A fatal error has occurred: Unsupported action (val: 12) for item STR_DOGE_TRACK
Notice val: 12 (BA_LAUNCH), not 8 (BA_SNAPSHOT) as in the earlier bug
I will add that this bug was also not fixed yet... still crashes.
-
Here's the relevant bit of code
if (_visibleEnemies)
{
auto ammo = _attackAction->weapon->getAmmoForAction(_attackAction->type);
if (ammo && ammo->getRules()->getPowerBonus(_attackAction->actor) >= weightToAttack)
{
return false;
}
}
else if (RNG::generate(35, 155) >= weightToAttack)
{
return false;
}
If you delete that inner if block, that will avoid the crash. (That condition will never be true anyway, because the attack action never has ammo.) Perhaps it would be even better to delete the entire `_visibleEnemies` block though, just leaving the final random number test.
sh*** I forget to fix it, and again you do not fix this but, you remove this check because Psi is always check before Weapons and this cause that `_attackAction->type`do not have any valid attack type. This was my whole point.
Notice val: 12 (BA_LAUNCH), not 8 (BA_SNAPSHOT) as in the earlier bug
I will add that this bug was also not fixed yet... still crashes.
Failed again :/ I focus too much on "NULL" bug :/
I will release today fixed version.
-
Missed bugs are fix.
-
Here is my patch for improving the order of items on the ground.
https://github.com/karadoc/OpenXcom/commit/c446001e3f13f1be0352fd9bf3e6b307a71ee0d4
Note that most of the changes in the patch are just cosmetic things, changing the interator loops to be range-based for loops. I just made those changes for my own benefit, to make the code easier to read so that I could see what I was doing.
There's only really three lines that make any difference: the sorting of the list, the starting x position when placing an item, and the 'break' rather than 'continue' for quick search (which is just for efficiency).
---
By the way, I like the fix for the psi bug. It looks like you've fixed the caused of the crash, fixed the faulty AI, and improved the robustness of the functions involved.
-
Missed bugs are fix.
Thanks, it works now.
I am currently trying to merge oxce 3.9a, but I get compilation errors... can you have a look at the attached picture please?
-
I see, VS is more restrictive in that case, I will fix it.
[ps]
check if it fix your error: https://github.com/Yankes/OpenXcom/commit/3ce7a4cd72580743a579405f0164df9262e183ec
-
I see, VS is more restrictive in that case, I will fix it.
check if it fix your error: https://github.com/Yankes/OpenXcom/commit/3ce7a4cd72580743a579405f0164df9262e183ec
Yes, it's fixed.
I have fixed one more CTD: https://github.com/MeridianOXC/OpenXcom/commit/729f82f07a7cf81bc3e1aac741d1a67dac8fc810
You should cherry-pick that into OXCE too.
And one optional fix/change: https://github.com/MeridianOXC/OpenXcom/commit/327e1ace90ffcf3a4a4cbe2fdea03ac7909519cf
This enables ammo animation also on "combo-ammo weapons" (e.g. throwing knives + grenade laucher)
-
Yes, it's fixed.
I have fixed one more CTD: https://github.com/MeridianOXC/OpenXcom/commit/729f82f07a7cf81bc3e1aac741d1a67dac8fc810
You should cherry-pick that into OXCE too.
And one optional fix/change: https://github.com/MeridianOXC/OpenXcom/commit/327e1ace90ffcf3a4a4cbe2fdea03ac7909519cf
This enables ammo animation also on "combo-ammo weapons" (e.g. throwing knives + grenade laucher)
Thanks for fixes
-
I like that you added up to 20 damage types I was reading the code you got extra D_1 to D_10
-
I left the UFO for a while and do not know some things. Did not watched. I dug in the latest updates of everything that is, but I did not understand - was the critical bug corrected, with the experience and frags not being added, for the enemy killed by the mines? Does anyone do something about this monstrous bug?
-
I do not recall this exact bug in Extended, if it existed it was probably fix already.
-
I do not recall this exact bug in Extended, if it existed it was probably fix already.
If even you do not know, then nothing has been fixed. It's a pity.
2. Soldiers do Not credited dead aliens, if they died from an explosion of mines / proximity grenades of any type damage.
There are some fixes in vanilla waiting to be merged into OXCE 3.9 and also Yankes made some changes in OXCE 3.8... probably best to wait for 3.8 or 3.9 and re-test again.
-
I left the UFO for a while and do not know some things. Did not watched. I dug in the latest updates of everything that is, but I did not understand - was the critical bug corrected, with the experience and frags not being added, for the enemy killed by the mines? Does anyone do something about this monstrous bug?
1. Experience was always correctly counted.
2. Frags I didn't check... there are two kinds of frags actually... one normal game counter and one counter in diaries... I believe that only the diaries counter was bugged, the normal game frag counter was OK (99% sure)
EDIT: well, I've been proved wrong... :( see below
3. So the only thing you are missing are medals for some frags... which is not a "monstrous bug".
As I said, there were some fixes in recent nightlies... and they were merged in OXCE 3.9a and also OXCE+ 3.9a... you may want to retest and let us know if it works now...
-
Sometimes flames do not generate light (see screenshot).
It happened there when the tile was hit by a flame arrow (PirateZ). One turn later when the fire spreads lighting is proper again.
-
3. So the only thing you are missing are medals for some frags... which is not a "monstrous bug".
As I said, there were some fixes in recent nightlies... and they were merged in OXCE 3.9a and also OXCE+ 3.9a... you may want to retest and let us know if it works now...
In version OXCE+ v3.9a - the bug has not been fixed.
Let someone else test it. And that can at me somewhere an bug, which I can not identify in any way?
-
In version OXCE+ v3.9a - the bug has not been fixed.
Let someone else test it. And that can at me somewhere an bug, which I can not identify in any way?
I can confirm it works in newest nightly.
I can unfortunately confirm it doesn't work in OXCE.
I do not recall this exact bug in Extended, if it existed it was probably fix already.
It's not fixed.
Attached a save to reproduce.
Steps:
1. load
2. end turn to get 2 kills with proxy
3. ctrl+D ctrl+K to kill remaining aliens
4. no experience and no kills :(
I'll have a look at it eventually, not sure when... if you have more time Yankes, feel free to investigate.
-
Sometimes flames do not generate light (see screenshot).
It happened there when the tile was hit by a flame arrow (PirateZ). One turn later when the fire spreads lighting is proper again.
I can confirm it works in newest nightly.
I can unfortunately confirm it doesn't work in OXCE.
2x I will look on this
-
Mouseover over a clip doesn't show ammo count.
reported here: https://openxcom.org/forum/index.php/topic,4595.msg85774.html#msg85774
EDIT: looks like this bug was introduced by my latest commit (for combo weapons), I'll prepare a fix this week
EDIT2: also melee weapons show 255 ammo, probably wasn't like that before... I'll make comparison of all types between 3.7 and 3.9 and post an update later
-
Just reported this problem and was advised to post here, hopefully this is the right place.
https://openxcom.org/forum/index.php/topic,5604.msg85815.html#msg85815
EDIT by Meridian: fixed link
-
Just reported this problem and was advised to post here, hopefully this is the right place.
https://openxcom.org/forum/index.php/topic,5604.msg85815.html#msg85815
@Yankes
The images don't have any palette and oxce crashes on surfaceset copyconstructor: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Mod/Mod.cpp#L3693
Vanilla doesn't use copyconstructor... maybe because of this?
-
a) Right now you can easy remove this line completely because reason it was added was fixed (old draw item code modified x and y making impossible to draw same graphic on both hands).
b) Old copy was completely broken and when I fixed it I removed custom code that was work around of not working copy.
c) Because that was custom code it do not copy surfaces set exactly thous ignoring cases like lack of palette.
d) We could fix it by allowing coping `Surface` without but case a) exists and ...
e) 99% of surfaces ignore palettes (`blitNShade` respect only byte values nothing else), we could throw it away and it would still work only exception could be your ufopedia rich palette mode because I do not look on your code to know how it works (with it we could throw away SDL_Surface too, because it only needed for screen)
-
One more from the discord.
Mindcontrol/Panic/Use on psi-amps doesn't work on units on stairs.
Save attached... try panicking the sectoid on the stairs.
The visual effect is actually the same as in vanilla in this case... but the piratez save where I tried this first was not going only +1 z-level but also to the sides...
The not working psi amp is however much more important issue, let's forget about visual issue for now.
-
Mouseover over a clip doesn't show ammo count.
reported here: https://openxcom.org/forum/index.php/topic,4595.msg85774.html#msg85774
EDIT: looks like this bug was introduced by my latest commit (for combo weapons), I'll prepare a fix this week
EDIT2: also melee weapons show 255 ammo, probably wasn't like that before... I'll make comparison of all types between 3.7 and 3.9 and post an update later
Fixed both: https://github.com/MeridianOXC/OpenXcom/commit/aaa54fa338357efb83f13ff7b33783c1ca975bc9
As far as I can say all item types now display ammo count correctly.
-
Crash in AI code.
Reported here: https://openxcom.org/forum/index.php/topic,5617.0.html
-
It is a good thing Oharty basically plans to rewrite the AI. :D
-
It is a good thing Oharty basically plans to rewrite the AI. :D
I seriously doubt he is.
And if so, there's no way I'm taking that into oxce+.
-
Crash in AI code.
Reported here: https://openxcom.org/forum/index.php/topic,5617.0.html
fix is probably add `&& _attackAction->weapon` to `if (_visibleEnemies)` in `psiAction`. This could affect vanilla too because there was no test for alien without weapon.
btw when you show screenshot with null reference exception is better to show place where null object was used not where member function access null `this`.
-
I seriously doubt he is.
And if so, there's no way I'm taking that into oxce+.
Yep, no re-write, just some switches to flip to activate some interesting behavior, like squadsight snipers.
-
I would like to use the race dependent custom deployment for ufos (meaning I want to give each race their own equipment in their UFOs):
ufos:
- type: STR_UFO_TYPE #default config ...
raceBonus: #bonus stats per race.
STR_SECTOID: #name of race that bonus apply.
craftCustomDeploy: STR_BATTLESHIP_3 #override craft default weapon deploy.
so I tried the following code
- type: STR_LARGE_LIGHTER
raceBonus:
STR_GESSERIT:
craftCustomDeploy: STR_LARGE_LIGHTER_GESSERIT
I defined my custom deployment in the alienDeployment section.
For testing, I tried the new battle option and the custom deployment is used as intended.
However, there is no UFO spawned and the mission became a terror mission which needs custom briefing (see screenshot).
I only wanted to change the equipment for the specific race in a specific UFO and not change the mission type. Is this possible with "craftCustomDeploy"?
EDIT: I did the mission during regular play (shooting down the UFO) and the deployment works fine. However, the mission played with the "new battle" from the main menu is messed up.
-
fix is probably add `&& _attackAction->weapon` to `if (_visibleEnemies)` in `psiAction`. This could affect vanilla too because there was no test for alien without weapon.
btw when you show screenshot with null reference exception is better to show place where null object was used not where member function access null `this`.
So, what is an issue source? Alien without weapons? Or terror unit without "fixedweapon"? Or psionic alien?
What can i modify in savegame or ruleset to avoid this bug? (Just for now, because no fixes exist)
-
It look as when game check psi and unit do not have any normal weapon it can crash game on this check. I did not test this fully because I have had trouble with finding time to work on OXC related stuff but I will try in this week fix this bugs.
-
Is there a way to adjust shotguns? I often feel multi shot rounds like shotguns are pretty well garbage, because the buckshot spread is either incredibly tight, or incredibly wide : its not so much a full buckshot blast spreading in the direction fired, after being fired, its more the shots all act like individual bullets fired with the spread of the pawns aim as well, giving shotguns ridiculous pellet spread when used by a bad shot, but very tight spread when used by a guy with high skill. I never rely on shotguns with buckshot for this reason, as pellets end up being a mess often times.
I certainly would like if shotguns were altered : infact, I figure this might be doable by having a firearm accuracy, round accuracy, and then user accuracy : where the firarm / ammo is the CAP of the performance of the weapon, and then the weapon has a curve in performance based on skill : this way a bad shot could fire a shotgun, and the pellet spread would always be more or less identical as when fired from a good shot, but the ability to aim this shot itself would be different.
-
Check this thread (https://openxcom.org/forum/index.php/topic,4834.msg69314.html#msg69314) out, these options have been in OXCE+ for quite some time now and are used heavily in Piratez and X-Com Files. I hope that provides what you're looking for.
-
@Yankes: a few vanilla melee weapons (e.g. TFTD thermal tazers) and a few modded weapons have stopped working in 3.9 because they don't have "clipSize: -1"...
... do we want to make it somehow compatible again... or should I just PR a ruleset update upstream to supsuper?
In my opinion... unless there is something deeper behind it, we should just update rulesets to contain clipsize: -1 as most melee weapons already do... what's your opinion?
-
Thought question, when I made this changes I look on ufo1 and piratez ruleset and everywhere I saw -1 in melee weapons. This allow me to heavy simplify logic responsible for spending/using ammo. Adding more special checks will made code worse but I see one place where change would be simple and work in 99% cases, simply when item rule is loaded and item type is changed to melee than we can set `clipSize: -1` as default that will be override by typical weapons or ignored by minority. One draw back will be if someone try change item type on existing item, then original clip size will be set to default.
-
As far as I understand:
clipsize = -1 is unlimited "ammo"
clipsize = 0 doesn't make any sense, right? not even for firearms... or is it used for something? (EDIT: it is)
clipsize > 0 is used for firearms and for some exotic melee weapons (like bamboo stick in piratez)
If my assumption about clipSize = 0 not being used at all is true (EDIT: it isn't), I would either:
- just update vanilla rulesets
- or change the default value on RuleItem level to -1 instead of 0 (for everything, not only battletype 3)
EDIT: ruleset reference from ufopedia even says the game crashes when clipsize = 0
https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)#Items
The amount of ammo stored in each weapon clip. If -1 is specified, this weapon has infinite ammo. If specified for a HWP, clipSize determines the maximum amount of shots which can be loaded into the HWP weapon. Use clipsize -1 for melee weapons. If clipsize is 0 for a melee weapon, the game will crash if an AI unit attacks with it.
EDIT2: so, clipsize = 0 is used for HWPs (means load just one clip)... can't change the default... I'd just update the ruleset and not change the code at all
EDIT3: fixed: https://github.com/SupSuper/OpenXcom/commit/f818e539ffedb5898b41fba372dd01d552d61e95
-
Fix for a very old merge issue: https://github.com/MeridianOXC/OpenXcom/commit/938c1e772eff2d35fe51da2881438ab79420566b
-
I noticed a curious thing (intended? bug?): the
isExplodingInHands:
flag is not working for BT: 5 items (proxies). Can this function be added (with explosion delay = 0 if no timer set)?
-
Found a segfault that I think was introduced with this commit (https://github.com/Yankes/OpenXcom/commit/90c6dc70f172c26022ebc859050799a9fc8e5c5e). When an alien that has previously panicked and dropped their weapon attempts at psi attack, _attackAction->weapon->getAmmoForAction(action) on line 2036 is sometimes called with an incomplete type, leading to a crash. I'm attaching a save and a zip file containing the mods and options.cfg used in that save; after pressing end turn, when the sectoid leader moves into sight of one of the xcom units, the game will often crash.
-
Fix for a very old merge issue: https://github.com/MeridianOXC/OpenXcom/commit/938c1e772eff2d35fe51da2881438ab79420566b
Thax, I will pull this.
I noticed a curious thing (intended? bug?): the isExplodingInHands:
flag is not working for BT: 5 items (proxies). Can this function be added (with explosion delay = 0 if no timer set)?
I do not look to code but I suspect that proxies do not explode until someone step on them.
Found a segfault that I think was introduced with this commit (https://github.com/Yankes/OpenXcom/commit/90c6dc70f172c26022ebc859050799a9fc8e5c5e). When an alien that has previously panicked and dropped their weapon attempts at psi attack, _attackAction->weapon->getAmmoForAction(action) on line 2036 is sometimes called with an incomplete type, leading to a crash. I'm attaching a save and a zip file containing the mods and options.cfg used in that save; after pressing end turn, when the sectoid leader moves into sight of one of the xcom units, the game will often crash.
Know bug, I will release fix for it soon (today or tomorrow).
-
An issue reported from XComFiles... I would describe more, but I'm not sure which part of this is wrong.
Basically load the attached save, and try to open inventory of the soldier "Rosie Pagram" => crash.
Crash is caused by an item in the inventory having inventorySlot == null.
In the save, the slot is not null (it is STR_QD_SLOT), and it gets loaded as such at first but then it gets overwritten to null in your new multi-ammo code, somewhere after this line: https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Savegame/SavedBattleGame.cpp#L315
Can you please have a look? I don't understand what's going on exactly there...
Issue is with item #29 (and also with item #15)
-
An issue reported from XComFiles... I would describe more, but I'm not sure which part of this is wrong.
Basically load the attached save, and try to open inventory of the soldier "Rosie Pagram" => crash.
Crash is caused by an item in the inventory having inventorySlot == null.
In the save, the slot is not null (it is STR_QD_SLOT), and it gets loaded as such at first but then it gets overwritten to null in your new multi-ammo code, somewhere after this line: https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Savegame/SavedBattleGame.cpp#L315
Can you please have a look? I don't understand what's going on exactly there...
Issue is with item #29 (and also with item #15)
Ok I will look on this, if I manage to fix it I will release it with other bug fix today.
I would like to use the race dependent custom deployment for ufos (meaning I want to give each race their own equipment in their UFOs):
ufos:
- type: STR_UFO_TYPE #default config ...
raceBonus: #bonus stats per race.
STR_SECTOID: #name of race that bonus apply.
craftCustomDeploy: STR_BATTLESHIP_3 #override craft default weapon deploy.
so I tried the following code
- type: STR_LARGE_LIGHTER
raceBonus:
STR_GESSERIT:
craftCustomDeploy: STR_LARGE_LIGHTER_GESSERIT
I defined my custom deployment in the alienDeployment section.
For testing, I tried the new battle option and the custom deployment is used as intended.
However, there is no UFO spawned and the mission became a terror mission which needs custom briefing (see screenshot).
I only wanted to change the equipment for the specific race in a specific UFO and not change the mission type. Is this possible with "craftCustomDeploy"?
EDIT: I did the mission during regular play (shooting down the UFO) and the deployment works fine. However, the mission played with the "new battle" from the main menu is messed up.
I could say that this is not bug, you are using custom deploy directly in new battle game not as part of ufo deploy.
Right now new battle do not use in any way overwriting of deploy that is used in normal game.
I will think for some solution for in in 4.0 version (this mean not bug fix version that I plan release today).
-
@Meridian
loading code look fine, problem is with that this item is loaded in weapon (id 11 or 27) and in unit inventory, I will probably need more info how this clip end up in inventory.
Probably bug is in code that auto fill inventory that use same clip for two different purposes. I will try hunt this but its possible that I will not find cause without some hits to narrow places to search.
-
Well, the special thing about this situation is that it was a 2-stage mission.... maybe something special is done between stage 1 and stage 2?
-
New bug fix version is ready.
Well, the special thing about this situation is that it was a 2-stage mission.... maybe something special is done between stage 1 and stage 2?
I probably find cause of this bug, on transition to second stage it grab all items on ground and move it to new start, problems was that loaded ammo was placed on ground too.
-
I probably find cause of this bug, on transition to second stage it grab all items on ground and move it to new start, problems was that loaded ammo was placed on ground too.
Yeah, there is definitely something fishy there.
I tried it in vanilla (Cydonia mission), where all aliens had just 1 clip (in the gun)... but after killing them all, in the second stage I was given 2x more clips than guns.
I'll report to Warboy...
-
Yeah, there is definitely something fishy there.
I tried it in vanilla (Cydonia mission), where all aliens had just 1 clip (in the gun)... but after killing them all, in the second stage I was given 2x more clips than guns.
I'll report to Warboy...
as reference you could use my commit: https://github.com/Yankes/OpenXcom/commit/5e97b199367cedd063f2bef1f7c2010df6c8478f
Probably this is one place where this could go wrong.
-
as reference you could use my commit: https://github.com/Yankes/OpenXcom/commit/5e97b199367cedd063f2bef1f7c2010df6c8478f
Probably this is one place where this could go wrong.
Thanks.
Here's Warboy's variation... most probably equivalent.
But I have one more report for you (I feel really bad mostly bringing bad news here):
https://openxcom.org/forum/index.php/topic,4058.msg87079.html#msg87079
We'll need your help here... might be a code error, might also be a map error.
-
Hi Yankes, just found a bug with recovering ammo from a fixedWeapon when the weapon is defined on an armor (not unit) by builtInWeapons - any ammunition loaded into such a weapon when the battlescape ends will not be recovered, even if the weapon is never fired. To reproduce, use my mod and the saves attached to this post (https://openxcom.org/forum/index.php/topic,5655.0.html), specifically the battlescape save, and just lift off. The debriefing will give the message for missing HWP Cannon Shells, even though none were fired. I've written a fix for it - see this commit (https://github.com/ohartenstein23/OpenXcom/commit/86d673addea6968fda6e08a9186def8136835666).
-
One question who create this ammo?
https://github.com/ohartenstein23/OpenXcom/blob/oxce3.5-plus-proto/src/Savegame/SavedBattleGame.cpp#L1298
As we can see with your fix you can crate new ammo if it was from fixed too.
-
Hi Yankes, just found a bug with recovering ammo from a fixedWeapon when the weapon is defined on an armor (not unit) by builtInWeapons - any ammunition loaded into such a weapon when the battlescape ends will not be recovered, even if the weapon is never fired. To reproduce, use my mod and the saves attached to this post (https://openxcom.org/forum/index.php/topic,5655.0.html), specifically the battlescape save, and just lift off. The debriefing will give the message for missing HWP Cannon Shells, even though none were fired. I've written a fix for it - see this commit (https://github.com/ohartenstein23/OpenXcom/commit/86d673addea6968fda6e08a9186def8136835666).
One question who create this ammo?
https://github.com/ohartenstein23/OpenXcom/blob/oxce3.5-plus-proto/src/Savegame/SavedBattleGame.cpp#L1298
As we can see with your fix you can crate new ammo if it was from fixed too.
On top of that, I tried to cherry-pick and test the code, but it always crashes on NPE (with both oharty's saves).
See attached.
-
@Yankes:
BA_USE on BT_PSIAMP doesn't work since the last refactoring (sectoid on stairs bug).
Attack always misses (resp. there is no victim).
Test save attached.
Tested with:
items:
- type: STR_PSI_AMP
accuracyMultiplier:
flatHundred: 2
flatRate: true
psiAttackName: CUSTOM_PSI
damageType: 1
damageBonus:
flatHundred: 1
-
One question who create this ammo?
https://github.com/ohartenstein23/OpenXcom/blob/oxce3.5-plus-proto/src/Savegame/SavedBattleGame.cpp#L1298
As we can see with your fix you can crate new ammo if it was from fixed too.
On top of that, I tried to cherry-pick and test the code, but it always crashes on NPE (with both oharty's saves).
See attached.
Need to test more before I propose a fix then, sorry. I'll rewrite after vacation with a check on whether the ammo is fixed/built-in/recoverable, and take a closer look at why I threw a null pointer for trying to get the unit of the fixed weapon.
-
@Yankes:
BA_USE on BT_PSIAMP doesn't work since the last refactoring (sectoid on stairs bug).
Attack always misses (resp. there is no victim).
Test save attached.
Tested with:
items:
- type: STR_PSI_AMP
accuracyMultiplier:
flatHundred: 2
flatRate: true
psiAttackName: CUSTOM_PSI
damageType: 1
damageBonus:
flatHundred: 1
My bad, I mess one condition here is bug fix commit:
https://github.com/Yankes/OpenXcom/commit/2d6906a8659e23d3353ae796b754df099c1259c5
-
There is a proposal for a more radical implementation of the script of energetic shields in armor https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644 (https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644). Ie - as one of the parameters of the armor (not in the "tags:" section), with the imagery (in the lower left corner) of the number of absorbed damages, with the imagery in Ufopedia in the characteristics of the armor/unit.
-
There is a proposal for a more radical implementation of the script of energetic shields in armor https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644 (https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644). Ie - as one of the parameters of the armor (not in the "tags:" section), with the imagery (in the lower left corner) of the number of absorbed damages, with the imagery in Ufopedia in the characteristics of the armor/unit.
And where is that proposal?
I see only the script there... don't see any suggestions for parameters or imagery...
-
And where is that proposal?
I see only the script there... don't see any suggestions for parameters or imagery...
The proposal comes from me. Based on the script from ohartenstein23 to do what I described the post above. Only shields not with a single actuation, as in this script, but as on ships - with a certain amount of absorbed damage.
-
My bad, I mess one condition here is bug fix commit:
https://github.com/Yankes/OpenXcom/commit/2d6906a8659e23d3353ae796b754df099c1259c5
It crashes on hit animation now... I have a fix (see attached), but probably a deeper review is needed... the use of (_hit || _psi) and _targetPsiOrHit seems inconsistent.
-
It crashes on hit animation now... I have a fix (see attached), but probably a deeper review is needed... the use of (_hit || _psi) and _targetPsiOrHit seems inconsistent.
indeed, special psi attack need `_targetPsiOrHit` to calculate hit chance but after that it should behave as normal hit. My fix should revert this test to previous ones as you suggest. previously it was only set when this condition was true, now is not true in all cases.
There is a proposal for a more radical implementation of the script of energetic shields in armor https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644 (https://openxcom.org/forum/index.php/topic,5435.msg83644.html#msg83644). Ie - as one of the parameters of the armor (not in the "tags:" section), with the imagery (in the lower left corner) of the number of absorbed damages, with the imagery in Ufopedia in the characteristics of the armor/unit.
Whole point of scripts was to not implements this in code, if I implements this it could work different what you wan. Another thing is that if code would support multiple cases/versions it will create big mess.
Your request should be different, you should ask for new features in scripts that could fulfill your goals.
e.g. When I will have some time I will add option for creating custom descriptions to ufopedia articles, this will allow displaying values of all tags in way you want.
-
@Yankes: if you find some time... there is an older bug that keeps coming back randomly... and I can't track and isolate it easily: https://openxcom.org/forum/index.php/topic,5047.msg87564.html#msg87564
Maybe you'll spot immediately, what could be causing it?
-
No, at least not in my version, maybe some your changes with more aggressive aliens cause it?
-
Can you make a miniature version of the statistics of soldiers, a separate option, with the excision of the memory of each specific mission? To just how many killed, who and what weapons.
Example -
diary:
killList:
- STR_FLOATER_SOLDIER: 4
- STR_GILLMAN_NAVIGATOR: 2
- STR_SECTOID_COMMANDER: 1
killWeapon:
- STR_GRENADE: 3
- STR_PROXIMITY_GRENADE: 1
- STR_SHOTGUN: 3
Ie - without indicating which specific mission and when each enemy was killed. And any successful action against the opponent, whether psionic, murder, stunning, or killing "improvisation", is saved only for the current battle and until its end, and then recorded in a common heap, as indicated above.
Simply, the current system very slows down the Save / Load process. When you have 250-300 soldiers who have committed 7-10 missions and killed 20-30 opponents each, the Save or Load process can take up to a minute.
-
I think this is outside of scope of my branch, I focus on new game play mechanics that improving overall game. Maybe Meridian or SupSuper would be interested in implementing this?
-
Found the issue with the fix I posted earlier; item->getUnit() was for getting the unit from a corpse item, getOwner() was what I intended to use. Also added a check to make sure the loaded ammo item is marked as recoverable. I'm assuming that the modder will set recover: false for ammo items that are built in on armors. Here's the updated commit (https://github.com/ohartenstein23/OpenXcom/commit/f12e31736c92daa0d6090b97d03538a90e2cf44a).
-
Any chance you could remove the requirement to face south to fire directly down at ones feet? Its often used to execute downed people, but needing to turn makes it cost extra TU's, and it makes no sense why you would need to turn to shoot down.
Also, is there any chance you can make TU usage change based on other stats, like larger melee weapons swinging faster with a stronger person, or odd guns firing faster with better reactions?
-
This is not requirement, this is consequence of direction calculation. Because you cant calculate correctly angle between two points in same tile it always return same value. I will look on this when I will have some free time but it possible that fixing it will need lot of work to do it correctly.
For item use cost. Biggest problem is that game engine assume that use cost do not change, this is case in AI and reaction shoots. Engine calculate cost and using it plan sequence of actions, if in between this action execution cost will change, whole chain will break.
This is primary reason why I do not allow weapon to change it cost on things that could change between actions.
In next version you could hack it, I will adding script event that will be call after each shoot, you could alter stats of unit in any way you want. This mean you could refund some TU. But still this will be able to break AI if not used carefully.
-
In my opinion... a lot of work, for close to no benefit.
-
Also, is there any chance you can make TU usage change based on other stats, like larger melee weapons swinging faster with a stronger person, or odd guns firing faster with better reactions?
This is allready implemented in vanilla game by flat ant percentage tu costs.
Look at it as: one turn is a fixed time length (a 3-5 seconds of real time). If you swing a melee weapon, you can train to do it faster. So lets say 25 tu for unit who has 50tu will be a 2seconds, but for faster unit with 100tu it will be only 1 second.
While shooting count in percent, because machinegun will not shoot faster in the hands of faster man.
Of course, all this is simplified, because this is a game. :)
-
Hey Yankes, looking into some of the multiple ammo slots features, I noticed that the ufopaedia still uses the strings for Aimed, Snap, and Auto instead of having new strings based on the confAimed, confSnap, and confAuto definitions - can you add a parameter for picking the ufopaedia name of the shot type?
Edit: Also, if a weapon uses itself as ammo for some shot types (ammoSlot: -1) but has a shot type using a separate clip, the ufopaedia article does not show the power and damage type of the 'built-in' ammo. The alternative, making ammo slot 0 have compatibleAmmo: ~ and putting the alternative ammo type in slot 1, means that only the 'built-in' ammo is shown in the article.
-
yup, Ufopedia need some changes to better handle multiple ammo types, overall I think I will allow to split article per ammo slot.
-
Any chance you can allow a mode 3 on multi level view button, which shows ONLY the selected floor, and nothing underneath? I often find with areas with lots of same textures, its hard to tell where there is and isn't gaps in a destroyed floor, and this would really help. It would also help telling exactly how big a smoke cloud is.
-
I suggest to the craftsmen to make a script to eliminate the accidental triggering of panic. If you look more broadly - a reassembly of the whole psionics.
At Morale = 0, the panic should be 100%.
Next we need 2 options to "units.rul" - "ChancePanic" and "ChanceBerserk" which by default = 50%. If the total value of these options is less than 100%, then the missing ones become a chance to ignore panic or berserk.
In addition, you need the "IgnoreMindControl" option for mechanical creatures. There were cases when the aliens took control of tanks, which should not be under any circumstances. Exactly, as well as the opportunity to take control of the alien's mechanical terrorists - the same complete nonsense.
-
Hey Yankes, could you add script hooks on priming/unpriming an item? I think those could be interesting for creating a 'transforming' weapon that goes back and forth between stationary and mobile forms, particularly with your firing and throwing scripts in the upcoming version.
-
Hey Yankes, could you add script hooks on priming/unpriming an item? I think those could be interesting for creating a 'transforming' weapon that goes back and forth between stationary and mobile forms, particularly with your firing and throwing scripts in the upcoming version.
Some thing like that I have in plans.
-
Hello Yankes,
Is the next release close by? There are some important fixes in the vanilla code I would like to see in OXCE soon.
Also, a request: can you please enable timers on flares? The reason being, with OXCE+ new sniper/spotter code, the use of flares became quite dangerous - if you hold a flare in your hand and get illuminated, some enemies remember where you are! :)
-
Next release is in far future ("thing I want add" / "free time" is very large), but Meridian ask me for merge and I will do it soon (probably with some small fixes).
"can you please enable timers on flares"
isn't "fuse type" and "exploding in hand" do this trick? Or you want something else?
-
Next release is in far future ("thing I want add" / "free time" is very large), but Meridian ask me for merge and I will do it soon (probably with some small fixes).
While I do appreciate your content very much, a new merge would be satisfactory for now. :)
"can you please enable timers on flares"
isn't "fuse type" and "exploding in hand" do this trick? Or you want something else?
No, fuse type doesn't seem to work on flares.
-
I will check it.
-
When I start a random battle with Lightning or just load a savegeme for this battle, I keep getting STR_GEN_MAP_ERROR message. Sometimes a line appears in the log
"Bad node in RMP file: ROUTES/LIGHTNIN.RMP Node #0 is outside map boundaries at X:5 Y:252
Z:251. Culling Node."
Same in OXCE (git version e00e75e07) and OXCE+ (61d22e5f6).
To reproduce, load the attached "map error.sav". The log is also attached.
P.S. In case the above is unclear:
- The error appears even without any modes enabled.
- The error doesn't appear for vanilla nightly (12fbabe5a).
-
This is not part of changes of OXCE, this is normal error message added by Warboy in nightly.
-
This is not part of changes of OXCE, this is normal error message added by Warboy in nightly.
I do not get this error in the vanilla nightly.
-
I do not get this error in the vanilla nightly.
Why not just fix the .rmp? It must be done anyway.
-
Why not just fix the .rmp? It must be done anyway.
1. It's UFO/ROUTES/LIGHTNIN.RMP, from the original game.
2. I have no idea how to do that.
-
1. It's UFO/ROUTES/LIGHTNIN.RMP, from the original game.
2. I have no idea how to do that.
The universal patch (from OXC site) should take care of all such issues.
-
The universal patch (from OXC site) should take care of all such issues.
https://openxcom.org/download/extras/universal-patch.zip and https://openxcom.org/file/2225/TFTD_MAP_FIXES.zip ? Never heard of them. Thanks.
The error no longer appears in the new missions.
-
No, fuse type doesn't seem to work on flares.
I'm now finishing version with nightly merge and I finally find time to check your bug.
Right now only case it do not work is instant grenade (-2 type). Did you tried using this type for flare?
-
Right now only case it do not work is instant grenade (-2 type). Did you tried using this type for flare?
In fact I wanted to make a flare that works like a normal grenade, with a counter.
-
In fact I wanted to make a flare that works like a normal grenade, with a counter.
Could you elaborate a bit more? what exacly behavior you wanted?
Right now it should work in this way:
Set `fuseType` to -1 (set timer) and then flare do not generate light until you prime it.
When you prime it will glow for set number of turn, when time is up flare will be removed.
You can set fixed number of turn using `fuseType` to e.g. 6 then flare will glow always for 6 turns.
-
All right, so the idea is that the flare only starts glowing after a set number of turns, and not glow on the ground, in hand etc. - only after being primed and thrown. (Of course for most situations it would be primed for 0 turns, to start glowing right at the end of your turn.)
This whole issue was created because of the recent additions to OXCE+, mostly the sniper/spotter system. Illuminating yourself when using flares simply became too risky to ignore.
I wonder if you can help me :)
-
All right, so the idea is that the flare only starts glowing after a set number of turns, and not glow on the ground, in hand etc. - only after being primed and thrown. (Of course for most situations it would be primed for 0 turns, to start glowing right at the end of your turn.)
This whole issue was created because of the recent additions to OXCE+, mostly the sniper/spotter system. Illuminating yourself when using flares simply became too risky to ignore.
I wonder if you can help me :)
I can easy made that flare will start glow after throw ("shock" will enable it). It will be two version, only throw and prime & throw to enable glow.
This will be enough?
-
I can easy made that flare will start glow after throw ("shock" will enable it). It will be two version, only throw and prime & throw to enable glow.
This will be enough?
More than enough, thank you :)
I am intrigued by the "lights up on impact" part, but having both things would be best.
-
That makes me think of the OXC grenade setting where you have to choose to either have explode-on-impact grenades or explode-at-end-of-turn grenades. It seems to me these behaviors could be integrated by adding a -1 timer to the prime setting and moving all the rest up one (who ever primes their grenades for 30 turns anyway?). I realize there's no real demand for it, mods like Piratez and X-Com Files just do their own thing anyway, but that's just my take on it.
-
That makes me think of the OXC grenade setting where you have to choose to either have explode-on-impact grenades or explode-at-end-of-turn grenades. It seems to me these behaviors could be integrated by adding a -1 timer to the prime setting and moving all the rest up one (who ever primes their grenades for 30 turns anyway?). I realize there's no real demand for it, mods like Piratez and X-Com Files just do their own thing anyway, but that's just my take on it.
This already work this way, you can choose between instant grenades, normal grenades or fix time grenades. Problem is with flares and proxi grenades when they are on and when off. Another thing is that I prefer do not add lot of new logic or states. Right now flares and proxi are enabled when timer is up and removed when it run out (in same moment when grenade would explode).
-
Thanks for the continued effort on your part, Yankes. The world is watching you. :)
Any estimation on the next release date? I would like to adjust my timeframe with OXCE development cycle.
-
3.10 with merge and some fix (like this grenades) is planed this weekend.
4.0 with lot of big features still is without ETA.
-
3.10 with merge and some fix (like this grenades) is planed this weekend.
4.0 with lot of big features still is without ETA.
Thanks! Can't wait!
-
I had delay in my work, I couldn't decide how new flares functionality should work exactly.
Right now decision was to add new config that will change moment of triggering of flare.
For now only value now supported will be throw e.g. proxy, grenade or flare will be enabled only when throw (can work without prime).
-
New version 3.10 is finally ready.
Bug fix.
Update nightly.
New grenade fuse config.
rule changes diff: https://github.com/Yankes/OpenXcom/commit/8f8ea26bee7377c566546465d21d1d11a3a536e9#diff-fe0874bb03e6a00382c8b351288b4249
-
Hi Yankes,
Like every single time, I have no idea how to use the new feature.
fuseType: -2 #set how prime granade works.
# -3 -> no priming, flare always work.
# -2 -> can prime, unlimited time. Granade explode instantly after throw. Flare work only after prime.
# -1 -> can prime, can set time. Granade explode after set time. Flare and Proxy disappere after set time.
# 0 -> can prime, set fixed time of 0 turns.
# 1 -> can prime, set fixed time of 1 turns.
@ (...)
fuseTriggerEvents:
defaultBehavior: true #used to enable default fuse behavior. Defualt `true`.
throwTrigger: false #timer start on throw.
throwExplode: false #item explode (grenade) or is removed on thorw. Defualt `false`. `specialChance` affect this.
proximityTrigger: false #timer start when unit move in it proximity. Defulat `false`.
proximityExplode: false #item explode (grenade, proxi) or is removed when unit move in it porximity. Default `false`. `specialChance` affect this.
So if I want a flare that starts shining on impact (after throw), but requires no timer, what should I do?
Also, what does defaultBehavior do? What if we set it to false?
-
Ok, I see i miss combination of not-primeable flares and enabling glow on throw. I will fix it in bug-fix release.
`defaultBehavior` is for disabling normal all behavior of priming, used if you want only one specific behavior configured by rest of properties.
if set `false` then nothing will work except thing that you set manually.
Right now closed thing to enable only after throw is prime & throw to glow, eg:
fuseType: -2
fuseTriggerEvents:
defaultBehavior: false
throwTrigger: true
now flare will start "counting" on throw, because `-2` mean unlimited time, it will stay that way infinity.
-
Ok, I see i miss combination of not-primeable flares and enabling glow on throw. I will fix it in bug-fix release.
Ah, that would explain things. :P
Your solution looks good though, I tested it. But is it possible to change prime cost in TUs? I'd like the flares to prime faster than grenades.
-
This is already done, you can even change name of this action and message.
-
This is already done, you can even change name of this action and message.
Thanks, I didn't expect that!
EDIT: Could you please post code for the same, but when the activated flare disappears after 5 turns? Is it even possible for flares, or you can't have both this and the timer?
-
fuseTriggerEvents:
throwTrigger: true
fuseType: 5
I added new property and even split to multiple sub properties to have multiple possible combinations for flare & proxi & grenade
btw grenade can work as proxi now if you use
fuseTriggerEvents:
proximityExplode: true
-
OK, thanks! I'll play with it when it trickles down to OXCE+.
-
Hello again.
I miss maybe two monts of updatess and discussions, so ask now.
Yankes, there was a bug in the script about force shield integrated into armor, which makes shield absorb only one hit per turn. I changed this and that in script file and bug was removed. Did you found it at this time or should i upload my version?
-
Hello again.
I miss maybe two monts of updatess and discussions, so ask now.
Yankes, there was a bug in the script about force shield integrated into armor, which makes shield absorb only one hit per turn. I changed this and that in script file and bug was removed. Did you found it at this time or should i upload my version?
This bug wasn't part of Yankes' code at all, the script was my writing. A fixed version is available as part of my larger script file, here on github (https://github.com/ohartenstein23/Yankes-Scripting/blob/master/Yankes_Scripts.rul).
-
Oh, great. Thanks.
One small question: is it possible to set blinking of shield on hit longer?
-
Yes, it should just be changing all instances of this line
unit.setTag Tag.UNIT_RECOLOR_FRAME_LENGTH 3;
to have a number larger than 3.
-
Great again. Thank you.
-
Hey Yankes, I think the new grenade code you wrote might have broken proximity grenade triggering - the mine will trigger properly when a unit enters its radius, but will not explode. I'm attaching a save where there's a primed proximity grenade in the equipment pile of the skyranger, but when you move any of the soldiers down the ramp, it simply disappears without exploding.
Edit: I think I see the issue - at line 2376 of BattlescapeGame.cpp (https://github.com/Yankes/OpenXcom/blob/8f8ea26bee7377c566546465d21d1d11a3a536e9/src/Battlescape/BattlescapeGame.cpp#L2376), the check for whether the item explodes checks if the item has the battleType for both proximity grenades and regular grenades, instead of one or the other. Since no item can have both battleTypes, the item is simply removed from the game. I think just changing this AND to an OR should fix it.
-
indeed, that was mistype
-
I found another spot in BattlescapeGame that has the mistyped AND instead of OR - https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/BattlescapeGame.cpp#L1838
-
"not and not" is ok
-
Ah sorry, my mistake. Didn't catch the NOTs.
-
@Yankes:
Forwarding a bug report I got from karadoc twice already... I think it is probably caused by OXCE (and the fact that ammo has no slot, unlike in vanilla).
Can you please have a look?
I am attaching a picture with how to reproduce without mods.
And here's original bugreports from karadoc
1. "equipment templates don't always copy the correct loaded ammo.
I'm not sure what the cause is yet. Maybe it isn't even checking the loaded ammo at all...
eg. if I load up a soldier with rubber shotgun ammo, then copy the template and apply it to another soldier; I tend to get ordinary shotgun shells instead of rubber ones.
But if I manually load up the rubber ammo, then apply the template again, it stays as rubber."
2. "Re-reporting a bug which has existed for awhile: copying soldier item templates does not always copy the correct loaded ammo.
In particular, if I use a template to copy shotguns loaded with rubber bullets, I end up with shotguns with ordinary shells -
unless the soldier is already holding a gun with the correct ammo in the first place."
-
Hey Yankes, have you had a chance to review fixing ammo recovery from fixed weapons on soldier armor? I wrote a commit (https://github.com/ohartenstein23/OpenXcom/commit/f12e31736c92daa0d6090b97d03538a90e2cf44a) to fix losing ammo loaded into fixed weapons - would this work without breaking other things?
For background, we reported this problem here (https://openxcom.org/forum/index.php/topic,2915.msg87448.html#msg87448).
-
@Meridian I will check it
@ohartenstein23 if I recall correctly I have some issues with this, because it will start recovering fixed ammo too (ammo that was defined in armor to fill weapons).
Now if Piretez and XFiles or other mods use ammo like that then they will need change how they use it. If they do not then probaby we can apply this patch
-
I talked to Dioxine, and he doesn't have any ammunition as built-in items on armor, and I know that X-Com Files doesn't use this. The commit also checks to make sure the clip item is not fixed and is recoverable, so that should prevent bugs with extra clips being recovered when they shouldn't be.
-
Merge Change Notification:
isRecoverable should be moved from Geoscape item to BattleScape item, because how now work in OXC.
--- posts merged ---
@Yankes:
Forwarding a bug report I got from karadoc twice already... I think it is probably caused by OXCE (and the fact that ammo has no slot, unlike in vanilla).
Can you please have a look?
I am attaching a picture with how to reproduce without mods.
Found and fixed. One check use invalid iterator instead of pointer.
Probably today or tomorrow I will release bugfix version.
-
New bug fix release 3.10a ready. It is up to date with nightly.
-
New bug fix release 3.10a ready. It is up to date with nightly.
Thanks.
OXCE+ is updated too.
2 questions:
1. https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/ProjectileFlyBState.cpp#L584
What does this mean? What exactly is not working yet?
2. https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/ProjectileFlyBState.cpp#L596
Why would a check for (_projectileImpact == 4) be necessary?
Also, I have activated this nerfing in OXCE+ too, for all experience variables: https://github.com/MeridianOXC/OpenXcom/commit/bbbd0c529fbb3863d16197cafa25f3d9545a52fc
-
First commented because https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/ProjectileFlyBState.cpp#L537 Already disable this in OXCE
And I dislike current solution that look for me as hack not proper solution, when I will have time to refactor this (move this to explosion state) I will enable this again.
This second point is probably garbage, in old version was test for `if (_projectileImpact == 4)` that current look like `if (_projectileImpact == V_UNIT)` and some code was move around. Probably during merge I left this as comment for myself to check for some changes and do not remove it after I finished merge.
Your nerf code look better than vanilla one but did you not allow +2 for some cases?
btw update you profile description :>
-
Your nerf code look better than vanilla one but did you not allow +2 for some cases?
Yes, it allows for +2 when many bullets hit and don't kill... I actually like that too... if you're punished by useless shotgun with no damage, you should at least get exp from that ;)
This is the description I gave on discord, hopefully accurate.
Meridian - Yesterday at 5:11 PM
more details about the shotgun experience:
1. "first" bullet is generated, but not used yet
2. current experience is remembered
3. extra bullets are generated and processed one by one... experience for each bullet is awarded normally
4. after all extra bullets are processed, any experience gained is nerfed to 1
5. first bullet is processed... if it hits (and target is still alive) experience is awarded normally
...
meaning standard shotgun, which hits all bullets will award:
- 2 firing experience if the unit stays alive
- 1 firing experince if the unit dies before the "first" bullet is processed ("first" is actually last for all our intents and purposes)
btw update you profile description :>
Done :)
-
@Yankes: a question... I found one difference between OXC and OXCE, see attached picture
The difference would cause different radius for a HE weapon with low damage (e.g. Heavy cannon HE rounds)... either by defining fixed low damage or by damage reduction over distance.
In OXC the radius would be 0 (zero) and in OXCE the radius would be 1 (one).
This will then have effect on various places to determine if the damage is AOE or not... and other side effects...
Is this a feature or a bug?
-
Feature, I made clear cut between single target and aoe damage. This will return same answer as `RuleDamageType::isDirect`.
-
Found a small visual bug with multiple ammo (both on 3.9 and 3.10)
1/ Use this mod:
items:
- type: STR_RIFLE
confAimed:
ammoSlot: 1
confSnap:
ammoSlot: 2
confAuto:
ammoSlot: 3
ammo:
0:
compatibleAmmo: [ STR_RIFLE_CLIP ]
1:
compatibleAmmo: [ STR_HC_HE_AMMO ]
2:
compatibleAmmo: [ STR_AC_I_AMMO ]
3:
compatibleAmmo: [ STR_SMALL_ROCKET ]
2/ Go to New Battle GUI and equip:
1x STR_RIFLE
1x STR_RIFLE_CLIP
1x STR_HC_HE_AMMO
1x STR_AC_I_AMMO
1x STR_SMALL_ROCKET
3/ Now take the weapon in your imaginary hand (left click) and you will see the loaded ammo... all 4 of them, changing regularly with a frequency of about 1 second.
4/ Then, unload the first clip (STR_RIFLE_CLIP), three clips will remain in the gun... however only 2 of them are visible and the change frequency is not regular... about 75% of the time we see STR_HC_HE_AMMO, 25% of the time we see STR_AC_I_AMMO and we don't see STR_SMALL_ROCKET at all.
-
Hi Yankes, there is an issue with armor "calculation", reported here: https://openxcom.org/forum/index.php/topic,5957.msg91692.html#msg91692
Issue is here: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/BattleUnit.cpp#L1241
(the upper boundary is not multiplied by the difficulty coeficient)
Maybe instead of:
setValueMax(_currentArmor[side], - std::get<toArmor>(args.data), 0, _armor->getArmor(side));
it should be:
setValueMax(_currentArmor[side], - std::get<toArmor>(args.data), 0, _maxArmor[side]);
Or some other solution...?
PS: proposed fix: https://github.com/MeridianOXC/OpenXcom/commit/fa91ce19a19fb5a6a7aced035911fdc06ef8bcbc
-
Hi, me again,
looks like this fix was never merged into OXCE: https://github.com/SupSuper/OpenXcom/commit/eaf884863bb21718b2a7b526962c9b241e0ec7f0
It causes NPE when people mod their own globe markers.
Something like this:
extraSprites:
- type: GlobeMarkers
width: 3
height: 3
files:
9: Resources/AbandonedBaseMarker.png
10: Resources/ShipwreckMarker.png
Here's my temporary fix, but I think we need something nicer, could you have a look pls?
https://github.com/MeridianOXC/OpenXcom/commit/682da0775f522ed73d9b0d77319cdd0700d312ca
-
Thanks for reports, last one probably should be fixed in `drawTarget` by replacing `blit` with function that will flip bits when draw.
This will allow adding `const` to `Surface *` because modifying this surface is not needed there (this is design error to require to modyfing shared data do draw anything). I will prepare some fix for this.
As you post some erros to fix, I will grab them and when I find some time publish new bugfix version.
-
Not a major glitch but a wee bit annoying, in the save attached I've mc'd the snakeman leader but it won't let me set waypoints to fire his blaster launcher?
-
Not a major glitch but a wee bit annoying, in the save attached I've mc'd the snakeman leader but it won't let me set waypoints to fire his blaster launcher?
It's because aliens are not allowed to use explosives before turn 3 :)
Small refactoring oversight, that can be easily fixed.
Here's the code: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/SavedBattleGame.cpp#L890
This
if (unit->getOriginalFaction() == FACTION_HOSTILE && getTurn() < rule->getAIUseDelay(getMod()))
should be changed to this
if (unit->getFaction() == FACTION_HOSTILE && getTurn() < rule->getAIUseDelay(getMod()))
Fix: https://github.com/MeridianOXC/OpenXcom/commit/68ec0b2b45fd5aa275b3cab3332869901d984b49
-
Testing out your latest oxce+(v3.10a of 06/01/18) I get this image when a ufo has landed. I have got the language as en-US. Is this right? The ufo in question is a supply ship for alien base 1.
-
Testing out your latest oxce+(v3.10a of 06/01/18) I get this image when a ufo has landed. I have got the language as en-US. Is this right? The ufo in question is a supply ship for alien base 1.
There is a translation for this: https://github.com/MeridianOXC/OpenXcom/commit/3d80cbec3a5614326a0d911baa9382f2fb82afc1
You probably forgot to update the data files.
Updating only the EXE is not enough.
-
Hey Yankes, would you consider removing the validation checks on item costs for facilities here (https://github.com/ohartenstein23/OpenXcom/blob/oxce3.5-plus-proto/src/Mod/RuleBaseFacility.cpp#L123)? I feel like this is unnecessarily limiting modders and assuming only one type of facility refund. For example, in my mod I have a non-functional hangar in a starting base containing a crashed craft; I'd like to be able to remove it to gain back the damaged craft for repairs, but I found it non-intuitive that I needed to be the damaged craft as a build cost before the refund would work.
Edit: Meridian just wrote a commit to change this, if you'd like to use it (https://github.com/MeridianOXC/OpenXcom/commit/08384009518626a8c1ff1514bc02cf8e2e172044).
-
Ok, valid point. It could work other way, but build using X but as refund you get trash Y.
I will include this in next version.
-
bug in documentation, both UFO and XCrafts can modify `sightRange`, all things defined in `craftWeapons`->`stats` can be used in craft and ufo too (but some are not used).
E ... Ie, if set "sightRange" for a UFO, then can increase the distance and the probability of finding X-COM base?
-
Range yes, chance no.
-
Range yes, chance no.
Can find out what is the default range? Is it the same for all UFOs? Maybe should enter this information in the "Readme"?
-
Can find out what is the default range? Is it the same for all UFOs? Maybe should enter this information in the "Readme"?
It's the same as in vanilla, no need for readme if there's no change...
-
Hi Yankes, after having a discussion with Hobbes about using craft weapon stat bonuses to create external fuel tanks, I came to the realization that removing such an item when the craft is fully fueled, you will lose that extra fuel; this means loss of an item if the craft uses E-115 or some other item to refuel. Could this be changed such that extra fuel would be returned as an item, as long as it is equal to at least the refuelRate of the craft?
-
Hi Yankes, after having a discussion with Hobbes about using craft weapon stat bonuses to create external fuel tanks, I came to the realization that removing such an item when the craft is fully fueled, you will lose that extra fuel; this means loss of an item if the craft uses E-115 or some other item to refuel. Could this be changed such that extra fuel would be returned as an item, as long as it is equal to at least the refuelRate of the craft?
There is already code for this:
int overflowFuel = _fuel - _stats.fuelMax;
if (overflowFuel > 0 && !_rules->getRefuelItem().empty())
{
_base->getStorageItems()->addItem(_rules->getRefuelItem(), overflowFuel / _rules->getRefuelRate());
}
setFuel(_fuel);
-
A small bug report... which is not even a bug... but a different side-effect than in vanilla.
When using GIF transparency (on an index different than 0), OXC can still somehow render it transparent, even though it isn't explicitly coded that way.
In OXCE, the "script blit" cannot do that anymore... so mods, which use this "side effect" don't work in OXCE, even though they somehow work in OXC.
The recommendation of course, is to use proper images... but, could you have a look if it would be easy to change the "script blit" to behave the same way?
Attached is a minimod to test it and two screenshots with more explanation.
-
Well that's even terrible for everyone who use OXCE+. Sad news for me. :(
I'll wait for future updates to fix it then, that way transparency problems go away.
Or just don't use gif, use png. Gif has other issues anyway. And if you really want to use gifs, make transparent background transparent instead of green or whatever people use.
-
A small bug report... which is not even a bug... but a different side-effect than in vanilla.
When using GIF transparency (on an index different than 0), OXC can still somehow render it transparent, even though it isn't explicitly coded that way.
In OXCE, the "script blit" cannot do that anymore... so mods, which use this "side effect" don't work in OXCE, even though they somehow work in OXC.
The recommendation of course, is to use proper images... but, could you have a look if it would be easy to change the "script blit" to behave the same way?
Attached is a minimod to test it and two screenshots with more explanation.
One easy way to fix it is add script that will ignore 255 value, in may contexts you have value of background color, and instead of drawing new pixel we will draw background again making this effective transparent.
And for not work around solution, no. SDL can this because It create mapping between src and dest palettes. My blit do only 0 check (except for version that run custom scripts per pixel, but this is only when you ask for this). I would need recreate all SDL logic and with this overhead that it will bring.
-
One easy way to fix it is add script that will ignore 255 value, in may contexts you have value of background color, and instead of drawing new pixel we will draw background again making this effective transparent.
Not worth it.
Each image can have transparent color on a different index.
And converting the image is a nicer, more robust and only official solution anyway.
And for not work around solution, no. SDL can this because It create mapping between src and dest palettes. My blit do only 0 check (except for version that run custom scripts per pixel, but this is only when you ask for this). I would need recreate all SDL logic and with this overhead that it will bring.
That's what I wanted to hear.
Thanks.
Now I can sleep well :)
-
I'm working on the transifex Romanian translation right now. I'm a bit over 50% done :D
-
@Yankes: while doing a "ruleset viewer" I noticed something I don't understand, see attached pictures
Is it intended or just forgotten?
-
`-1` mean "use parent action" for rest of resorces costs. To get correct you should use getter function that replace `-1` with correct value.
-
`-1` mean "use parent action" for rest of resorces costs. To get correct you should use getter function that replace `-1` with correct value.
But why is Aimed a parent of Auto and Snap?
Doesn't make any sense to me...
-
But why is Aimed a parent of Auto and Snap?
Doesn't make any sense to me...
Idea was that modder usually wanted only tweak TU and rest of "cost" leave same for all "shoot" attacks. Same logic as I did for psi attacks.
-
I have completed the Romanian translation for OpenXCom Extended.
I could not translate this "{N} of us are still fatally wounded" seems it has an issue between different spellings and won't let me provide a translation.
-
I have completed the Romanian translation for OpenXCom Extended.
I could not translate this "{N} of us are still fatally wounded" seems it has an issue between different spellings and won't let me provide a translation.
I do not remember adding use of this string in OXCE, didn't you use OXCE+? If yes then you should post this in Meridian thread.
-
One more observation Yankes:
When a weapon is defined like this:
- type: STR_RIFLE
battleType: 1
compatibleAmmo:
- STR_RIFLE_CLIP
... it gets the default damageType DT_NONE... but its attributes are different compared to the _damageTypes.at(DT_NONE)... i.e. the default templates
The questions are:
- Why did you add those extra rules for DT_NONE in Mod.cpp (see screenshot)?
- Do they serve any specific purpose?
- Are they the same in vanilla?
-
Indeed, my bug, I tried to be more papal than the pope. Probably only correct way is to remove them because now behavior is inconsistent.
-
Indeed, my bug, I tried to be more papal than the pope. Probably only correct way is to remove them because now behavior is inconsistent.
OK, thanks.
Done here: https://github.com/MeridianOXC/OpenXcom/commit/d3dcd52c430095ca9d6ce4488d6d936733243ced
-
This is already done years ago, each item can have it own damage type that behave different. Addition there are 10 more resist types added by Meridian.
-
@Yankes:
should getFlatUse() be used in Ufopedia?
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Ufopaedia/ArticleStateItem.cpp#L104
maybe use getFlatAimed(), getFlatSnap() and getFlatAuto() instead?
-
Yes,
I see you did lot of check lately, what do you work on right now? This is some kind ruleset "dump"?
-
Yes,
Fixed here: https://github.com/MeridianOXC/OpenXcom/commit/c20fbbc170f0bc568bf4c6921edbc8b846bffbb6
I see you did lot of check lately, what do you work on right now? This is some kind ruleset "dump"?
Yes, it's a ufopedia extension for nerds who need to know all numbers... so that the modders don't have to write themselves to death.
-
I do not remember adding use of this string in OXCE, didn't you use OXCE+? If yes then you should post this in Meridian thread.
Is there . I asked in discord they told me is because the string has a correction so I had to translate both the correct and wrong string in order to be approved :)
-
Hi Yankes, I'm having trouble with the multiple ammo slots code - I'd like to be able to have two different ammo slots use the same ammunition type, such that I can simulate having to load two different 'chambers' of a weapon separately. However, whenever I set two slots to use the same ammo type, only one will be loaded unless it has a second compatible ammo type to be loaded in it. For example, in the following code snippet, a player would never be able to fire the aimed shot of the rifle because ammo slot 1 will never be filled with a rifle clip:
items:
- type: STR_RIFLE
ammo:
0:
compatibleAmmo: [STR_RIFLE_CLIP]
1:
compatibleAmmo: [STR_RIFLE_CLIP]
confAimed:
ammoSlot: 1
Is there a way around this?
-
no, this functionality was designed to only work with different ammo types per slot. It will be hard to remove because in multiple of places logic really on this.
-
Hi Yankes,
I'm trying to understand the functionality in the attachment... and I just can't understand it no matter how long I look at it.
How is "damage >= type->SmokeThreshold * 2" equivalent to "type->SmokeThreshold == 0" ??
And why not just use "type->SmokeThreshold == 0" ? Why instead doing multiplication by two and comparing it with damage??
-
Code is ok, comments are special case.
This code cap effect when its lot larger than threshold.
Example:
Damage = 50, Threshold = 100 -> 0% smoke
Damage = 101, Threshold = 100 -> 1% smoke
Damage = 200, Threshold = 100 -> 100% smoke
Damage = 300, Threshold = 100 -> 100% smoke
Damage = 5, Threshold = 0 -> 100% smoke
-
Hi again Yankes,
am I right if I say that methods fireWeapon1() .. fireWeapon4() are not used anywhere and can be removed?
I would "need" to remove them to merge some recent nightly fixes...
https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L1233
-
Hi again Yankes,
am I right if I say that methods fireWeapon1() .. fireWeapon4() are not used anywhere and can be removed?
I would "need" to remove them to merge some recent nightly fixes...
https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L1233
https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L960 (compare with master)
This was use place of this, probably after couple of refactoring I forget remove them.
-
OK, one more "merge" thing... for about a year, the animation of bigger units is broken... I think I found the reason, but I am not sure:
I think that this commit was not merged properly: https://github.com/SupSuper/OpenXcom/commit/5a363721372e3818d56008f2f8be73c1ae86d254
There was an attempt to fix it: https://github.com/Yankes/OpenXcom/commit/64168e2befa7cf249cf9b549405ce5bef05d88f8
But it only fixed it partially.
I think that
getTerrainLevel(westUnit->getPosition(), westUnit->getArmor()->getSize())
needs to be removed completely, because it is (probably) done in
calculateWalkingOffset(westUnit, &offset);
already
Would you agree?
In attachment, you can see the visual manifestation of the issue.
-
Yes, exactly.
-
Hey Yankes, I've noticed that newTurnUnit now runs on civilian 'turns' during terror site missions - was it always this way? This means that scripts I expect to run twice per player turn run three times for terror missions, which ruins any balance that depends on these scripts. Is there any way to get the faction of a unit with createUnit and newTurnUnit? I can use that to determine whether civilian units are on the map and therefore have to change the newTurnUnit logic to match.
Edit: Oh, is this what the purpose of the 'side' variable in newTurnUnit is? It returns a value equal to which side's turn is starting, with 0 = X-Com, 1 = Aliens, 2 = Civilians?
-
Yes. this mean you can run some code only on one side "end turn".
-
People, it may be time to think of something, what would speed up the load \ save? Save file grew to 5 megabytes (half of this volume is occupied by soldiers' statistics) and it loads for a very long time. Need to somehow speed up the load of large files.
5 megabytes! And this is the middle of the game and the end is not even visible with binoculars. That is it is visible, but it more likely the end of an admissible volume of the loaded information from a file of saving. It can be divided him into 2 or 3 parts?
-
You can disable soldier diaries in options.cfg, just set:
soldierDiaries: false
Btw. it's not about the size of the file, splitting it into multiple parts won't help.
-
You can disable soldier diaries in options.cfg, just set:
soldierDiaries: false
We have already discussed this. Without statistics, half the interest in the game is lost.
Btw. it's not about the size of the file, splitting it into multiple parts won't help.
Will help. If all the statistics are moved to a separate file, which is loaded only when the player turns to the statistics. That's why in combat is loaded, all the statistics? In battle, there is a buffer, where all the actions of soldiers are recorded, which can be entered after the battle into the statistics file, instead of loading the whole array of statistics every time, which is not used at all and just increases the time load\save in combat.
-
Ah yes, I remember now... you were the guy with 500 soldiers hired and no losses... not sure why you need statistics, if you don't have any losses :)
Jokes aside, I am not interested in changing how soldier diaries are saved and loaded.... it's a lot of work... and no, your approach still doesn't work.
Btw. the biggest save I have here is 11 MB, and it loads in 4 seconds.
And even if it was more than 4 seconds on older computers... doing it once or twice per hour would not bother me.
Maybe you can find someone else to do it...
EDIT: I tried this 11 MB save on the oldest computer I could find... notebook from 2008 (10 years old)... and it loaded in 11 seconds.
-
Ah yes, I remember now... you were the guy with 500 soldiers hired and no losses... not sure why you need statistics, if you don't have any losses :)
Jokes aside, I am not interested in changing how soldier diaries are saved and loaded.... it's a lot of work... and no, your approach still doesn't work.
Btw. the biggest save I have here is 11 MB, and it loads in 4 seconds.
And even if it was more than 4 seconds on older computers... doing it once or twice per hour would not bother me.
Maybe you can find someone else to do it...
EDIT: I tried this 11 MB save on the oldest computer I could find... notebook from 2008 (10 years old)... and it loaded in 11 seconds.
yup, this more work for Warboy or SupSuper, otherwise OXCE/OXCE+ would need break compatibility with basic version.
-
Ah yes, I remember now... you were the guy with 500 soldiers hired and no losses... not sure why you need statistics, if you don't have any losses :)
Jokes aside, I am not interested in changing how soldier diaries are saved and loaded.... it's a lot of work... and no, your approach still doesn't work.
Btw. the biggest save I have here is 11 MB, and it loads in 4 seconds.
And even if it was more than 4 seconds on older computers... doing it once or twice per hour would not bother me.
Maybe you can find someone else to do it...
EDIT: I tried this 11 MB save on the oldest computer I could find... notebook from 2008 (10 years old)... and it loaded in 11 seconds.
Either you have a monstrously powerful computer, or because of XP, I have such a delay. The load time of the 5 megabyte save file in combat is 1 minute 30 seconds. 11 megabytes I probably would have loaded 3-4 minutes. My computer is not weaker than a hamster, he and Perfect World and World of Tanks pulls without problems. Strange situation.
-
Either you have a monstrously powerful computer, or because of XP, I have such a delay. The load time of the 5 megabyte save file in combat is 1 minute 30 seconds. 11 megabytes I probably would have loaded 3-4 minutes. My computer is not weaker than a hamster, he and Perfect World and World of Tanks pulls without problems. Strange situation.
That's not normal.
1/ Are you using the official executable or are you compiling your own? If you compile your own, make sure it is compiled in "Release mode", not in "Debug mode"... debug mode is 10-20x slower.
2/ Do you have antivirus running? If yes, try turning it off completely, and see if it helps... if yes, install a different antivirus software... Solarius had the same issue recently, and he also got significant improvement (from minutes to seconds).
PS: I tried it on Lenovo R500 notebook... average model from 2008, Intel Core 2 Duo 2 GHz, 3 GB RAM, slow classic HDD (=no SDD), Windows 7
-
That's not normal.
1/ Are you using the official executable or are you compiling your own? If you compile your own, make sure it is compiled in "Release mode", not in "Debug mode"... debug mode is 10-20x slower.
2/ Do you have antivirus running? If yes, try turning it off completely, and see if it helps... if yes, install a different antivirus software... Solarius had the same issue recently, and he also got significant improvement (from minutes to seconds).
I do not know which version of the test, and which is not. I have installed OXE + 3.10a 2018-02-24. I myself have not changed anything there.
Disabling the antivirus did not help much. Loaded only a couple of seconds faster.
Apparently it is in the overflow of the statistics of soldiers. For 400 soldiers, there are 164 missions, 6,119 killed and 86 captured aliens in the twelfth month.
P.S. Disabling statistics, of course, solves the problem, but ... it's like Ufoedia without images.
-
Upload the save here, I will try later how fast it loads for me...
-
Upload the save here, I will try later how fast it loads for me...
It's done. But to check it it is necessary also my mod to download. https://openxcom.org/forum/index.php/topic,5724.0.html
-
It's done. But to check it it is necessary also my mod to download. https://openxcom.org/forum/index.php/topic,5724.0.html
It loads in 3 seconds on my current computer.
I will try also on the old computer later when I'm back home (on Thursday). But I don't expect it will be more than 10 seconds.
PS: btw. why didn't you create a normal mod? Why putting everything into /standard/xcom1 ? that's very unfortunate...
-
It took about 5 seconds to load the save on my 10 years old PC. The mod was extracted to an old and quite slow HDD with a highly fragmented file system. The in-game journal can also be viewed without any problems.
-
Understandably. I will be helped only by switching to a new hardware with a new operating system. Thanks for the help.
PS: btw. why didn't you create a normal mod? Why putting everything into /standard/xcom1 ? that's very unfortunate...
Because all this construction is incompatible with other mods anyway. Whether it's a separate mod, or base - it does not matter.
-
Because all this construction is incompatible with other mods anyway. Whether it's a separate mod, or base - it does not matter.
Well it matters to you, as you'll have a lot of work every time you update OXC ;)
-
Just a reminder for two fixes mentioned earlier and not yet merged (afaik):
https://github.com/MeridianOXC/OpenXcom/commit/d3dcd52c430095ca9d6ce4488d6d936733243ced
https://github.com/MeridianOXC/OpenXcom/commit/c20fbbc170f0bc568bf4c6921edbc8b846bffbb6
-
I'm not done yet :> I probably before release scan this thread again and look for bugs I missed or forget.
-
small bugfix: craft stats need to be refreshed after loading OG saves via saveconverter
PS: I didn't add weapon stats since OG doesn't have any, but feel free to add them if you want
-
bugreport: unit.getStunMax returns "current health" instead of "max heath * 4"
https://github.com/Yankes/OpenXcom/blob/stash/workInProgress/src/Savegame/BattleUnit.cpp#L4236
EDIT: in the meantime could you tell me how to fix it on my branch? I don't understand much of it... questions attached
-
Right my bad, I forget that I add limit on this in damage function, probably this will need small refactor to not coping multiple times `health * 4`.
For now commit for cherry-pick: https://github.com/Yankes/OpenXcom/commit/f0495bf10e03cf37096254dfacc01eae1a8eac63
-
I that "maxStun = 0;" correct?
https://github.com/Yankes/OpenXcom/commit/f0495bf10e03cf37096254dfacc01eae1a8eac63#diff-a19679ce5a8ec8fcb81157507368cd4eR3962
-
I that "maxStun = 0;" correct?
https://github.com/Yankes/OpenXcom/commit/f0495bf10e03cf37096254dfacc01eae1a8eac63#diff-a19679ce5a8ec8fcb81157507368cd4eR3962
Fast fix aren't fixes, yup I overwrite correct value by this, it should be in `else`.
-
bugreport: "skillApplied" on items is not considered
https://github.com/Yankes/OpenXcom/blob/stash/workInProgress/src/Mod/RuleItem.cpp#L444
if (node["skillApplied"].as<int>(false))
should be
if (node["skillApplied"].as<bool>(false))
-
yup
-
3.0:
Backported game machanic changes from Meridian OXCE+.
Well, that's pretty darn confusing.
Does that mean all of the OXCE+ mechanics? Some of them? If not all, which ones? Does this not muddy the waters between OXCE and OXCE+, making the distinction less apparent?
Mind clarifying for me?
-
Well, that's pretty darn confusing.
Does that mean all of the OXCE+ mechanics? Some of them? If not all, which ones? Does this not muddy the waters between OXCE and OXCE+, making the distinction less apparent?
Mind clarifying for me?
It means "some".
There is no clarification possible, because there is no masterplan. Whatever Yankes liked, he took into OXCE.
If you need to know exactly what it is... there is no easier way than to read the whole commit history in git.
-
It means "some".
There is no clarification possible, because there is no masterplan. Whatever Yankes liked, he took into OXCE.
If you need to know exactly what it is... there is no easier way than to read the whole commit history in git.
yup,
@Mechasaurian problem is I have bit different goals than Meridian, I prefer extensions that do not change UI if possible.
Meridian add lot of QoL changes and UI improvements.
Looking at current state of affairs you could consider my OXCE as "lite" version of OXCE+
-
Bugreport: units on fire render bug when aiming, see screenshot
https://github.com/Yankes/OpenXcom/blob/stash/workInProgress/src/Battlescape/UnitSprite.cpp#L222
https://github.com/Yankes/OpenXcom/blob/stash/workInProgress/src/Battlescape/UnitSprite.cpp#L272
Might also apply to bubbles which were moved there recently too... I didn't test the bubbles yet
-
Right, this is because original version move sprites around (bigger temporal surface for aiming), to not rewriting all code I added this hack (`_x -= 16`) probably correct long term solution will be remove this hack and aiming adjustment from vanilla code.
-
Hi Yankes, ever since you wrote the code for picking ammo slots by action type, I felt it was missing a configuration option for arcing shot or not by action type, so I wrote a commit to add the option to set arcing: true by shot type (https://github.com/ohartenstein23/OpenXcom/commit/2d403297b97045c0a70f8d76c0d36a793328e095). Could you review this and consider including it in OXCE? Thanks!
Also, I found a discrepancy between OXCE and OXC regarding AI unit melee charges - here you use getSpecialWeapon(BT_MELEE) (https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/UnitWalkBState.cpp#L471), while in the same place OXC uses getMeleeWeapon() (https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/UnitWalkBState.cpp#L502), which is closer to getUtilityWeapon(BT_MELEE) in OXCE. As a result, AI units that are charging fail to attack at the end of walking up to a player unit unless they have a meleeWeapon on their unit definition, even though they decided to charge since they have a melee item instead.
-
For your commit, I think better would be if you use something like `(_action.weapon->getActionConf(_action.type) && _action.weapon->getActionConf(_action.type)->arcing)`, it will be more future proof.
For diffrence in in AI, you are correct, in `AIModule::think` the `getUtilityWeapon` is use, this mean OXCE is inconsistent. Correct fix is use `getUtilityWeapon`.
-
Would you like me to amend the commit for the arcing shot configuration and send a new link?
Do you want a commit for the melee attack fix?
-
Yes for both, btw in `awardExperience` we have too arcing test, probably would be good add this new functionality there too.
-
Here's the commit for the changes to arcing shots (https://github.com/ohartenstein23/OpenXcom/commit/1998bc16a894e71b8602f752994b179df2e80c09), I updated the check in ProjectileFlyBState and in AIModule (might be OXCE+ only), but I can't include this check in TileEngine::awardExperience, as the action type is not passed to the function.
Here's the fix for AI melee attacks at the end of a charge (https://github.com/ohartenstein23/OpenXcom/commit/e31f13d7f578afaa3f3369156a675c0b13ad9a0a).
-
If i want the melee weapon to inflict base (before 0-200%) damage == current hit points:
power: 0
meleeMultiplier:
healthCurrent: 1.0
or
power: 0
damageBonus:
healthCurrent: 1.0
?
-
it's damageBonus
(meleeMultiplier affects accuracy)
-
Thanks!
-
help with math
i'd like to define a weapon that inflicts a lot of fatal wounds (and lesser normal damage), and i thought about this as an example:
power: 50
damageAlter:
ToHealth: 0.5
ToWound: 3.0
so, let say the shot deals perfectly average damage = 50 dmg
50 - 30 from an hypothetical armor = 20
20 * ToHealth = 10 final effective damage to the unit
since the final damage >= 10, then --> 3 to 9 points of fatal wounds (1 to 3 * ToWound)
right?
Thanks
p.s. do i also need to explicitly add RandomWound: false for ToWound to work?
-
`RandomWound`:
`true` <- mean normal 1-3 wounds calculated like on ufopaedia (more`ToWound` increases only probability)
`false` <- mean `round(damageThatPassArmor*ToWound)`
And one imporat difference "finall damge" is `(reststs*damage) - armor`, `ToHealth` and `ToWound` are independent, you can do 0 to health but still bleed unit out.
-
`false` <- mean `round(damageThatPassArmor*ToWound)`
so 10 damage with "ToWound: 3.0" would inflict 30 points of fatal wounds?
-
Yes, but if you want you can drop script that will overwrite it in any way you want.
-
powerRangeReduction: 0.1
Does that means the "power" is reduced by 10% each tile after "powerRangeThreshold" ?
-
Not by 10%, but by a flat 0.1, or 1 power every 10 tiles.
-
Not by 10%, but by a flat 0.1, or 1 power every 10 tiles.
thanks!
-
Hi, Yankes, maybe you are interested in this proposal?
https://openxcom.org/forum/index.php/topic,4187.msg98086.html#msg98086
The translator creaked and smoked, but I'm still not sure that everything has been translated correctly.
-
I usually do not do UI Improvements. Another this I have already long TODO list, and not enough time to finish all thing I want to do.
-
Bugreport, in terrain damage calculation: https://openxcom.org/forum/index.php/topic,4187.msg98377.html#msg98377
-
Side effect of unification of damage handling. Probably ohartenstein23 suggestion to reduce default values will work, not same but usually indistinguishable.
-
Side effect of unification of damage handling. Probably ohartenstein23 suggestion to reduce default values will work, not same but usually indistinguishable.
Fix and new option to use OXC or OXCE method: https://github.com/MeridianOXC/OpenXcom/commit/c0219ef9c78fde1ceb28e86371b8614687b35186
-
any chance of vanilla merge in the near future? it's been half a year...
-
I will try do this in this or next month. Right now I fight with corner cases in craft allocation :)
-
I will try do this in this or next month. Right now I fight with corner cases in craft allocation :)
OK.
Btw. your move order PR was merged into vanilla... I can't cherry-pick it to OXCE+... OXC and OXCE are too different and I have no idea how to resolve all those conflicts.
-
Btw. your move order PR was merged into vanilla... I can't cherry-pick it to OXCE+... OXC and OXCE are too different and I have no idea how to resolve all those conflicts.
Because in reality I implemented this two times, once for OXC and once for OXCE, this is merge that do this: https://github.com/Yankes/OpenXcom/commit/de685a17760a568992ab4583a6c2673bd8b62f74
Overall its still in WIP branch and will be released with 4.0
-
Bugreport: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/MissionSite.cpp#L66
_missionCustomDeploy is saved, but never loaded
-
-- post double wrong --
We load `missionSites` and `terrorSites`, one load and another not load this `missionCustomDeploy`. This is correct because one is for backward compatibility.
-
Are you getting progress with the next version, Yankes?
We're really far from the vanilla now, which makes me kinda uncomfortable. ;)
-
Are you getting progress with the next version, Yankes?
We're really far from the vanilla now, which makes me kinda uncomfortable. ;)
Real men can live with uncomfortable things :D
As for more serious answer. right now I'm working on this (merge with vanilla). This force me to scrap two features (craft/hangar types and weapon use scripts, two culprits why it take so much time) other wise it would take maybe another month to release this.
-
Real men can live with uncomfortable things :D
Yep, I already hit it with a rock, strangled it, skewered it and roasted it over a volcano. ;)
As for more serious answer. right now I'm working on this (merge with vanilla). This force me to scrap two features (craft/hangar types and weapon use scripts, two culprits why it take so much time) other wise it would take maybe another month to release this.
The craft/hangar types is a very cool feature which I would love to see, but from my perspective it's not urgent, and I don't know of any mod which would depend on it heavily.
-
We're really far from the vanilla now, which makes me kinda uncomfortable. ;)
Extended/Extended+ is the new vanilla.
-
Extended/Extended+ is the new vanilla.
This is not valid point, vanilla is still developed and bugfixed and this changes are still useful for OXCE/OXCE+.
-
New version 4.0 us up:
Damage script can now alter zombie transformation chance.
Add access to current difficulty level in scripts.
Add base function requirmets to buy items, crafts and solders.
Add access to geoscape soldier in scripts.
Add script that is run at end of mission.
Add arcing shoots per attack type (by ohartenstein23).
Breaking change: Renamed `action` to `battle_action` in reaction scripts.
Add battle action to `awardExperience` script.
Breaking change: Renamed access function to statis in armor (added prefix `Stats.`).
Custom hangar types and script on item will be available in next version (4.1 or 4.2) probably with script run on item equip.
In this version probably most important change is that script now can escape one battlescape and transfer state between battles.
As side effect you now can override how much wound days unit will have, image that only thinking about on some eldar gods you will need take some weeks for off. Another is your super duper solder will not take year to heal half of his hp.
-
Okay, I give up. How the hell do I install this?
-
Another is your super duper solder will not take year to heal half of his hp.
As far as I know, many years of healing and so were defeated.
sickBayAbsoluteBonus: 10.0
sickBayRelativeBonus: 10.0
Or similar settings with this update will lose relevance?
-
Okay, I give up. How the hell do I install this?
Download it? (link to mediafire is in first post). This is replacement for recent nightly. If you have already installed new nighlty you can drop my exe in folder where nightly have its own exe.
Alternate grab `Data400.zip` from first post in this thread and extract it to folder where you have downloaded my exe.
As far as I know, many years of healing and so were defeated.
sickBayAbsoluteBonus: 10.0
sickBayRelativeBonus: 10.0
Or similar settings with this update will lose relevance?
Biggest difference is that you can assign arbitrary value to healing time. If solder is robot, it will not need any time to heal.
-
Biggest difference is that you can assign arbitrary value to healing time. If solder is robot, it will not need any time to heal.
Understood. Thank you very much. For my mod is extremely useful.
-
If solder is robot, it will not need any time to heal.
This is already available in OXCE+ as a tag on armor to determine whether or not a unit takes any wound time:
armors:
- type: STR_ROBOT_ARMOR
instantWoundRecovery: true
However, the script will be useful for reducing wound time on units used as HP tanks.
-
This is already available in OXCE+ as a tag on armor to determine whether or not a unit takes any wound time:
armors:
- type: STR_ROBOT_ARMOR
instantWoundRecovery: true
However, the script will be useful for reducing wound time on units used as HP tanks.
Exactly, scripts are for "custom" behaviors, like now wounds could count to recovery days or even heal up damage still counts.
You could make that for some armor only some type of damage do pernamet damage.
But this only "side effect" of changes I add, you can made that solder after each kill of some specific alien will grain 1 dmg bonus against same type in next battle.
Or after 10 missions it will take break for week (right now indistinguishable from "wounds" but in future I will add option to change this).
-
New version 4.0 us up:
I installed the latest OXCE+, but game keeps telling me, that it is version 3.10b. Have I done somethring wrong?
-
I installed the latest OXCE+, but game keeps telling me, that it is version 3.10b. Have I done somethring wrong?
Yankes released version 4.0 of OXCE. Meridian's OXCE+ is currently in version 3.10b.
-
CTD when moving items in the inventory (when opened from the craft equipment screen in the basescape).
Please hotfix.
-
Any more bugs or things to change? Only this, did you find?
-
Fixed version ready: https://github.com/Yankes/OpenXcom/commits/OpenXcomExtended
-
Any more bugs or things to change? Only this, did you find?
I found a few small things, but I'm not finished merging yet, hopefully by the end of this week I can give more feedback.
Fixed version ready: https://github.com/Yankes/OpenXcom/commits/OpenXcomExtended
Thx.
-
So, I am more or less finished with merging.
So far, I didn't get any new crashes after clicking through the game for about 2-3 hours.
I found a few things:
1/ it's not possible to manufacture both craft and items in the same project anymore... but I checked a few mods and it is not used anymore as far as I can say... so OK for me
2/ there is an unused Base parameter here: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Transfer.h#L67
(not sure if implementation is missing or parameter is not needed)
3/ there is probably a merge typo here?: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Geoscape/DogfightState.cpp#L1098
Vanilla has
newMission->start(newMission->getRules().getWave(0).spawnTimer); // fixed delay for first scout
OXCE has
newMission->start(mission->getRules().getWave(0).spawnTimer); // fixed delay for first scout
[/code]
4/ DEBUG mode in Ufopedia doesn't show all articles anymore
-
1/ I recall place in code that previously prevent adding items if it build craft. This mean if I'm right you could not use it correctly before.
This line: https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/Production.cpp#L133
2/ Right now not used, It will be used when I add hangars types (side effect of rebase that remove it from this release).
3/ Right, typo.
4/ I do not recall changing any thing that could affect this. This could be missmerge or change from nightly. I will look on this too.
Thanks for your findings :)
-
4/ I do not recall changing any thing that could affect this. This could be missmerge or change from nightly. I will look on this too.
Looks like a forgotten parameter after refactoring.
Here's a fix: https://github.com/MeridianOXC/OpenXcom/commit/e19f743eacff1871d5bd5dd02da0ae09d0699582
5/ And one more, "requiresBuy" in RuleItem didn't work at all, here's a fix: https://github.com/MeridianOXC/OpenXcom/commit/7a2543c1cd0caa5e84a5158973cef8f1f7922f34
-
Thanks for findings
-
Download it? (link to mediafire is in first post). This is replacement for recent nightly. If you have already installed new nighlty you can drop my exe in folder where nightly have its own exe.
...okay, I don't know why, but I can't wrap my head around this. Again, how do I download Open XCom Extended?
-
...okay, I don't know why, but I can't wrap my head around this. Again, how do I download Open XCom Extended?
If you want OXCE, download link is here: https://openxcom.org/forum/index.php/topic,2915.0.html
If you want OXCE+, download link is here: https://openxcom.org/forum/index.php/topic,5258.0.html
-
Just figured I should mention that (finally) nightlies can have stack traces (https://github.com/SupSuper/OpenXcom/commit/86975785a7046ee40c7b39c087dab4dfdbf80a21).
If you wanna integrate it into your MXE builds, you need to add -Wl,--export-all-symbols to your LDFLAGS. (-g is not needed and will just bloat the exe).
-
Thanks for info.
-
List order for research topics is ignored in 4.0... can we have it back?
-
I will look on that.
-
https://github.com/Yankes/OpenXcom/commit/5fb565cd9d7b31978b4a152a38b55cd389b1ffb0
Order fix. Reason of this bug is because I change source to `mod->getResearchMap()` in `getAvailableResearchProjects`. As order only matter in this place I fix only there otherwise we will do not needed work in other places.
-
New bug fix version is ready, I added files to first post and mediafire.
-
This thread has been locked, please use the new thread: https://openxcom.org/forum/index.php/topic,6586.0.html