Post by: Yankes on September 07, 2014, 06:50:34 pm
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 :)
Post by: redv on September 07, 2014, 08:25:39 pm
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
Post by: Yankes on September 07, 2014, 09:07:08 pm
Post by: Dioxine on September 07, 2014, 09:21:06 pm
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...
Post by: Solarius Scorch on September 08, 2014, 01:18:53 am
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.
Post by: Yankes on September 08, 2014, 01:37:09 am
Post by: luke83 on September 08, 2014, 01:59:34 pm
Post by: Dave84 on September 08, 2014, 04:01:43 pm
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!
Post by: Solarius Scorch on September 08, 2014, 07:37:50 pm
(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:
Code: [Select]
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).
Post by: Yankes on September 08, 2014, 07:43:06 pm
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)...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).
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...
How much more freedom for Modders... THis much https://openxcom.org/forum/index.php?topic=2743.0 :PTracking 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:Most of things form your list is working, only direct morale change is unimplemented.
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!
Post by: Dave84 on September 08, 2014, 11:00:45 pm
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.
Post by: Dioxine on September 09, 2014, 02:29:11 am
Post by: NeoWorm on September 09, 2014, 10:05:38 am
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.
Post by: pkrcel on September 09, 2014, 10:34:56 am
Quote
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.
Post by: redv on September 09, 2014, 10:44:26 am
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.
Post by: NeoWorm on September 09, 2014, 12:28:35 pm
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.
Post by: pkrcel on September 09, 2014, 02:29:51 pm
Quote
The view distance mod is backward and forward compatible with regular version of OpenXcom.
This is mostly what I was talking about. ;D
Post by: Dioxine on September 09, 2014, 02:34:59 pm
Post by: Yankes on September 09, 2014, 07:12:13 pm
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 :)
Post by: Dioxine on September 10, 2014, 11:44:16 pm
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 :)
Post by: Falko on September 10, 2014, 11:57:40 pm
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*
Post by: Yankes on September 11, 2014, 12:44:10 am
Gratz!I never intended use bool for that, only "strengthApplied" is bool for backward compatibility and new functionality use [0.0, 1.0] scale.
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 :)
Current options:
Code: [Select]
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.Post by: Ran on September 11, 2014, 01:06:54 am
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
Post by: RSSwizard on September 11, 2014, 01:30:10 am
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).
Post by: Dioxine on September 11, 2014, 01:59:07 am
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...?
Post by: arrakis69ct on September 11, 2014, 02:37:26 pm
Enviado desde mi LG-D802 mediante Tapatalk
Post by: Dioxine on September 11, 2014, 04:24:43 pm
@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).
Post by: Dave84 on September 11, 2014, 10:10:39 pm
Post by: Yankes on September 11, 2014, 10:21:24 pm
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.
Post by: Dave84 on September 11, 2014, 10:26:11 pm
Post by: Dave84 on September 11, 2014, 11:17:35 pm
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?
Post by: Yankes on September 12, 2014, 12:29:15 am
Code: [Select]
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.
Post by: Voiddweller on September 13, 2014, 12:29:17 am
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.
Post by: redv on September 13, 2014, 10:57:08 am
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.
Code: [Select]
# 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
Post by: Dave84 on September 13, 2014, 11:54:18 am
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.
Post by: Solarius Scorch on September 13, 2014, 12:44:30 pm
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.
Post by: Yankes on September 13, 2014, 01:32:39 pm
Latest build contain ViewDistance mod. https://www.openxcom.com/mod/openxcom-extendedI altered redv mod that you don't need define default "9" range for solders.
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.Code: [Select]# 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.Every mission, or only one? I would be glad if you send me save from that mission. Meanwhile I will try reproduce it myself.
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.
Post by: Voiddweller on September 13, 2014, 03:15:47 pm
Post by: Yankes on September 13, 2014, 06:03:55 pm
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.
Post by: ivandogovich on September 13, 2014, 06:59:52 pm
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.
Quote
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
Post by: NeoWorm on September 13, 2014, 07:31:27 pm
Otherwise, the increased nightvision for X-Com soldiers seems to work fine.
Post by: Yankes on September 13, 2014, 07:49:56 pm
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.I don't know, redv add this feature and he probably know answer for that.
Otherwise, the increased nightvision for X-Com soldiers seems to work fine.
Post by: NeoWorm on September 13, 2014, 08:10:46 pm
Post by: redv on September 13, 2014, 08:14:00 pm
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".
Post by: NeoWorm on September 13, 2014, 09:20:11 pm
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.
Post by: NeoWorm on September 14, 2014, 01:49:50 am
When I figure out how to post the code to git I will send link there.
Post by: redv on September 14, 2014, 04:01:52 pm
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.
Quote
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.
Post by: NeoWorm on September 14, 2014, 05:02:08 pm
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.
Post by: redv on September 14, 2014, 05:19:06 pm
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.
Post by: Falko on September 14, 2014, 05:41:03 pm
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
Post by: NeoWorm on September 14, 2014, 06:40:13 pm
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.
Post by: redv on September 15, 2014, 11:17:15 am
Default value is 100. For instance, if set:
Code: [Select]
facilities:
- type: STR_HYPER_WAVE_DECODER
radarChance: 50then chance of detection of UFOs will be 50/50 every 30 min.Interesting option will be if set radarChance to 0.
Code: [Select]
facilities:
- type: STR_HYPER_WAVE_DECODER
radarChance: 0In 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:)
Post by: Solarius Scorch on September 15, 2014, 07:42:30 pm
Interesting option will be if set radarChance to 0.Code: [Select]facilities:In this case hyperwave decoder cannot determine position of UFO but can decode an UFOs transmissions.
- type: STR_HYPER_WAVE_DECODER
radarChance: 0
Sorry, please clarify if this is true for the OpenXCom Extended only, or works for vanilla OpenXCom as well?
Post by: Yankes on September 15, 2014, 08:59:29 pm
Post by: redv on September 15, 2014, 09:09:42 pm
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
Post by: pkrcel on September 15, 2014, 09:14:13 pm
I'll try out it in the future
Post by: RSSwizard on September 15, 2014, 11:26:32 pm
Quote
(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.
Post by: Sturm on September 16, 2014, 12:33:09 am
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.
Post by: Yankes on September 16, 2014, 12:51:38 am
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:
Code: [Select]
weapons: 4
weaponTypes: [0, 0, 0, 1] # slot 1 accept weapon with type 0, ... slot 4 accept weapon with type 1
craft weapon:
Code: [Select]
weaponType: 1 #default value 0
My next target will be probably bonus stats in craft weapons.
Post by: Vulgar Monkey on September 16, 2014, 01:50:58 am
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.
Post by: arrakis69ct on September 16, 2014, 12:21:12 pm
And a option to recover countries to council again XD
Enviado desde mi LG-D802 mediante Tapatalk
Post by: Random Commander on September 16, 2014, 12:58:44 pm
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!)
Post by: Dioxine on September 16, 2014, 01:27:20 pm
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 :)
Post by: pkrcel on September 16, 2014, 02:33:09 pm
Of course one woudl have to design a new debrief screen with the soldiers stats embedded.....
Post by: Dave84 on September 16, 2014, 03:43:12 pm
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.
Post by: redv on September 16, 2014, 05:05:48 pm
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.
Post by: KingMob4313 on September 16, 2014, 10:03:48 pm
Post by: Yankes on September 16, 2014, 10:41:12 pm
BTW do you have plan how to fix it?
Post by: Yankes on September 18, 2014, 11:37:31 pm
For now you can change:
Code: [Select]
stats: #stats that are add to crafts stats
fuelMax: 0
damageMax: 0
speedMax: 0
accel: 0
radarRange: 0
radarChance: 0
sightRange: 0
Post by: arrakis69ct on September 19, 2014, 02:31:33 am
May be extra cargo for skiranger??? More soldiers or one more tank XD
Enviado desde mi LG-D802 mediante Tapatalk
Post by: robin on September 19, 2014, 11:05:04 am
New feature, crafts weapon can alter craft stats.this + the 4 slots.. if the goal was an Apocalypse-like customization (for crafts), then you have reached it.
For now you can change:Code: [Select]stats: #stats that are add to crafts stats
fuelMax: 0
damageMax: 0
speedMax: 0
accel: 0
radarRange: 0
radarChance: 0
sightRange: 0
(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.
Post by: Random Commander on September 19, 2014, 02:00:19 pm
(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!
Post by: Yankes on September 19, 2014, 07:01:16 pm
May be extra cargo for skiranger??? More soldiers or one more tank XDThis 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.
Post by: arrakis69ct on September 19, 2014, 11:40:24 pm
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.Ok. Only is a idea. But may be possible others options in future.
Another problem is adding new code that will throwing out stuff from craft when you remove weapon that give out additional solder/tank slot.
Enviado desde mi LG-D802 mediante Tapatalk
Post by: Solarius Scorch on September 20, 2014, 10:19:33 am
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. :)
Post by: Dioxine on September 20, 2014, 10:56:54 am
Post by: Yankes on September 22, 2014, 08:24:00 pm
`fix fixed weapon (should always placed into "hands")` by redv
`Support for fire and smoke for any damage type`
And recent fix form nightly.
Post by: Yankes on September 28, 2014, 03:03:28 am
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:
Code: [Select]
newHitChance = oldHitChance + attacker->hitBonus - target->avoidBonusAdditional 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+).
Post by: Solarius Scorch on September 28, 2014, 08:30:50 am
Post by: Dioxine on September 28, 2014, 09:38:06 am
Post by: redv on September 28, 2014, 11:34:13 am
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".
Post by: Dioxine on September 28, 2014, 11:47:04 am
Post by: redv on September 28, 2014, 12:26:00 pm
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).
Post by: Solarius Scorch on September 28, 2014, 01:32:16 pm
"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.
Post by: redv on September 28, 2014, 03:00:20 pm
Post by: Arthanor on September 28, 2014, 07:45:54 pm
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.
Post by: redv on September 28, 2014, 08:12:49 pm
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.
Quote
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?
Post by: Yankes on September 28, 2014, 08:21:10 pm
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)
Post by: Arthanor on September 28, 2014, 08:30:35 pm
It's wrong.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.
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.
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).
Quote
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..! ;)
Post by: redv on September 28, 2014, 08:56:41 pm
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
Post by: Arthanor on September 28, 2014, 09:17:50 pm
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?
Post by: Dioxine on September 28, 2014, 09:22:46 pm
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?
Post by: redv on September 28, 2014, 09:57:52 pm
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.
Post by: Dioxine on September 29, 2014, 02:04:08 am
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.
Post by: Falko on September 29, 2014, 02:13:33 am
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 :/
Post by: Dioxine on September 29, 2014, 02:23:20 am
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.
Post by: Arthanor on September 29, 2014, 02:30:33 am
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?
Post by: Dioxine on September 29, 2014, 03:39:45 am
(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)
Post by: Falko on September 29, 2014, 03:50:51 am
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
Post by: redv on September 29, 2014, 04:30:39 am
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.
Post by: Dioxine on September 29, 2014, 05:00:05 am
(about the scripts that mod the hit chance based on disputable ideas like not seen personally or recoil - this is beside the point now)
Post by: redv on September 29, 2014, 05:13:42 am
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:)
Post by: Dioxine on October 01, 2014, 09:19:00 pm
Post by: Yankes on October 01, 2014, 10:48:52 pm
Post by: The Reaver of Darkness on October 02, 2014, 10:44:40 am
Post by: pkrcel on October 02, 2014, 10:18:05 pm
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
Post by: Yankes on October 03, 2014, 07:31:16 pm
Post by: new_civilian on October 04, 2014, 02:21:20 pm
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*.... :)
Post by: Yankes on October 04, 2014, 07:34:49 pm
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.
Post by: ivandogovich on October 04, 2014, 07:40:46 pm
....
Weapons, grenades and corpses have "floorSpriteAlt" and "bigSpriteAlt" for live unit, loaded gun and armed grenade.
This is a lovely idea. :)
Post by: redv on October 04, 2014, 09:59:18 pm
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?
Post by: Dioxine on October 05, 2014, 02:52:53 am
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)...
Post by: new_civilian on October 05, 2014, 03:42:02 pm
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.
Post by: Yankes on October 05, 2014, 06:29:06 pm
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 :)This is per armor. Without value its use 20 for enemies or 9 for rest.
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)...
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.
Post by: new_civilian on October 06, 2014, 11:55:49 am
Post by: Yankes on October 06, 2014, 08:57:46 pm
Code: [Select]
CXXFLAGS = -Wall -o3 -s `$(SDL_CONFIG) --cflags`andCode: [Select]
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! ;DDocumentation 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.
Post by: NeoWorm on October 07, 2014, 12:15:23 am
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...
Post by: redv on October 07, 2014, 11:21:14 am
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?
Post by: guille1434 on October 07, 2014, 07:17:54 pm
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!
Post by: Yankes on October 07, 2014, 09:06:30 pm
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.
Post by: guille1434 on October 07, 2014, 10:35:00 pm
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!
Post by: Dioxine on October 08, 2014, 08:50:07 am
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 ;)
Post by: guille1434 on October 08, 2014, 06:25:54 pm
Post by: Dioxine on October 09, 2014, 05:05:49 am
Post by: Falko on October 10, 2014, 02:49:21 am
[..] 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
Post by: VSx86 on October 10, 2014, 04:48:17 pm
more options for creative work. I suspect that many of OXXT (OpenXcom eXTended)
innovations will be added to main OXC sooner or later. ;)
Post by: Yankes on October 10, 2014, 09:18:54 pm
from irc:I will think about this. This probably will be easy to do.
[..] 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 provideProbably 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.
more options for creative work. I suspect that many of OXXT (OpenXcom eXTended)
innovations will be added to main OXC sooner or later. ;)
Example of this is how I handle unconscious unit under explosion, In my version explosion must kill unit first before it can remove body.
Post by: Solarius Scorch on October 11, 2014, 11:01:55 am
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. :)
Post by: new_civilian on October 11, 2014, 11:41:07 am
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!
Post by: Yankes on October 11, 2014, 12:43:26 pm
You copied it wrong way, without line breaks and spaces its useless.
Proper rul should look like:
Code: [Select]
- 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).
Post by: Yankes on October 11, 2014, 07:56:41 pm
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.
Post by: new_civilian on October 12, 2014, 05:23:20 pm
Post by: Sturm on October 14, 2014, 04:58:14 am
I will think about this. This probably will be easy to do.The reverse could be cool too. Explosions being able to cause body/equipment destruction on living soldiers.
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.
Post by: Dioxine on October 14, 2014, 11:17:29 am
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.
Post by: new_civilian on October 14, 2014, 04:24:18 pm
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!
Post by: Dioxine on October 14, 2014, 07:47:41 pm
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 :)
Post by: Yankes on October 14, 2014, 08:02:17 pm
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.
Post by: Dioxine on October 14, 2014, 08:49:55 pm
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?
Post by: new_civilian on October 15, 2014, 04:41:56 pm
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.
Post by: Solarius Scorch on October 17, 2014, 07:06:05 pm
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?
Post by: new_civilian on October 18, 2014, 01:08:45 pm
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...
Post by: Yankes on October 31, 2014, 12:21:08 am
https://www.youtube.com/watch?v=MnKh1nU4XZU
Post by: ivandogovich on October 31, 2014, 12:27:25 am
Obliterate!
https://www.youtube.com/watch?v=MnKh1nU4XZU
Wow. Intended for certain classes of weapons?
Post by: Yankes on October 31, 2014, 12:40:38 am
Post by: ivandogovich on October 31, 2014, 12:43:43 am
Post by: Yankes on October 31, 2014, 01:15:44 am
Post by: arrakis69ct on November 01, 2014, 12:24:58 am
Enviado desde mi LG-D802 mediante Tapatalk
Post by: XOps on November 01, 2014, 01:34:18 am
Post by: Yankes on November 01, 2014, 11:43:01 am
Post by: Yankes on November 01, 2014, 01:28:49 pm
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.
Post by: new_civilian on November 01, 2014, 02:45:26 pm
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. ;)
Post by: new_civilian on November 07, 2014, 04:46:51 pm
*have to test this!*
edit: Doesn't work. :-[ It seems to be a original OpenXcom problem, though.
Post by: Yankes on November 10, 2014, 08:58:51 pm
Just realized that the ability of fixed weapons in armor allows for armed civilians. Now they could wield pistols or combat knifes.... :)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.
*have to test this!*
edit: Doesn't work. :-[ It seems to be a original OpenXcom problem, though.
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
Post by: new_civilian on November 14, 2014, 12:25:03 pm
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.
Post by: bladum on November 14, 2014, 07:10:15 pm
- 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
Post by: Yankes on November 14, 2014, 10:13:54 pm
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...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.
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.
Post by: new_civilian on November 17, 2014, 04:56:01 pm
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)
Post by: robin on November 17, 2014, 07:14:55 pm
Post by: Yankes on November 18, 2014, 12:51:08 am
Does OXC Extended support "dual wielding" tanks?two fixed weapon on one tank? It should work.
Post by: Yankes on November 23, 2014, 05:17:39 am
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).
Post by: Arthanor on November 23, 2014, 05:34:41 am
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)
Post by: robin on November 23, 2014, 11:36:45 am
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?)?
Post by: Yankes on November 23, 2014, 02:11:28 pm
@robin this is separate exe with different name, after installing it you can chose which exe to run. Both exe can live together fine.
Post by: Arthanor on November 23, 2014, 08:23:18 pm
Post by: Yankes on December 03, 2014, 02:02:23 am
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.
Post by: HelmetHair on December 03, 2014, 03:17:23 am
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?
Post by: bladum on December 03, 2014, 09:24:00 am
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
Code: [Select]
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
Post by: Yankes on December 03, 2014, 11:57:40 pm
I have a request.I don't think that mixing item types is good idea, most of this features you request are possible as separate weapons.
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?
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.
Yankes1) 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).
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.0Code: [Select]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
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.
Post by: HelmetHair on December 04, 2014, 12:12:54 am
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
Post by: robin on December 04, 2014, 12:13:45 am
Armor can have build in regeneration.Alien armors too?
Post by: Yankes on December 04, 2014, 12:42:31 am
Please provide a working example so I may replicate it.from first post:
-HH
Code: [Select]
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).
Post by: HelmetHair on December 04, 2014, 03:03:52 am
Post by: bladum on December 04, 2014, 12:46:29 pm
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.
Post by: Yankes on December 04, 2014, 10:10:29 pm
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?
Post by: yrizoud on December 05, 2014, 12:05:27 am
Post by: HelmetHair on December 05, 2014, 05:45:45 am
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!
:)
Post by: yrizoud on December 05, 2014, 10:12:36 am
Post by: bladum on December 05, 2014, 11:17:02 am
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.
Post by: bladum on December 05, 2014, 08:27:56 pm
Thanks
Post by: robin on December 05, 2014, 09:34:17 pm
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).
Post by: bladum on December 05, 2014, 09:38:12 pm
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.
Post by: bladum on December 09, 2014, 02:19:11 pm
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.
Post by: The Reaver of Darkness on December 12, 2014, 05:42:11 pm
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 ?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.
Thanks
Post by: The Reaver of Darkness on December 13, 2014, 05:00:18 pm
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)
Post by: bladum on December 13, 2014, 05:16:59 pm
Post by: Yankes on December 13, 2014, 05:52:46 pm
Something like that:
Code: [Select]
>small scout (3x3)
#
>medium scout (3x3)
#
# #
>large scout (3x3)
#
# #
#
>somthing diffrent (3x3)
###
# #
#
>biggest alien craft (5x5)
# # #
# #
#
Post by: The Reaver of Darkness on December 14, 2014, 02:27:38 pm
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.
Post by: bladum on December 14, 2014, 02:55:37 pm
Post by: The Reaver of Darkness on December 14, 2014, 05:30:23 pm
(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.
Post by: The Reaver of Darkness on December 14, 2014, 08:50:23 pm
Another simple idea regarding base defense: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.
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.
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.
Post by: bladum on December 16, 2014, 02:31:19 pm
unit aggression level current options:
Code: [Select]
0 = mostly passive
1 = balanced
2 = mostly aggresive
what about adding this:
Code: [Select]
-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.
Post by: Warboy1982 on December 16, 2014, 03:10:07 pm
Post by: bladum on December 16, 2014, 05:18:21 pm
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 :)
Post by: Warboy1982 on December 16, 2014, 10:32:26 pm
Post by: bladum on December 17, 2014, 08:50:35 pm
and why not ?
Post by: Yankes on December 17, 2014, 10:11:00 pm
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.
Post by: Warboy1982 on December 18, 2014, 06:41:46 am
Post by: bladum on December 18, 2014, 02:05:03 pm
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
Post by: bladum on December 18, 2014, 10:56:45 pm
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.
Post by: Yankes on December 19, 2014, 02:19:45 am
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).
Post by: Yankes on February 07, 2015, 08:27:26 pm
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.
Post by: kikimoristan on February 10, 2015, 12:00:33 pm
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.
Post by: Yankes on February 10, 2015, 06:52:25 pm
[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?
Post by: kikimoristan on February 11, 2015, 01:39:28 am
lemme try again
Post by: Yankes on February 15, 2015, 09:03:17 pm
btw tollworkout, do you have still this bug?
Post by: kikimoristan on February 15, 2015, 09:47:02 pm
Post by: Yankes on February 16, 2015, 01:19:56 am
Post by: Yankes on February 22, 2015, 06:28:26 pm
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.
Post by: kikimoristan on March 02, 2015, 09:11:34 am
Post by: Yankes on March 02, 2015, 07:27:37 pm
Post by: kikimoristan on March 02, 2015, 08:52:23 pm
Post by: Yankes on March 05, 2015, 01:04:41 am
[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.
Post by: kikimoristan on March 05, 2015, 01:54:54 am
Post by: Yankes on March 06, 2015, 07:20:06 pm
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.
Post by: kikimoristan on March 06, 2015, 07:45:58 pm
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 :)
Post by: Mono on March 08, 2015, 06:15:48 pm
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!
Post by: Yankes on March 08, 2015, 09:31:28 pm
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)You read wrong ufopaedia article :> Hack form UFO don't work in OpenXcom, its have its own set of hacks :)
(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?
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.
Quote
I also have a second request (I'm a greedy person :P)Only thing that prevent me form doing it is error message when you don't have enough hp to use item.
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)
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.
Post by: Mono on March 08, 2015, 11:41:23 pm
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:
Quote
One practical application of this is to create exploding elerium pods that will explode after a pre-set number of turns
Quote
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"?
Post by: Yankes on March 09, 2015, 12:32:49 am
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
Post by: Arthanor on March 09, 2015, 02:56:50 am
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!
Post by: Yankes on March 09, 2015, 08:51:19 pm
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.
Post by: Mono on March 11, 2015, 02:40:48 am
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!
Post by: Yankes on March 11, 2015, 07:58:57 pm
Can I pester you a little about "lazy solutions?" ::)This will complicate code a lot, it's because I need add handing of suicide after every place where is spend resource.
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!
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.
Post by: XOps on March 12, 2015, 04:57:34 am
Post by: kikimoristan on March 12, 2015, 05:10:23 am
Post by: Yankes on March 12, 2015, 09:11:57 am
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.
Post by: Mono on March 12, 2015, 04:56:58 pm
Quote
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.
Post by: Dioxine on March 18, 2015, 06:51:30 pm
- "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...
Post by: Ridаn on March 18, 2015, 07:07:00 pm
Sure hope that after completing TFTD development team would consider integrating all those goodies into a main branch. Keep up the good work.
Post by: Yankes on March 18, 2015, 11:26:45 pm
Hmm... if this hasn't been implemented yet, I have an idea that could add to the complexity of weapons:I had plans to do it but I didn't do it because I get distracted by something else.
- "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).
Quote
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".
Quote
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?In theory can be done.
Sure hope that after completing TFTD development team would consider integrating all those goodies into a main branch. Keep up the good work.
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.
Post by: x60mmx on March 27, 2015, 08:40:07 am
- 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
Post by: Yankes on March 27, 2015, 06:54:27 pm
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.You forget `damageAlter:`
- 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
Proper item should look like:
Code: [Select]
- 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.
Post by: x60mmx on March 28, 2015, 07:58:00 am
Is there any way to define at what range powerRangeReduction begins? If not, any plans to? Would be very helpful!
Post by: Yankes on March 28, 2015, 10:53:48 am
My current plans is finish that I have now and after that I you still interested in that feature I could add this.
Post by: Yankes on March 28, 2015, 03:44:49 pm
I made experimental version for ubuntu. I hope it will work on other machines, at least its work on my VM :D
Post by: x60mmx on March 28, 2015, 07:49:05 pm
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.
Post by: Yankes on April 04, 2015, 10:33:59 am
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.
Post by: x60mmx on April 04, 2015, 10:06:51 pm
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.
Post by: Solarius Scorch on April 04, 2015, 10:36:52 pm
Issues:
Code: [Select]
flatHunderd: 0.0 #const bonus equal 100.Is this correct? Shouldn't it be flatHundred instead of flatHunderd?
This part:
Code: [Select]
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?
Post by: Yankes on April 04, 2015, 10:45:13 pm
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.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.
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.1 yes
Issues:Code: [Select]flatHunderd: 0.0 #const bonus equal 100.
Is this correct? Shouldn't it be flatHundred instead of flatHunderd?
This part:Code: [Select]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?
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.
Post by: Solarius Scorch on April 04, 2015, 11:23:49 pm
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.
Post by: Yankes on April 05, 2015, 02:46:58 am
Post by: Solarius Scorch on April 05, 2015, 03:27:51 am
Post by: Hobbes on April 09, 2015, 01:37:25 pm
(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.
Post by: robin on April 09, 2015, 02:00:19 pm
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:I once though about hijacking those to implement portraits for agents.
(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.
Post by: DoxaLogos (JG) on April 09, 2015, 03:22:04 pm
Post by: Hobbes on April 09, 2015, 03:37:52 pm
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.
Post by: robin on April 09, 2015, 03:52:41 pm
Post by: Warboy1982 on April 09, 2015, 04:58:48 pm
Post by: ivandogovich on April 09, 2015, 05:01:15 pm
Post by: robin on April 09, 2015, 05:19:58 pm
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..
Post by: Hobbes on April 09, 2015, 05:38:25 pm
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...
Post by: Meridian on April 09, 2015, 05:58:51 pm
(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.
Post by: DoxaLogos (JG) on April 09, 2015, 06:45:56 pm
Wait until you see the General or Marshal ones...
Good grief... I'm not sure I want to see that :)
Post by: Yankes on April 09, 2015, 07:53:38 pm
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: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.
This would require some change to the .EXE for the promotion requirements.
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).
Post by: Dioxine on April 09, 2015, 08:04:09 pm
Post by: Yankes on April 09, 2015, 08:16:24 pm
Post by: Dioxine on April 09, 2015, 08:44:55 pm
Post by: Yankes on April 09, 2015, 10:26:30 pm
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.
Post by: robin on April 10, 2015, 01:06:05 am
why there are two files, OpenXcomEx.zip, OpenXcomExElf.zip, for the same version (1.6) ?
Post by: Yankes on April 10, 2015, 06:36:42 pm
Post by: DoxaLogos (JG) on April 11, 2015, 07:03:26 am
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)
Post by: Yankes on April 11, 2015, 12:45:01 pm
So Yankes,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.
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)
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
Post by: DoxaLogos (JG) on April 11, 2015, 07:36:56 pm
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.
Post by: Dioxine on April 11, 2015, 11:21:47 pm
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).
Post by: Warboy1982 on April 11, 2015, 11:24:16 pm
Post by: DoxaLogos (JG) on April 12, 2015, 12:50:28 am
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 :)
Post by: DoxaLogos (JG) on April 12, 2015, 12:58:00 am
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.
Post by: Yankes on April 12, 2015, 05:04:11 pm
Still based on 31/03/2015
New features are new cost for item/weapon use.
Code: [Select]
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.
Post by: Solarius Scorch on April 12, 2015, 05:45:03 pm
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.
Post by: Yankes on April 12, 2015, 06:00:27 pm
Post by: Warboy1982 on April 13, 2015, 01:59:04 am
Post by: Yankes on April 13, 2015, 09:14:30 am
Post by: Dioxine on April 13, 2015, 10:54:05 am
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.
Post by: Yankes on April 13, 2015, 08:13:09 pm
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.
Post by: Dioxine on April 13, 2015, 10:10:17 pm
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).
Post by: DoxaLogos (JG) on April 14, 2015, 02:34:30 am
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.
Post by: Solarius Scorch on April 16, 2015, 05:46:11 pm
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.)
Post by: Dioxine on April 16, 2015, 05:58:25 pm
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.
Post by: Yankes on April 16, 2015, 07:17:25 pm
Post by: Solarius Scorch on April 16, 2015, 08:06:57 pm
Simply you want flag "ignoreMissionDeploy" in craft? :)
Maybe, I don't know the code. :) But yeah, I think so.
Post by: Yankes on April 16, 2015, 11:09:47 pm
Post by: Solarius Scorch on April 17, 2015, 10:41:53 am
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.
Post by: Yankes on April 19, 2015, 05:00:58 pm
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:
Code: [Select]
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:
Code: [Select]
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.
Post by: Solarius Scorch on April 19, 2015, 05:06:39 pm
Post by: Yankes on April 19, 2015, 05:08:35 pm
Post by: Solarius Scorch on April 19, 2015, 05:29:52 pm
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.
Post by: SIMON BAILIE on April 20, 2015, 11:21:15 pm
Post by: Yankes on April 20, 2015, 11:24:49 pm
Post by: SIMON BAILIE on April 20, 2015, 11:52:57 pm
Post by: Yankes on April 21, 2015, 06:29:22 pm
Post by: Yankes on April 21, 2015, 08:22:14 pm
[ps]
I updated to recent nightly too.
Post by: SIMON BAILIE on April 22, 2015, 12:28:06 am
Post by: Yankes on April 22, 2015, 12:30:39 am
And about buttons, yes 4 buttons will appear.
Post by: SIMON BAILIE on April 22, 2015, 01:29:38 am
Post by: SIMON BAILIE on April 25, 2015, 02:27:59 am
Post by: Yankes on April 25, 2015, 03:02:11 am
Post by: Yankes on April 26, 2015, 04:38:23 pm
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.:
Code: [Select]
dodge
Front: 100
75
Side: 50
25
Back: 0
Or less linear
Code: [Select]
dodge
Front: 100
100
Side: 75
50
Back: 0
Or something completely different?
Post by: Solarius Scorch on April 26, 2015, 07:13:47 pm
Post by: Bloax on April 26, 2015, 10:59:42 pm
Code: [Select]
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.
Post by: yrizoud on April 27, 2015, 12:00:07 am
Post by: clownagent on April 27, 2015, 09:55:58 pm
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.:Code: [Select]dodge
Front: 100
75
Side: 50
25
Back: 0
Or less linearCode: [Select]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?
Post by: Yankes on April 27, 2015, 11:23:52 pm
How does this "dodge mechanic" work?From weapon hit chance you subtract dodge chance. Final value determine if hit was successful.
Has a unit the chance to make a potential hit go missing instead?
Logic is simple but probably enough for turn based strategy.
Post by: Bloax on April 28, 2015, 01:00:03 am
But that's just a little, difficult finesse.
Post by: robin on April 29, 2015, 11:22:14 pm
get them here: https://openxcom.org/forum/index.php/topic,3350.msg43786.html#msg43786
Post by: Dioxine on May 10, 2015, 08:09:03 am
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).
Post by: Solarius Scorch on May 10, 2015, 10:58:00 am
- 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.)
Post by: Yankes on May 10, 2015, 12:06:37 pm
Yankes, regarding soldier training on base, would it be possible to have two separate training facilities? Because I would like to have: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.
- 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.)
@Dioxine
I looking on this.
Post by: Dioxine on May 10, 2015, 12:17:52 pm
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.
Post by: Yankes on May 10, 2015, 01:12:41 pm
The only workaround of this "gym problem" I see is:This was one way I could do it.
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;
Quote
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.When I would add different training facilities then custom caps (or even starting requirements) is basic feature for this.
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.
Post by: Solarius Scorch on May 10, 2015, 03:15:17 pm
Good call with the max stat improvement, too. (I think psi balance would also benefit from this limitation.)
Post by: Arthanor on May 10, 2015, 06:08:41 pm
- 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).
Post by: Solarius Scorch on May 10, 2015, 09:28:59 pm
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?
Post by: NuclearStudent on May 11, 2015, 03:51:41 am
In my opinion having both improve reactions might be the best option.
Post by: Arthanor on May 11, 2015, 04:39:32 am
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!
Post by: Solarius Scorch on May 11, 2015, 09:44:53 am
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.
Post by: pilot00 on May 11, 2015, 01:08:00 pm
Post by: Arthanor on May 11, 2015, 03:31:36 pm
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.
Post by: Solarius Scorch on May 11, 2015, 05:49:51 pm
Post by: Bloax on May 11, 2015, 06:18:10 pm
Oh.. I did not realize I phrased my comment quite that way.. What I meant to say is that both facilities should do it.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.
*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!
Post by: pilot00 on May 12, 2015, 01:00:34 am
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).
Post by: the_third_curry on May 12, 2015, 03:47:56 am
Post by: Bloax on May 12, 2015, 04:54:40 am
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
Post by: Solarius Scorch on May 12, 2015, 11:45:31 am
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?
Post by: pilot00 on May 12, 2015, 04:12:35 pm
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 :)
Post by: Dioxine on May 12, 2015, 04:44:10 pm
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).
Post by: Bloax on May 12, 2015, 06:40:11 pm
because having the possibilities there is always good
Post by: Solarius Scorch on May 12, 2015, 06:49:32 pm
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.
Post by: Dioxine on May 12, 2015, 06:53:15 pm
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.
Post by: Yankes on May 12, 2015, 07:14:05 pm
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
Post by: Dioxine on May 12, 2015, 08:36:56 pm
EDIT
Aaaand a major one. This below has happened when I used:
Code: [Select]
- 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... :)
Post by: Yankes on May 12, 2015, 09:45:35 pm
Post by: Dioxine on May 12, 2015, 09:49:04 pm
(nothing special about the Unit, 30 health, 60 bravery, no specabs or stuff like that)
Code: [Select]
- 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.
Post by: Yankes on May 12, 2015, 10:15:00 pm
Post by: Yankes on May 13, 2015, 12:43:29 am
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 :>
Post by: Solarius Scorch on May 13, 2015, 12:54:15 am
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?
Post by: Yankes on May 13, 2015, 01:00:47 am
Post by: Solarius Scorch on May 13, 2015, 01:19:36 am
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.
Post by: arrakis69ct on May 13, 2015, 01:31:31 am
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:If this grow up. Here have a big big big game....
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.
Post by: Bloax on May 13, 2015, 06:50:47 am
Post by: Solarius Scorch on May 13, 2015, 11:59:16 am
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.
Post by: Yankes on May 13, 2015, 07:08:58 pm
Bloax "the gym" currently work like psi lab. You need create building that have training slots.
Post by: Bloax on May 13, 2015, 07:54:20 pm
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.)
Post by: Yankes on May 13, 2015, 08:35:14 pm
Only problems is that mod is incompatible with current OXC and I need update them to new mod format.
Post by: clownagent on May 15, 2015, 06:58:25 pm
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.
Post by: Yankes on May 15, 2015, 07:50:34 pm
The possibilities of this modification are really awesome.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.
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.
Post by: Bloax on May 15, 2015, 10:09:53 pm
Post by: Yankes on May 15, 2015, 11:29:49 pm
Post by: Yankes on May 17, 2015, 03:12:25 pm
Fixed reload button cost.
Baster Luncher rocket don't disappear after first waypoint.
Stun regeneration work properly.
Post by: Firaa on May 17, 2015, 04:02:46 pm
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.
Post by: Yankes on May 17, 2015, 04:21:45 pm
Post by: Dioxine on May 17, 2015, 04:31:42 pm
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.
Post by: Firaa on May 17, 2015, 04:34:25 pm
Code: [Select]
- 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.
Post by: Dioxine on May 17, 2015, 04:35:38 pm
Post by: Yankes on May 17, 2015, 05:13:19 pm
Post by: Warboy1982 on May 17, 2015, 08:22:36 pm
Post by: Solarius Scorch on May 18, 2015, 08:02:35 pm
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.
Post by: Yankes on May 18, 2015, 09:48:04 pm
Post by: SDEDEN on May 19, 2015, 05:00:50 am
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.
Post by: Warboy1982 on May 19, 2015, 12:50:46 pm
Post by: Dioxine on May 19, 2015, 05:55:44 pm
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!) :)
Post by: Warboy1982 on May 19, 2015, 07:11:08 pm
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.
Post by: Dioxine on May 19, 2015, 07:37:56 pm
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)
Post by: robin on May 19, 2015, 10:27:03 pm
https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training (https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training)(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.
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.
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.
Post by: SDEDEN on May 20, 2015, 05:04:03 am
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.
Post by: Yankes on May 20, 2015, 11:23:02 pm
Post by: SDEDEN on May 21, 2015, 04:36:22 am
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.
Post by: Yankes on May 22, 2015, 01:43:18 am
Its fix reload bug and some UI issues with crafts.
Post by: Solarius Scorch on May 22, 2015, 02:04:08 pm
Post by: Yankes on May 23, 2015, 08:14:43 pm
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.
Post by: Solarius Scorch on May 24, 2015, 07:17:49 pm
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. :)
Post by: Arthanor on May 24, 2015, 07:45:08 pm
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
Post by: Yankes on May 24, 2015, 09:47:52 pm
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?
Post by: Solarius Scorch on May 24, 2015, 09:53:54 pm
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?
Post by: Arthanor on May 24, 2015, 10:42:06 pm
Code: [Select]
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:
Code: [Select]
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.
Post by: Yankes on May 24, 2015, 10:47:43 pm
Post by: Arthanor on May 24, 2015, 10:56:31 pm
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.
Post by: pilot00 on May 24, 2015, 11:49:02 pm
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.
Post by: Yankes on May 25, 2015, 12:18:27 am
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.
Post by: Arthanor on May 25, 2015, 12:46:08 am
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.
Post by: Yankes on May 25, 2015, 01:05:36 am
Post by: pilot00 on May 25, 2015, 01:45:49 am
Post by: Solarius Scorch on May 25, 2015, 02:55:44 am
Post by: Arthanor on May 25, 2015, 05:07:05 am
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.
Post by: Solarius Scorch on May 25, 2015, 02:30:44 pm
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).
Post by: pilot00 on May 25, 2015, 03:09:28 pm
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...
Post by: Arthanor on May 25, 2015, 03:34:24 pm
@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.
Post by: Solarius Scorch on May 25, 2015, 03:57:32 pm
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.
Post by: Arthanor on May 25, 2015, 04:12:12 pm
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.
Post by: Solarius Scorch on May 25, 2015, 04:19:02 pm
Post by: Arthanor on May 25, 2015, 04:22:03 pm
Post by: Solarius Scorch on May 25, 2015, 04:32:08 pm
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.
Post by: Yankes on May 25, 2015, 07:07:54 pm
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.
Post by: pilot00 on May 25, 2015, 08:04:01 pm
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.
Post by: Solarius Scorch on May 25, 2015, 08:12:48 pm
Post by: Yankes on May 27, 2015, 09:00:00 pm
I fixed two bug with berserker, first one that prevent unit form shooting and second that allow use of not researched weapons while berserkerking.
Post by: pilot00 on May 28, 2015, 02:57:00 pm
Post by: Solarius Scorch on May 28, 2015, 04:12:39 pm
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.
Post by: pilot00 on May 28, 2015, 11:10:14 pm
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... :(
Post by: arrakis69ct on May 31, 2015, 05:42:43 pm
It definitely should be, but the FMP doesn't use the options that OXCE enables. Yet.When a versión compatible.
So the experience should be the same as vanilla exe really.
Enviado desde mi ECOO E04 3GB mediante Tapatalk
Post by: new_civilian on June 04, 2015, 11:28:35 am
fwiw, the readme needs an update (the part about regen when use for items is still in it)
Post by: Yankes on June 07, 2015, 09:11:43 pm
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!could you be more precise what line in readme need fixing?
fwiw, the readme needs an update (the part about regen when use for items is still in it)
Post by: new_civilian on June 10, 2015, 01:08:03 pm
Sorry for the late answer, was busy actually playing OpenXcom with your awesome Exe! ;D
Post by: Yankes on June 10, 2015, 07:38:18 pm
Maybe I need rephrase it to be more clearly.
Post by: Dioxine on June 11, 2015, 12:44:52 am
Post by: new_civilian on June 11, 2015, 01:09:39 pm
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 :)
Post by: ivandogovich on June 11, 2015, 06:05:18 pm
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?
Post by: Meridian on June 11, 2015, 06:16:10 pm
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.
Post by: Arthanor on June 11, 2015, 06:47:08 pm
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.
Post by: Yankes on June 11, 2015, 08:11:40 pm
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.
Post by: Arthanor on June 11, 2015, 10:19:00 pm
And for custom inventory, this would be problematic because lot of code depends on/use this (like AI, inventory templates, equipping units).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).
This would require more work that is worth.
Quote
I thinking about resurrecting my old branch: https://openxcom.org/forum/index.php/topic,2059.0.html#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.
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.
Post by: Dioxine on June 12, 2015, 02:33:31 pm
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.
Post by: alinare on June 12, 2015, 04:09:39 pm
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.
Post by: Solarius Scorch on June 12, 2015, 06:03:38 pm
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? ;)
Post by: Dioxine on June 12, 2015, 06:54:09 pm
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.
Post by: Yankes on June 12, 2015, 07:48:04 pm
I hope this means what I think it means.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.
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? ;)
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.
Post by: alinare on June 12, 2015, 08:07:30 pm
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.
Post by: Arthanor on June 12, 2015, 08:43:08 pm
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
Post by: Yankes on June 12, 2015, 08:55:34 pm
Code: [Select]
facilities:
- Type: STR_NUCLEAR_DEFENSES
provideBaseFunc: [A, ThisCanBeAnyText ]
"requiresBaseFunc" - this is what is require in base to use.
Code: [Select]
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:
Code: [Select]
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.
Post by: Dioxine on June 12, 2015, 09:46:42 pm
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! :)
Post by: Jo5hua on June 12, 2015, 09:56:00 pm
It is working now, sorry for the inconvenience. All is good now :)
Post by: Yankes on June 12, 2015, 10:43:28 pm
Post by: alinare on June 13, 2015, 12:39:19 pm
Post by: Yankes on June 14, 2015, 09:08:52 pm
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.
Post by: new_civilian on June 15, 2015, 11:49:52 am
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
Post by: Dioxine on June 15, 2015, 03:59:16 pm
Code: [Select]
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)
Post by: new_civilian on June 16, 2015, 12:39:35 pm
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!
Post by: new_civilian on June 29, 2015, 02:43:32 pm
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. :)
Post by: Yankes on June 30, 2015, 07:23:12 pm
Post by: Dioxine on July 02, 2015, 05:53:09 pm
Post by: Yankes on July 02, 2015, 06:41:13 pm
Post by: Dioxine on July 02, 2015, 07:46:11 pm
Post by: Arthanor on July 02, 2015, 09:05:38 pm
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.
Post by: Yankes on July 07, 2015, 01:43:29 am
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
Post by: Dioxine on July 07, 2015, 08:40:15 pm
- Sometimes, explosives detonate twice, causing double damage
- Would it be possible to define the number of detonations for an explosive (item-per-item basis)?
Post by: Yankes on July 07, 2015, 09:47:52 pm
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.
Post by: Dioxine on July 08, 2015, 05:04:42 pm
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).
Post by: Yankes on July 08, 2015, 11:40:14 pm
I mess up logics some were. Armor only expose this bug.
Post by: Yankes on July 10, 2015, 11:29:37 pm
Post by: new_civilian on July 12, 2015, 05:44:40 pm
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.
Post by: Yankes on July 12, 2015, 08:12:59 pm
Bug fix version is ready. I add recent commits form master branch, this mean I could add new bugs to it :DAnd for reaction, I didn't touch it jet. Probably another miss merge.
Post by: robin on July 15, 2015, 12:34:31 am
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";
--
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.
Post by: Yankes on July 15, 2015, 01:11:28 am
Post by: robin on July 15, 2015, 07:19:13 pm
Don't know if it is exclusive to the Extended version or not.
Post by: Yankes on July 15, 2015, 11:49:47 pm
Post by: Searmay on July 18, 2015, 12:06:45 am
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.
Post by: wsmithjr on July 18, 2015, 08:16:34 pm
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.
Post by: Yankes on July 18, 2015, 11:26:34 pm
Post by: robin on July 20, 2015, 10:43:02 am
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).
Post by: new_civilian on July 20, 2015, 11:21:58 am
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.... :-\
Post by: robin on July 20, 2015, 11:40:32 am
Happened to me, too, but i had forgotten to set the medikittype. :)I have the medkit type.
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'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.
Post by: Arthanor on July 20, 2015, 05:52:38 pm
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.
Post by: Yankes on July 20, 2015, 07:18:04 pm
I had a weird thing where both the medi-kits I equipped couldn't be used.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".
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.
Happened to me, too, but i had forgotten to set the medikittype. :)I do not touch damages types recently. Behavior should not change.
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.... :-\
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.
Post by: robin on July 20, 2015, 08:06:56 pm
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
Post by: robin on July 20, 2015, 11:09:15 pm
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
Post by: Yankes on July 21, 2015, 02:15:53 am
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.After checking code, error "STR_NO_USES_LEFT" can only appear if you use new instant medikit and you run out uses.
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).
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 can't reproduce it. Can you test it with F8 that will slow animations?
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):
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).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.
Don't know if it is exclusive to the Extended version or not.
I assume this is a bug with Extended - it affects X-Piratez, but not the unmodified game:fixed.
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.
Tomorrow I will publish new version with all the fixes.
Post by: robin on July 21, 2015, 09:37:00 am
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.
Post by: Yankes on July 21, 2015, 07:24:30 pm
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 "**"):"RandomType": you misquote me, that text was for civilian.
- 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.
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.
Post by: begri on July 21, 2015, 07:26:39 pm
I would like to try it on android.
Post by: Yankes on July 21, 2015, 07:51:38 pm
I need the simple files without the installer. Can you attach it somewhere?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.
I would like to try it on android.
Post by: begri on July 21, 2015, 07:57:41 pm
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...
Post by: Yankes on July 21, 2015, 09:03:14 pm
Post by: begri on July 21, 2015, 09:05:02 pm
Post by: robin on July 21, 2015, 10:26:47 pm
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.
Post by: Yankes on July 21, 2015, 10:45:03 pm
Post by: new_civilian on July 22, 2015, 12:05:58 pm
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. :)
Post by: new_civilian on July 22, 2015, 12:16:45 pm
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)
Post by: Dioxine on July 22, 2015, 01:47:55 pm
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 :)
Post by: Yankes on July 22, 2015, 07:08:02 pm
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 :>
Post by: Yankes on July 23, 2015, 01:54:49 am
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.
Post by: new_civilian on July 24, 2015, 11:29:08 am
+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)
Post by: Yankes on July 26, 2015, 06:54:18 pm
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.
Post by: Dioxine on July 26, 2015, 07:37:32 pm
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
Post by: SIMON BAILIE on July 28, 2015, 12:54:54 pm
Post by: hellrazor on July 28, 2015, 01:02:48 pm
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.
Post by: SIMON BAILIE on July 28, 2015, 01:11:48 pm
Post by: new_civilian on July 29, 2015, 04:37:18 pm
I love the new explosion sound abilty! :)
Post by: Yankes on August 01, 2015, 01:38:06 am
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.
Post by: SIMON BAILIE on August 01, 2015, 02:54:31 am
Post by: Yankes on August 01, 2015, 01:51:05 pm
Post by: SIMON BAILIE on August 01, 2015, 02:14:36 pm
Post by: Yankes on August 01, 2015, 05:29:46 pm
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" :)
Post by: Yankes on August 02, 2015, 03:18:13 am
Post by: Dioxine on August 03, 2015, 02:29:42 pm
Post by: Meridian on August 03, 2015, 02:35:28 pm
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: /
Post by: new_civilian on August 03, 2015, 02:45:51 pm
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)
Post by: Yankes on August 03, 2015, 09:32:00 pm
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).
Post by: Ridаn on August 05, 2015, 04:41:26 pm
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.
Post by: Dioxine on August 05, 2015, 04:45:14 pm
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.
Post by: new_civilian on August 06, 2015, 01:50:27 pm
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. :)
Post by: kikimoristan on August 13, 2015, 05:58:57 am
Post by: Yankes on August 13, 2015, 09:40:45 pm
Post by: Dioxine on August 14, 2015, 08:06:37 pm
Post by: kikimoristan on August 15, 2015, 06:58:48 am
Post by: Dioxine on August 15, 2015, 09:08:36 am
Post by: Yankes on August 15, 2015, 11:47:20 am
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)
Post by: Dioxine on August 15, 2015, 12:45:55 pm
Post by: Yankes on August 15, 2015, 01:44:49 pm
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.
Post by: Dioxine on August 15, 2015, 03:58:44 pm
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...
Post by: Yankes on August 15, 2015, 04:16:47 pm
Post by: Dioxine on August 15, 2015, 04:27:54 pm
However, as of 27th July Nightly, the missing fixed weapons bug still persists.
Post by: kikimoristan on August 16, 2015, 02:31:40 am
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.
Post by: niculinux on August 18, 2015, 09:12:52 pm
EDIT: once next openxcom stable version will be relased, a dedicated ubuntu PPA for the mod may be also created, don't know...
Post by: kikimoristan on August 18, 2015, 09:25:14 pm
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.
Post by: Yankes on August 18, 2015, 11:25:30 pm
Recently I have lot of distraction and work don't move fast.
Post by: niculinux on August 19, 2015, 11:43:35 am
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
Post by: Solarius Scorch on August 21, 2015, 10:41:47 am
Post by: Yankes on August 21, 2015, 10:47:45 am
Post by: Solarius Scorch on August 21, 2015, 10:51:47 am
This already done by another property.
...my knowledge of your project really has been slipping recently. :)
Post by: hellrazor on August 21, 2015, 11:51:07 am
This already done by another property.
Regarding that, could you make a pull request for the respective code into the master branch?
Post by: Yankes on August 22, 2015, 02:34:33 am
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.
Post by: kikimoristan on August 22, 2015, 02:53:40 am
Post by: kikimoristan on August 22, 2015, 02:59:17 am
Post by: Dioxine on September 07, 2015, 11:27:11 am
Post by: Yankes on September 07, 2015, 08:27:44 pm
Another thing is why you need do it? Couldn't you create separate mission that will have different alert, briefing, marker?
Post by: Dioxine on September 07, 2015, 08:57:36 pm
Post by: Yankes on September 07, 2015, 11:56:32 pm
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.
Post by: Solarius Scorch on September 13, 2015, 04:02:47 pm
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?
Post by: Yankes on September 13, 2015, 04:35:19 pm
Post by: Solarius Scorch on September 13, 2015, 08:03:08 pm
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
Post by: Dioxine on September 15, 2015, 03:05:07 pm
Post by: niculinux on September 15, 2015, 03:36:44 pm
Post by: Yankes on September 15, 2015, 08:02:36 pm
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.
Post by: Solarius Scorch on September 19, 2015, 08:59:36 am
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.
Post by: Yankes on September 19, 2015, 12:52:01 pm
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.
Post by: Solarius Scorch on September 19, 2015, 01:02:04 pm
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. :)
Post by: stalks on September 20, 2015, 08:23:21 pm
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.
Post by: Solarius Scorch on September 24, 2015, 08:40:17 am
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.
Post by: stalks on September 25, 2015, 08:02:03 pm
Post by: Yankes on September 25, 2015, 10:24:39 pm
Those firing modes would be very nice, but they certainly don't fall within this mod's objectives.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?
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?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".
Post by: Yankes on September 26, 2015, 08:32:52 pm
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.
Post by: Yankes on September 28, 2015, 02:03:56 am
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.
Post by: Dioxine on October 03, 2015, 12:39:56 pm
Post by: Solarius Scorch on October 03, 2015, 12:48:03 pm
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?
Post by: Yankes on October 03, 2015, 04:29:21 pm
Post by: Yankes on October 10, 2015, 01:12:28 am
https://youtu.be/FKzqCOg2DrQ
Next I will refactoring it to improve code. I plan that it will be finished in two weeks.
Post by: Solarius Scorch on October 10, 2015, 01:32:16 am
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.
Post by: Dioxine on October 10, 2015, 03:47:40 am
Post by: TigerLord on October 10, 2015, 04:54:02 am
Any help much appreciated, thanks:)
Post by: Yankes on October 10, 2015, 01:10:55 pm
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.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.
Any help much appreciated, thanks:)
Post by: Dioxine on October 10, 2015, 01:26:52 pm
Post by: Arthanor on October 10, 2015, 04:38:09 pm
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".
Post by: Dioxine on October 10, 2015, 05:48:24 pm
Post by: Solarius Scorch on October 10, 2015, 05:54:06 pm
Post by: Arthanor on October 10, 2015, 06:23:38 pm
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.
Post by: Solarius Scorch on October 10, 2015, 06:39:39 pm
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.
Post by: Arthanor on October 10, 2015, 06:52:12 pm
Post by: Solarius Scorch on October 10, 2015, 07:45:25 pm
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. :)
Post by: Yankes on October 11, 2015, 01:22:47 am
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.
Post by: Dioxine on October 11, 2015, 10:55:31 am
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 :)
Post by: new_civilian on October 16, 2015, 06:29:54 pm
and what about the new soldiertypes of the latest nightly? :)
Post by: Yankes on October 16, 2015, 09:19:27 pm
And for solders, right now I'm ignoring what happening in nightlys because I'm doing different things in my branch.
Post by: Dioxine on October 16, 2015, 09:28:24 pm
Post by: Arthanor on October 16, 2015, 10:02:37 pm
- 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.
Post by: Dioxine on October 16, 2015, 10:18:40 pm
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! :)
Post by: Arthanor on October 16, 2015, 11:21:22 pm
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..!)
Post by: Dioxine on October 17, 2015, 11:16:24 am
(it's a bit like Bioware morality, but more ethical and much less veiled)
Post by: robin on October 17, 2015, 03:39:03 pm
Post by: Dioxine on October 17, 2015, 03:54:52 pm
(sorry for horrible OT :) )
also @Arthanor, I am relieved that the real science is still alive :)
Post by: Solarius Scorch on October 18, 2015, 11:40:42 am
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 :)
Post by: new_civilian on October 18, 2015, 05:33:10 pm
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! :)
Post by: Arthanor on October 18, 2015, 07:09:45 pm
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..)
Post by: new_civilian on October 19, 2015, 04:34:31 pm
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.
Post by: moriarty on October 23, 2015, 05:37:06 pm
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?
Post by: Solarius Scorch on October 23, 2015, 06:07:41 pm
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!
Post by: Yankes on October 23, 2015, 08:44:24 pm
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).
Post by: moriarty on October 24, 2015, 10:35:54 pm
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")...
Post by: Yankes on October 25, 2015, 12:33:39 am
Post by: KingMob4313 on October 25, 2015, 02:47:29 am
Post by: KingMob4313 on October 25, 2015, 04:31:24 am
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.
Post by: Yankes on October 25, 2015, 03:31:01 pm
Post by: KingMob4313 on October 25, 2015, 05:10:29 pm
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.
Post by: Dioxine on October 29, 2015, 04:21:56 pm
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 :)
Post by: Yankes on October 29, 2015, 08:42:38 pm
In attachment there is data for version 2.5
Post by: Dioxine on November 07, 2015, 12:54:04 pm
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.
Post by: moriarty on November 07, 2015, 01:30:06 pm
The 2 properties I can think of now would be 'production' and 'science'.
...and 'piloting'...
Post by: Yankes on November 07, 2015, 04:50:41 pm
@Extra soldiers stats (a'la UFO:Afterlight or whatever).I have some thing like that in my far plans. Most objects in game will have customizable properties not used by game:
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.
Code: [Select]
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.
Post by: DracoGriffin on November 07, 2015, 07:54:53 pm
@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!
Post by: cowboy on November 17, 2015, 04:43:47 am
Post by: Dioxine on November 17, 2015, 02:40:07 pm
Oh yeah and making a proper Total Conversion takes a year or three, so be prepared :)
Post by: Yankes on November 17, 2015, 07:30:06 pm
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.
Post by: cowboy on November 18, 2015, 07:42:46 am
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.
Post by: Dioxine on November 20, 2015, 09:48:55 pm
Post by: Arthanor on November 20, 2015, 09:53:24 pm
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.
Post by: Yankes on November 20, 2015, 11:13:31 pm
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.
Post by: Dioxine on November 21, 2015, 01:15:15 am
Post by: Yankes on November 21, 2015, 01:50:16 am
BTW, around hour or more next bug fix verison will be ready.
Post by: Yankes on November 21, 2015, 02:13:28 am
- consistent craft stats
- stun unit items
- exposion radius based on stats
Post by: Dioxine on November 21, 2015, 12:28:00 pm
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?
Post by: Yankes on November 21, 2015, 01:40:10 pm
Post by: Dioxine on November 21, 2015, 02:01:58 pm
The meele code:
Code: [Select]
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?
Post by: Dioxine on November 21, 2015, 05:16:47 pm
Code: [Select]
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)
Post by: Yankes on November 21, 2015, 05:57:32 pm
And for psi-amp, I will look on this in code. Probably some special handling of psi attack override melee hits.
Post by: Dioxine on November 21, 2015, 06:51:33 pm
Post by: Dioxine on November 21, 2015, 10:31:55 pm
Post by: Yankes on November 22, 2015, 01:55:13 am
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.
Post by: Dioxine on November 22, 2015, 02:10:06 pm
Post by: Yankes on November 22, 2015, 02:33:17 pm
[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.
Post by: Dioxine on November 22, 2015, 05:15:15 pm
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?
Post by: Dioxine on November 22, 2015, 06:10:14 pm
Post by: Yankes on November 22, 2015, 11:34:35 pm
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.
Post by: Imeryak on November 24, 2015, 07:09:14 am
Post by: Cristao on November 24, 2015, 08:55:54 am
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.
Post by: Yankes on November 24, 2015, 07:35:05 pm
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.
Post by: Dioxine on November 27, 2015, 05:36:57 pm
Post by: Yankes on November 27, 2015, 06:51:49 pm
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
Post by: Yankes on November 27, 2015, 11:55:33 pm
Post by: Dioxine on November 28, 2015, 02:23:22 am
Post by: Yankes on November 28, 2015, 09:49:55 am
Post by: niculinux on November 28, 2015, 08:41:48 pm
Post by: Yankes on November 29, 2015, 12:32:20 am
One questions do this name is still calculated or it maybe leftover after mod was disabled? New hired have it too?
Post by: niculinux on November 29, 2015, 01:09:18 pm
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.
Post by: Yankes on November 29, 2015, 01:34:04 pm
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
Post by: niculinux on November 29, 2015, 02:20:05 pm
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
Post by: Dioxine on November 30, 2015, 01:13:58 am
Post by: The Reaver of Darkness on November 30, 2015, 11:23:06 am
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.
Post by: Yankes on November 30, 2015, 07:38:46 pm
Can I use this to change the base layout to 8x8?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.
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.
Post by: The Reaver of Darkness on December 01, 2015, 11:41:22 am
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.
Post by: Dioxine on December 01, 2015, 02:33:45 pm
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%?
Post by: Yankes on December 01, 2015, 07:55:30 pm
Why can't the base screen just be put to a higher resolution?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).
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.
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.
Post by: The Reaver of Darkness on December 02, 2015, 07:26:49 am
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?
Post by: Arthanor on December 02, 2015, 06:25:28 pm
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
Post by: robin on December 03, 2015, 11:59:36 am
Post by: Yankes on December 03, 2015, 07:02:35 pm
Post by: Dioxine on December 04, 2015, 01:26:36 pm
Post by: DracoGriffin on December 04, 2015, 03:05:30 pm
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)
Post by: Yankes on December 04, 2015, 07:15:54 pm
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).
Post by: Arthanor on December 04, 2015, 08:04:29 pm
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.
Post by: Yankes on December 04, 2015, 08:20:21 pm
Another minor request:It will be hard because not enough space for 4th line. Without some sacrifices it is probably impossible.
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.
Post by: Arthanor on December 04, 2015, 08:47:52 pm
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.
Post by: Yankes on December 04, 2015, 09:50:06 pm
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.
Post by: Dioxine on December 04, 2015, 10:41:15 pm
Post by: Arthanor on December 04, 2015, 10:52:17 pm
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).
Post by: Solarius Scorch on December 10, 2015, 12:29:27 am
Post by: Yankes on December 10, 2015, 01:17:28 am
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 :)
Post by: Solarius Scorch on December 10, 2015, 01:26:03 am
So, how is it going? Can we put you under pressure now? :)
Post by: Meridian on December 11, 2015, 12:38:46 pm
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)
Code: [Select]
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 ==========
Post by: Arthanor on December 11, 2015, 06:29:57 pm
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.
Post by: Yankes on December 11, 2015, 06:48:02 pm
"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".
Post by: Meridian on December 11, 2015, 11:49:57 pm
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... :(
Post by: Yankes on December 12, 2015, 01:55:53 am
Post by: Meridian on December 12, 2015, 12:23:05 pm
Code: [Select]
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 ==========
Post by: Yankes on December 12, 2015, 03:18:00 pm
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.
Post by: Meridian on December 12, 2015, 11:28:16 pm
After updating I also had to add one more file (TrainingState.h/cpp) and then it was OK.
Post by: The Reaver of Darkness on December 13, 2015, 12:25:15 pm
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.
Post by: Yankes on December 13, 2015, 12:42:09 pm
Post by: robin on December 14, 2015, 02:58:28 pm
i guess i could take out the files from xpiratez mod.
Post by: Yankes on December 14, 2015, 06:43:59 pm
Post by: robin on December 16, 2015, 10:58:22 pm
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.
vanilla:
- type: STR_TURRET
clipSize: 6
- type: STR_AMMO
clipSize: 6
equals to extended:
- type: STR_TURRET
clipSize: 1
- type: STR_AMMO
clipSize: 6
also turning off retaliation for alien races is different afaik.
vanilla:
- retaliation: false
extended:
- retaliationAggression: -100
anything else?
thanks
Post by: Yankes on December 16, 2015, 11:29:38 pm
Post by: Dioxine on December 17, 2015, 08:39:46 am
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 :)
Post by: AbuDhabi on December 20, 2015, 05:05:29 pm
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?
Post by: Yankes on December 20, 2015, 06:26:51 pm
Post by: Dioxine on December 27, 2015, 12:54:10 am
Post by: Yankes on December 27, 2015, 01:17:26 am
Post by: Meridian on December 27, 2015, 10:53:30 am
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
Post by: Dioxine on December 27, 2015, 12:39:22 pm
@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... :)
Post by: Meridian on December 27, 2015, 01:24:20 pm
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
Post by: Dioxine on December 27, 2015, 01:41:39 pm
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?
Code: [Select]
- 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:
Code: [Select]
- 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.
Post by: Yankes on December 27, 2015, 02:55:22 pm
Code: [Select]
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.
Post by: Solarius Scorch on December 27, 2015, 02:59:59 pm
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. :)
Post by: Meridian on December 27, 2015, 04:27:38 pm
I think that some med-kits should be only self use. Instead of current `allowSelfHeal`would be new property:Code: [Select]allowedTargets:
self: true
enemy: false
friend: true
stuned: false
Maybe also:
neutral: false/true ?
Post by: Yankes on December 27, 2015, 04:34:57 pm
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:Right, this too. It can have some uses over reusing `friend`for them.
neutral: false/true ?
Post by: Meridian on December 27, 2015, 06:44:50 pm
@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?
Post by: Yankes on December 27, 2015, 09:57:14 pm
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.
Post by: Meridian on December 27, 2015, 10:07:21 pm
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
Post by: Dioxine on December 27, 2015, 10:59:57 pm
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.
Post by: Meridian on December 28, 2015, 09:32:09 am
Which features would you turn off if you had the possibility?
Post by: davide on December 28, 2015, 12:10:58 pm
Charge available indicator are very useful :D
You could omit digit 0 when useless (003 -> 3)
Post by: Dioxine on December 29, 2015, 09:04:12 am
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.
Post by: Meridian on December 29, 2015, 12:24:06 pm
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
Post by: Solarius Scorch on December 31, 2015, 11:50:26 am
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.
Post by: Meridian on December 31, 2015, 10:23:46 pm
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.
Post by: Yankes on January 01, 2016, 02:58:36 pm
If you do it everything correctly, you should have clean fork of OXC without OXCE under:
Code: [Select]
git remote add MeridianRepo git@github.com:Meridian/OpenXcom.gitThen under two address you can grab my or supsuper changes:
Code: [Select]
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:Code: [Select]
git fetch YankesRepo
git merge YanikesRepo/master
Then you can push all changes from your master branch to your repo:
Code: [Select]
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/
Post by: Meridian on January 06, 2016, 06:30:41 pm
Post by: Yankes on January 06, 2016, 06:51:45 pm
Post by: Solarius Scorch on January 10, 2016, 02:39:04 pm
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.
Post by: Yankes on January 10, 2016, 08:11:04 pm
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.
Post by: Solarius Scorch on January 10, 2016, 11:42:33 pm
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.
Post by: Dioxine on January 11, 2016, 05:10:24 pm
Post by: Yankes on January 14, 2016, 02:13:51 am
New version is close to finish, some teaser: https://youtu.be/q0-RwIvLUxw
Post by: Dioxine on January 14, 2016, 10:10:17 am
Post by: Yankes on January 14, 2016, 07:50:24 pm
Post by: ivandogovich on January 14, 2016, 08:06:20 pm
- 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. ;)
Post by: Solarius Scorch on January 14, 2016, 08:13:24 pm
- Reaper's head swaying slowly side to side,
- Boomasaurus drooling
- StarGods shimmering...
- ...Snakemen swaying,
- Mutons flexing,
- Sectoids STILL NOT BLINKING.
:)
Post by: Yankes on January 14, 2016, 08:28:20 pm
So I think we are getting into animated sprites with that demo...s*** I thought that nobody will want doing animation for big units and skipped implementing that for them. I need probably add this too,
- 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. ;)
Post by: ivandogovich on January 14, 2016, 08:53:40 pm
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. ;)
Post by: Dioxine on January 14, 2016, 10:21:28 pm
Better question is what consequence of this are.
Impossible to tell without trying it :)
Post by: XOps on January 15, 2016, 09:50:35 pm
Post by: Yankes on January 17, 2016, 09:04:21 pm
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.
Post by: Meridian on January 20, 2016, 08:26:28 pm
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!
Post by: Dioxine on January 21, 2016, 10:24:16 am
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 :)
Post by: Yankes on January 21, 2016, 09:41:58 pm
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.
Post by: Meridian on January 21, 2016, 11:25:38 pm
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.
Post by: Meridian on January 24, 2016, 10:16:28 pm
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.
Post by: Yankes on January 29, 2016, 01:37:19 am
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.
Post by: Yankes on January 30, 2016, 12:55:38 am
How made animation and change torso to something else?
Solution:
Code: [Select]
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.
Post by: Meridian on January 30, 2016, 09:47:55 pm
Post by: Yankes on January 31, 2016, 02:01:55 am
[ps]
can you test my version of exe: https://www.mediafire.com/?zbzytnl6s8r69tz if it work or crash?
Post by: Meridian on January 31, 2016, 10:26:21 am
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.
Post by: Yankes on January 31, 2016, 02:30:00 pm
Sometimes small difference can easy crash something.
Post by: debuser on February 01, 2016, 01:31:57 pm
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!
Post by: Yankes on February 01, 2016, 07:59:46 pm
Hi YankesFirst of all most of this, with you have problems is from Meridian branch. It will be hard to debug someone else code.
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!
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.
Post by: debuser on February 02, 2016, 12:24:30 am
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
Post by: Yankes on February 02, 2016, 12:42:57 am
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 :)
Post by: Meridian on February 02, 2016, 01:04:09 am
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.
Post by: Yankes on February 02, 2016, 01:29:14 am
I will need spend some time cherry-pick cherries from your branch :)
Post by: yrizoud on February 04, 2016, 09:48:21 pm
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
Code: [Select]
#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 endFire 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)
Post by: Yankes on February 05, 2016, 01:13:23 am
Post by: Aldi on February 17, 2016, 05:26:55 pm
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?
Post by: Yankes on February 17, 2016, 07:30:49 pm
Code: [Select]
sudo apt-get install libyaml-cpp0.5This command don't work? It work in 14.04 LTS. Do you have other yaml-cpp libs available? You can test is easy typing:Code: [Select]
apt-get install libyamland 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.
Post by: R1dO on February 17, 2016, 08:02:48 pm
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.
Post by: Aldi on February 17, 2016, 08:10:25 pm
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.
Post by: Yankes on February 17, 2016, 08:22:24 pm
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.
Post by: Aldi on February 17, 2016, 10:44:14 pm
Many thanks for advice.
Post by: Yankes on February 17, 2016, 11:07:40 pm
Post by: Aldi on February 18, 2016, 12:20:55 am
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?
Post by: Aldi on February 18, 2016, 12:18:12 pm
Post by: Meridian on February 18, 2016, 12:26:48 pm
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
Post by: Dioxine on February 18, 2016, 05:52:14 pm
Post by: Meridian on February 18, 2016, 06:08:46 pm
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).
Post by: Dioxine on February 18, 2016, 06:22:57 pm
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.
Post by: Meridian on February 18, 2016, 06:58:23 pm
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
Post by: Dioxine on February 18, 2016, 08:16:09 pm
Post by: Aldi on February 19, 2016, 01:13:48 am
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.
Post by: Yankes on February 21, 2016, 04:11:40 pm
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.
Post by: Meridian on February 27, 2016, 02:22:38 pm
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...
Post by: Yankes on February 28, 2016, 01:36:37 am
Post by: Meridian on February 28, 2016, 04:43:36 pm
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.
Post by: Yankes on February 28, 2016, 05:43:42 pm
Post by: Countdown on February 29, 2016, 01:07:14 pm
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!
Post by: Solarius Scorch on February 29, 2016, 01:30:45 pm
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.
Post by: Countdown on February 29, 2016, 02:15:52 pm
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?
Post by: Yankes on February 29, 2016, 11:34:13 pm
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.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).
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!
Post by: Dioxine on February 29, 2016, 11:41:20 pm
Post by: Yankes on February 29, 2016, 11:55:33 pm
[ps]
This is true, but in real life you'd be able to tell if you put a bullet in their head haha.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.
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?
Post by: Countdown on March 01, 2016, 02:07:18 am
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.
Post by: Yankes on March 01, 2016, 07:32:34 pm
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.
Post by: Countdown on March 01, 2016, 09:13:34 pm
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)
Post by: Yankes on March 01, 2016, 09:51:16 pm
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.
Post by: Dioxine on March 01, 2016, 10:16:06 pm
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.
Post by: Countdown on March 02, 2016, 12:28:52 am
Code: [Select]
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.
Post by: Yankes on March 02, 2016, 12:57:36 am
Post by: Dioxine on March 02, 2016, 01:07:35 am
Post by: Countdown on March 02, 2016, 02:57:52 am
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.
Post by: Yankes on March 02, 2016, 06:52:32 pm
Again sorry for confusion.
Work around to enable items and inventory recoloring is adding in armor:
Quote
recolorScript: |
unit.getRecolor i0;
add_burn_shade i0 burn shade;
ret i0;
Post by: Countdown on March 02, 2016, 10:17:22 pm
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.
Post by: Yankes on March 03, 2016, 08:13:35 pm
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.)Right now not. But I think about way to add it.
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.
Post by: Meridian on March 10, 2016, 12:25:08 am
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
Post by: Dioxine on March 11, 2016, 03:31:20 am
Post by: Yankes on March 11, 2016, 07:12:06 pm
Stun damage type for defualt will have not random value but other damage types will randomize it.
Sneak peek from next version ruleset:
Code: [Select]
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.
Post by: Meridian on March 11, 2016, 10:14:14 pm
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).
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.
Post by: Yankes on March 11, 2016, 10:22:52 pm
Post by: Dioxine on March 11, 2016, 11:26:41 pm
Post by: Yankes on March 11, 2016, 11:32:03 pm
Post by: ivandogovich on March 14, 2016, 10:54:40 pm
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
Post by: Yankes on March 14, 2016, 10:57:46 pm
Post by: ivandogovich on March 14, 2016, 11:22:11 pm
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!
Post by: Dioxine on March 17, 2016, 11:16:08 am
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)
Post by: Meridian on March 17, 2016, 04:11:10 pm
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?
Post by: Dioxine on March 19, 2016, 11:19:53 am
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.
Post by: ivandogovich on March 19, 2016, 05:27:41 pm
https://openxcom.org/forum/index.php/topic,4424.0.html
Cheers, Ivan :D
Post by: Yankes on March 19, 2016, 06:05:59 pm
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).
Post by: Yankes on March 22, 2016, 01:33:41 am
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
Post by: Meridian on March 24, 2016, 02:01:06 pm
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.
Post by: Dioxine on March 24, 2016, 04:05:15 pm
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.
Post by: Meridian on March 25, 2016, 01:51:47 pm
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.
Post by: Meridian on March 27, 2016, 10:17:24 pm
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
Post by: Yankes on March 28, 2016, 01:09:35 am
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.
Post by: Meridian on March 28, 2016, 01:01:59 pm
Post by: g5-freemen on April 04, 2016, 11:30:51 am
And what is the difference between OpenXCOM Extended & OpenXCOM Extended+
Post by: Countdown on April 04, 2016, 11:54:06 am
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
Post by: Meridian on April 04, 2016, 11:59:29 am
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
Post by: g5-freemen on April 04, 2016, 01:14:36 pm
Post by: Solarius Scorch on April 04, 2016, 02:18:49 pm
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.
Post by: g5-freemen on April 11, 2016, 11:41:51 am
There is no download with all data files available at the moment, only EXE file.How about all data files with EXE ? And does it so difficult to place it (EXE + data files) together?
I will prepare a full download later today.
Post by: Yankes on April 11, 2016, 07:07:56 pm
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.
Post by: g5-freemen on April 12, 2016, 06:11:14 pm
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.
Post by: Meridian on April 12, 2016, 06:42:49 pm
You need different data files.
Post by: g5-freemen on April 13, 2016, 11:16:27 am
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).For me there is only one problem - font.dat
You need different data files.
Post by: Solarius Scorch on April 13, 2016, 01:44:39 pm
Post by: Meridian on April 13, 2016, 02:27:25 pm
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.
Post by: R1dO on April 13, 2016, 02:33:04 pm
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.
Post by: g5-freemen on April 13, 2016, 05:23:59 pm
Post by: Meridian on April 13, 2016, 06:03:21 pm
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)
Post by: Meridian on May 14, 2016, 06:12:38 pm
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...
Post by: Yankes on May 14, 2016, 06:41:51 pm
Post by: Dioxine on May 25, 2016, 05:13:33 am
Code: [Select]
psiAttackName: STR_PSI_CUSTOM_ATTACK
accuracyUse: 7
damageBonus:
psi: 0.02
damageAlter:
ToHealth: 1.0
Post by: Yankes on May 25, 2016, 09:26:47 am
Post by: Dioxine on May 25, 2016, 01:23:44 pm
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 :)
Post by: Yankes on May 25, 2016, 11:16:44 pm
Ah so it does need a damage type! Ok got it now. But it still does work through walls, right? :)yup
Post by: Meridian on May 31, 2016, 11:02:10 am
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
Post by: Yankes on May 31, 2016, 08:03:45 pm
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.
Post by: Solarius Scorch on May 31, 2016, 08:06:49 pm
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)
Post by: Meridian on May 31, 2016, 08:18:41 pm
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
Post by: Yankes on May 31, 2016, 11:44:52 pm
25edd7b is 2nd of January, right?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.
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
That's great news! There's a number of features that would be really useful for Piratez or X-Com Files: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).
- Soldier Diaries
- spawning UFO by mission
- destroyItem command
- defining waypoints (if possible, by soldier stats too)
Post by: Dioxine on June 02, 2016, 10:40:05 am
Post by: Yankes on June 02, 2016, 09:55:42 pm
Code: [Select]
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:
Code: [Select]
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.
Post by: Yankes on June 25, 2016, 12:08:23 am
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.
Post by: begri on June 25, 2016, 10:46:39 am
Gesendet von meinem SM-T800 mit Tapatalk
Post by: Dioxine on June 25, 2016, 12:39:16 pm
Post by: Yankes on June 25, 2016, 02:11:38 pm
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.
Post by: Vesparco on June 28, 2016, 02:12:11 am
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
Post by: Solarius Scorch on June 28, 2016, 07:19:56 pm
Post by: Yankes on June 28, 2016, 07:27:32 pm
Post by: Meridian on June 28, 2016, 07:53:47 pm
Post by: Solarius Scorch on June 28, 2016, 10:18:37 pm
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?
Post by: Yankes on June 28, 2016, 10:37:09 pm
Give both the same prevention condition and also make them both cause the condition?Then it should be "unique" instead of "forbid".
Post by: Vesparco on June 29, 2016, 02:14:24 am
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
Post by: Yankes on June 29, 2016, 08:00:25 pm
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.
Post by: Vesparco on June 30, 2016, 01:30:35 am
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 ???
Post by: Yankes on June 30, 2016, 06:59:17 pm
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.
Post by: Yankes on July 01, 2016, 09:29:23 pm
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:
Code: [Select]
#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.
Code: [Select]
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:
Code: [Select]
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 toreact (20 = 100/2 - 30).
We can define variables, each variable have fixed type and can't store anything else:
Code: [Select]
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:
Code: [Select]
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.Code: [Select]
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`.
Post by: ivandogovich on July 02, 2016, 04:45:27 am
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).
Code: [Select]
Resources/Corpses/PIR_1_b.png
Resources/Corpses/PIR_1_bs.png
Resources/Corpses/PIR_1_bw.pngAlternately 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.
Post by: Yankes on July 02, 2016, 05:19:48 pm
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.
Post by: ivandogovich on July 03, 2016, 02:37:01 am
Post by: Yankes on July 03, 2016, 12:26:39 pm
Post by: Meridian on July 03, 2016, 07:19:37 pm
Post by: Yankes on July 03, 2016, 09:16:49 pm
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.
Post by: Meridian on July 04, 2016, 01:49:02 pm
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)
Post by: Yankes on July 04, 2016, 06:16:02 pm
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?
Post by: Meridian on July 04, 2016, 06:50:38 pm
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
Code: [Select]
[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
Post by: Meridian on July 04, 2016, 07:09:29 pm
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.
Post by: Yankes on July 04, 2016, 09:01:55 pm
This commit should fix VS bug. Meantime I'm working on rest of bugs.
Post by: clownagent on July 04, 2016, 09:17:05 pm
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
Post by: Yankes on July 04, 2016, 10:05:56 pm
Thanks, you save me some hours of work to figuring out this bug :)
Some time ago a similar bug was fixed in the main openxcom branch.
https://github.com/SupSuper/OpenXcom/commit/ab552fb0aa7b16ef29f3c178bddcbb0b9546903b
[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.
Post by: Meridian on July 05, 2016, 09:10:58 am
Also, you may want to rename forbidenBaseFunc to forbiddenBaseFunc, just for spelling correctness before you release 3.1 :)
Post by: Yankes on July 05, 2016, 01:58:46 pm
[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.
Post by: Meridian on July 05, 2016, 06:24:36 pm
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?
Post by: ivandogovich on July 05, 2016, 07:41:26 pm
@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.
Post by: Yankes on July 07, 2016, 03:48:28 pm
Code: [Select]
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.
Post by: Yankes on July 07, 2016, 10:45:03 pm
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.
Post by: ivandogovich on July 07, 2016, 11:11:06 pm
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:
Code: [Select]
if eq blit_part blit_item_floorneed to be updated for the BigObs?
Post by: Yankes on July 08, 2016, 12:35:50 am
Some questions about Scripts:right I did it only for FloorObs. You probaby need copy paste this `if` to `end` replaced `getSpriteOffsetFloorob` with `getSpriteOffsetBigobs`.
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:Code: [Select]if eq blit_part blit_item_floorneed to be updated for the BigObs?
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.
Post by: ivandogovich on July 08, 2016, 01:13:26 am
Code: [Select]
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
Post by: Yankes on July 08, 2016, 01:41:17 am
Code: [Select]
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.
Post by: ivandogovich on July 08, 2016, 02:00:14 am
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?
Post by: Yankes on July 08, 2016, 01:07:26 pm
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.
Post by: Dioxine on July 11, 2016, 04:22:52 pm
Post by: Yankes on July 11, 2016, 06:53:57 pm
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:
Code: [Select]
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.
Post by: Dioxine on July 11, 2016, 07:01:50 pm
Post by: Yankes on July 11, 2016, 07:38:33 pm
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:
Code: [Select]
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:Code: [Select]
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`.
Post by: Dioxine on July 13, 2016, 03:38:41 pm
Post by: ivandogovich on July 17, 2016, 06:50:06 am
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.
Code: [Select]
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:
Code: [Select]
[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.
Post by: Yankes on July 17, 2016, 01:19:16 pm
Code: [Select]
invalid operation in line: 'wDo you see this "w"?Code: [Select]
unit.getFatalwoundsTotal curr_wounds;wI 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:
Code: [Select]
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;
Post by: ivandogovich on July 17, 2016, 05:09:41 pm
I must have gotten my version messed up.
Post by: ivandogovich on July 17, 2016, 06:17:38 pm
Code: [Select]
[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.
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.
Post by: Yankes on July 17, 2016, 06:34:10 pm
Post by: ivandogovich on July 17, 2016, 06:40:43 pm
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?
Post by: Yankes on July 17, 2016, 08:24:30 pm
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:
Code: [Select]
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.
Post by: ivandogovich on July 18, 2016, 05:15:57 am
First I read back through all the posts we have exchanged about this script. One of the things that you mentioned was that the
Code: [Select]
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:
Code: [Select]
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: intDespite 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.
Code: [Select]
[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:
Code: [Select]
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. :(
Post by: Yankes on July 18, 2016, 08:19:01 pm
Code: [Select]
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.
Post by: ivandogovich on July 18, 2016, 11:06:50 pm
Code: [Select]
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:
Code: [Select]
[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?
Post by: ivandogovich on July 19, 2016, 12:31:06 am
The script crashes before debug has a chance to log at the last return sprite_index
Code: [Select]
rules.getSpriteOffsetFloorob sprite_index temp; #logs here
return sprite_index; #crashes before it writes here.
Post by: Yankes on July 19, 2016, 01:13:37 am
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?
Post by: ivandogovich on July 19, 2016, 01:34:24 am
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" :
Code: [Select]
[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;'
Post by: Yankes on July 19, 2016, 02:05:39 am
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.
Post by: ivandogovich on July 19, 2016, 07:52:35 pm
Code: [Select]
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?
Post by: Yankes on July 19, 2016, 11:14:31 pm
I was looking through the various versions of the script that I've been playing with and I noticed a line: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.Code: [Select]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?
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.
Post by: ivandogovich on July 20, 2016, 05:23:50 pm
[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!)
Post by: Dioxine on July 20, 2016, 05:56:03 pm
Post by: Meridian on July 20, 2016, 06:13:10 pm
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).
Post by: ivandogovich on July 20, 2016, 06:21:59 pm
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?
Code: [Select]
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;
Post by: Yankes on July 20, 2016, 07:27:45 pm
Thats a really good point, Dioxine!Unit do not spawn corpse after overkill, but you can modify corpse unit that was close to evaporating simply looking on current hp.
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?Code: [Select]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;
Over kill is amount of current negative hp that surpass durability of "corpse".
Code: [Select]
overkillDamage = -curr_health - max_health * overKill
Post by: Yankes on July 20, 2016, 11:24:05 pm
Post by: ivandogovich on July 21, 2016, 02:00:38 am
Post by: Dioxine on July 21, 2016, 02:21:14 pm
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.
Post by: Yankes on July 21, 2016, 11:58:15 pm
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?
Post by: Starving Poet on July 22, 2016, 12:15:32 am
Post by: Dioxine on July 22, 2016, 01:52:45 pm
Also... Something's not right. I have this code:
Code: [Select]
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...
Post by: Yankes on July 22, 2016, 07:32:05 pm
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.
Post by: Dioxine on July 22, 2016, 09:09:30 pm
Post by: Yankes on July 24, 2016, 02:37:28 pm
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.
Post by: Solarius Scorch on July 24, 2016, 02:44:50 pm
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.
Post by: Yankes on July 24, 2016, 03:30:08 pm
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.
Post by: Solarius Scorch on July 24, 2016, 03:43:34 pm
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.
Post by: Starving Poet on July 24, 2016, 04:44:49 pm
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
Post by: ivandogovich on July 27, 2016, 06:44:34 am
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.
Code: [Select]
[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:
Code: [Select]
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. :)
Post by: Yankes on July 27, 2016, 07:35:23 pm
Post by: ivandogovich on July 27, 2016, 08:44:41 pm
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.
Post by: Yankes on July 27, 2016, 09:04:06 pm
Second mod override it ad pointing to wrong one causing crash.
Post by: ivandogovich on July 27, 2016, 09:09:33 pm
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)
Post by: Yankes on July 27, 2016, 09:45:17 pm
`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.
Post by: ivandogovich on July 27, 2016, 10:09:04 pm
`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)
Post by: HelmetHair on August 04, 2016, 08:27:30 am
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.
Post by: Solarius Scorch on August 04, 2016, 12:54:31 pm
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?
Post by: Yankes on August 04, 2016, 09:07:22 pm
Yankes,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.
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.
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.Because it would be dead weight and AI will not use it. If you are fine with it, this can be easy change.
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?
Post by: Solarius Scorch on August 04, 2016, 09:50:11 pm
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
Post by: Arthanor on August 04, 2016, 10:09:33 pm
Post by: Yankes on August 04, 2016, 11:18:27 pm
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
Post by: Sputnik on August 10, 2016, 04:39:05 pm
Post by: Meridian on August 10, 2016, 04:46:49 pm
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?
Post by: Sputnik on August 10, 2016, 04:57:59 pm
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.
Post by: Yankes on August 10, 2016, 08:56:09 pm
Yes, of course, everything is copied and installed correctly. Latest build openxcom_git_master_2016_08_07. It's working just fine since morning.Needed data are in first post of this thread.
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.
Post by: Solarius Scorch on August 11, 2016, 11:05:47 am
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.
Post by: Meridian on August 11, 2016, 03:03:03 pm
Post by: Solarius Scorch on August 11, 2016, 03:25:57 pm
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.)
Post by: Meridian on August 11, 2016, 05:19:37 pm
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)
Code: [Select]
- 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]
Post by: Solarius Scorch on August 11, 2016, 05:40:13 pm
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?
Post by: Meridian on August 11, 2016, 05:54:06 pm
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.
Post by: Yankes on August 11, 2016, 09:04:15 pm
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:I appreciate grouping all proposal in one place, it will be helpful to finding what to do next.
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.
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 :)
Post by: Dioxine on August 17, 2016, 08:02:54 pm
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.
Post by: Solarius Scorch on August 17, 2016, 09:03:37 pm
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.
Post by: Yankes on August 17, 2016, 10:21:34 pm
You mean enabling global damageAlter per types, but only for custom types?Right now I see this different, you create new "default" based on original and after that you use it as you fit.
Yeah, it could work.
Post by: HelmetHair on August 18, 2016, 02:39:22 am
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
Post by: Arthanor on August 18, 2016, 04:00:42 am
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! ;)
Post by: HelmetHair on August 18, 2016, 05:25:10 am
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
Post by: Solarius Scorch on August 19, 2016, 02:36:42 pm
It's not that I'm impatient, I would simply like to know, in order to plan my work better.
Post by: Yankes on August 19, 2016, 08:08:26 pm
Yankes, when can we expect an update to newer nightlies?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).
It's not that I'm impatient, I would simply like to know, in order to plan my work better.
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.
Post by: HelmetHair on August 20, 2016, 03:42:41 am
I wait with baited breath.
Post by: Yankes on August 20, 2016, 10:09:44 am
Like a flashlight?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.
I wait with baited breath.
Post by: HelmetHair on August 20, 2016, 11:18:09 am
;D
Post by: clownagent on August 20, 2016, 12:37:35 pm
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.
Post by: Yankes on August 20, 2016, 02:29:22 pm
A short question on scripts:Right now you can't. In future it will be probably possible.
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.
Post by: SophiaThe3rd on August 28, 2016, 10:52:01 am
Post by: Yankes on August 28, 2016, 10:57:14 am
Post by: SophiaThe3rd on August 28, 2016, 11:20:44 am
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
Post by: Yankes on August 28, 2016, 11:43:40 am
Probably most important line in readme is "OpenXcom date: Nightly 2016-01-02" this is exact version of nightly that Extended was build on.
Post by: HelmetHair on August 28, 2016, 01:23:12 pm
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?
Post by: ohartenstein23 on August 28, 2016, 05:21:15 pm
Post by: ivandogovich on August 28, 2016, 05:53:36 pm
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.
-
Post by: Yankes on August 28, 2016, 06:08:05 pm
@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?You do not need current nightly only data folder from 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.
-
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.
Post by: HelmetHair on August 28, 2016, 07:43:44 pm
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.
Post by: Yankes on August 29, 2016, 02:09:18 am
Post by: HelmetHair on August 29, 2016, 03:30:17 am
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.
Post by: Yankes on August 29, 2016, 07:50:30 pm
Post by: Meridian on August 29, 2016, 07:56:16 pm
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 :)
Post by: Arthanor on August 29, 2016, 08:28:09 pm
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.
Post by: Yankes on August 29, 2016, 09:06:12 pm
If I understand correctly it was about difference between 30/40/50/60/70 and 30/30/30/30/30.Then this would be equal comparing two weapons that have 50 and 30 accuracy.
Which is a bit of a difference.
I ask about that have similar performance.
Expected number of landed hits:Fully agree, there are different but is this difference big enough to be something more that some kind of flavor?
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.
Quote
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.
Post by: Arthanor on August 29, 2016, 10:51:10 pm
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! ;)
Post by: HelmetHair on August 29, 2016, 11:38:15 pm
Thank you,
to you both.
Post by: HelmetHair on September 06, 2016, 06:03:12 pm
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
Post by: Starving Poet on September 06, 2016, 06:34:06 pm
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 ;)
Post by: HelmetHair on September 06, 2016, 06:40:23 pm
That's easy, just play the dos version and launch some incendiary rounds ;)
(https://www.troll.me/images/brick-tamland/oh-you.jpg)
;D
Post by: Yankes on September 06, 2016, 06:46:08 pm
Yankes,Other people ask for this too. Right now its on my "far" todo list (far as in far future :>).
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
Post by: CanadianBeaver on September 06, 2016, 07:16:45 pm
Post by: Meridian on September 06, 2016, 07:19:22 pm
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.
Post by: CanadianBeaver on September 06, 2016, 08:54:15 pm
Post by: Arthanor on September 06, 2016, 09:11:33 pm
Post by: CanadianBeaver on September 06, 2016, 09:22:47 pm
Post by: Yankes on September 06, 2016, 09:39:33 pm
Post by: CanadianBeaver on September 06, 2016, 09:51:54 pm
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.
Post by: clownagent on September 29, 2016, 03:11:13 pm
So that different items (grenades) make a different sound when they fly through the air.
Post by: Solarius Scorch on September 29, 2016, 03:23:32 pm
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.
Post by: Yankes on September 29, 2016, 07:17:38 pm
Is there a possibility to define custom "Throwing Sounds" in OXCE?Doable, but it will need wait because my queue is full right now.
So that different items (grenades) make a different sound when they fly through the air.
Post by: clownagent on September 29, 2016, 09:09:44 pm
Doable, but it will need wait because my queue is full right now.
No problem, I will do it with the method Solarius suggested.
Post by: HelmetHair on September 30, 2016, 04:12:34 am
would you be willing to share your feature queue? I'm having a shit week and need something to smile at.
-HH
Post by: clownagent on September 30, 2016, 12:06:49 pm
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
Post by: Yankes on September 30, 2016, 06:54:55 pm
Yankes,This week releasing version 3.3 with:
would you be willing to share your feature queue? I'm having a shit week and need something to smile at.
-HH
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.Right now its fixed value.
Is the maxrange always a fixed value, or can I define it as strength dependent?
Something like:
maxRange: 0.5* strength
Post by: Solarius Scorch on September 30, 2016, 07:01:35 pm
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.
Post by: Yankes on September 30, 2016, 07:14:39 pm
Great news, Yankes!
Will 3.3 include newer nightlies?
AFAIK it's not possible yet. Unless Yankes could write a script or something.
Quote
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.
Post by: Solarius Scorch on September 30, 2016, 07:18:04 pm
This mean that 3.3 will still based on old nightly.
Right, I thought it could be something half-way. But nevermind, thanks!
Post by: Meridian on September 30, 2016, 07:24:52 pm
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.
Post by: Yankes on September 30, 2016, 08:22:22 pm
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?).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).
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.
Post by: Yankes on October 01, 2016, 02:11:31 am
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.
Post by: Meridian on October 01, 2016, 12:29:47 pm
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.
Post by: Yankes on October 01, 2016, 12:43:33 pm
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).Right, I probably need cheery pick your visibility changes as promised that my will be compatible with yours.
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.
Any thing else was conflicted?
Post by: Meridian on October 01, 2016, 12:49:04 pm
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.
Post by: Yankes on October 02, 2016, 05:24:37 pm
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?".
Post by: bladum on October 02, 2016, 09:03:30 pm
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
Post by: Meridian on October 03, 2016, 01:09:20 pm
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.
Post by: Yankes on October 03, 2016, 07:11:01 pm
So, this is what I had to revert to get a clean merge:I will look on this too. In my case half work is done because I write part of it.
- 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.
btw did you play with my new lighting? Do you have any feedback about how it work or its performance?
Post by: Stoddard on October 03, 2016, 07:53:52 pm
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().
Post by: Yankes on October 04, 2016, 09:12:32 am
Yankes, please consider below features:1) Maybe
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
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.
Post by: Meridian on October 04, 2016, 09:26:48 am
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.
Post by: Stoddard on October 04, 2016, 08:49:08 pm
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.
Post by: Meridian on October 04, 2016, 11:56:56 pm
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
Post by: Meridian on October 05, 2016, 11:17:17 am
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.
Post by: Yankes on October 05, 2016, 07:03:44 pm
Post by: Meridian on October 06, 2016, 05:27:07 pm
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.
Post by: Yankes on October 06, 2016, 07:11:42 pm
Opening and closing doors need recompiling shadows for every layer. Adding lot of fire that is independent light source made it even slower.
Post by: Meridian on October 06, 2016, 07:27:45 pm
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.
Post by: bladum on October 09, 2016, 09:20:21 am
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
Post by: Solarius Scorch on October 09, 2016, 12:02:42 pm
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!
Post by: Yankes on October 09, 2016, 02:08:35 pm
Yankes, another ideasThis 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.
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).
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.
Quote
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!).
Quote
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.
Quote
4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.This more like tweaking that new gameplay mechanic.
[...]
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.
Quote
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.
Quote
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.
Post by: Dioxine on October 09, 2016, 07:57:28 pm
Post by: bladum on October 09, 2016, 08:11:30 pm
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.
Post by: HelmetHair on October 11, 2016, 02:39:31 am
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".
Post by: Arthanor on October 11, 2016, 03:09:19 am
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.
Post by: Solarius Scorch on October 11, 2016, 11:24:45 am
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).
Post by: bladum on October 11, 2016, 02:10:16 pm
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.
Post by: ohartenstein23 on October 11, 2016, 02:57:39 pm
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.
Post by: Solarius Scorch on October 11, 2016, 03:03:01 pm
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!
Post by: bladum on October 11, 2016, 04:49:46 pm
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.
Post by: Solarius Scorch on October 12, 2016, 01:58:11 pm
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.
Post by: Yankes on October 12, 2016, 11:31:32 pm
Post by: Meridian on October 16, 2016, 12:34:06 pm
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.
Post by: Yankes on October 16, 2016, 10:52:18 pm
Post by: Meridian on October 16, 2016, 11:02:04 pm
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.
Post by: Yankes on October 17, 2016, 09:11:02 pm
I played first time with 3.3 yesterday and only for a few hours... but I'll check some other situations soon.In other buildings.
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.
Post by: Meridian on October 17, 2016, 10:07:14 pm
In other buildings.
Yes, happens everywhere.
Two examples with test saves attached.
Post by: Starving Poet on October 22, 2016, 05:48:02 am
Post by: Yankes on October 22, 2016, 01:30:56 pm
Yes, happens everywhere.I find cause of bug, `getWallShade` -> `isDiscovered` check wrong part. I will release fix in this week (with another one that fix corpse bug).
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.This more fit Meridian branch when he add lot of UI improvements.
Post by: Meridian on October 22, 2016, 02:32:56 pm
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
Post by: Yankes on October 22, 2016, 03:01:46 pm
Is it the same one I wrote here: https://openxcom.org/forum/index.php/topic,2915.msg72679.html#msg72679Exactly this, `part` should be less by 1.
Or a different one?
Post by: Starving Poet on October 22, 2016, 06:50:29 pm
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*
Post by: Solarius Scorch on October 22, 2016, 08:00:29 pm
Post by: Meridian on October 23, 2016, 07:11:22 pm
*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).
Post by: Starving Poet on October 24, 2016, 02:32:26 am
Post by: Ridаn on October 24, 2016, 02:08:26 pm
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.
Post by: The_Funktasm on October 24, 2016, 03:01:13 pm
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.
Post by: ohartenstein23 on October 24, 2016, 03:24:28 pm
Post by: The_Funktasm on October 24, 2016, 06:46:50 pm
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...
Post by: Yankes on October 24, 2016, 11:02:20 pm
Thanks much. Interested in seeing first-hand what all this is capable of over the main branch.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.
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...
From first post:
Code: [Select]
OpenXcom date: Nightly 2016-01-02This 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.
Post by: Meridian on October 27, 2016, 05:27:12 pm
a/ is saving missing?
b/ is loading not necessary and can be removed?
c/ have I missed something?
Post by: Yankes on October 27, 2016, 07:20:48 pm
Post by: Meridian on November 06, 2016, 07:29:23 pm
Please have a look if what I say there is right or not.
Post by: RSSwizard on November 09, 2016, 09:32:28 pm
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.
Post by: ohartenstein23 on November 09, 2016, 09:40:57 pm
Post by: Meridian on November 10, 2016, 12:04:10 am
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.
Post by: Yankes on November 10, 2016, 12:46:41 am
EDIT: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?
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.
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.
Post by: RSSwizard on November 11, 2016, 03:29:43 am
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).
Post by: Arthanor on November 11, 2016, 04:20:43 am
Post by: RSSwizard on November 11, 2016, 04:37:13 am
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
Post by: Yankes on November 11, 2016, 04:26:02 pm
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.
Quote
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.This is too on my TODO list.
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).
Post by: Yankes on November 13, 2016, 01:58:03 am
Dioxine now you will have fun with fixing all incompatibilities caused by over half of year of changes :D
Post by: Solarius Scorch on November 13, 2016, 02:21:13 am
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. ;)
Post by: Dioxine on November 13, 2016, 02:23:25 am
Post by: Yankes on November 13, 2016, 02:35:07 am
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.
Post by: Dioxine on November 13, 2016, 03:37:03 am
Post by: RSSwizard on November 13, 2016, 04:23:53 am
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)
Post by: Dioxine on November 13, 2016, 04:32:13 am
Post by: Meridian on November 13, 2016, 10:04:58 am
........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
Post by: Solarius Scorch on November 13, 2016, 12:43:47 pm
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)
Post by: Yankes on November 13, 2016, 04:21:06 pm
Post by: Solarius Scorch on November 13, 2016, 05:01:56 pm
Is there anything besides Blaster Launcher waypoints which absolutely needs to be changed to work properly?
Post by: Yankes on November 13, 2016, 06:40:51 pm
Thanks, an interesting read.Hard to say, I added changes form ruleset used by basic ufo. aside form `waypoints` the `destroyItem` was added that change behavior of research.
Is there anything besides Blaster Launcher waypoints which absolutely needs to be changed to work properly?
Post by: clownagent on November 17, 2016, 09:32:08 pm
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.
Post by: Yankes on November 18, 2016, 12:54:21 am
I have a feature suggestion:In some future I plans add something like that.
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.
Post by: Ethereal on November 19, 2016, 12:51:21 pm
Can the same be done so that the original logic is not much changed, or changed, but at the request?
Не знаю, что вы сделали, но с последней версией проблемы. В версии сентября 2015 года, всё работает отлично. Меняю на последнюю - даже в меню не входит. Глючит по линии missionScripts. Не знаю, что там может глючить, ибо при старой версии в игре всё работает отлично.
Можно-же было сделать так, что бы логика оригинала не сильно менялась, или менялась, но по желанию?
Можно-же было сделать так, что бы логика оригинала не сильно менялась, или менялась, но по желанию?
Post by: Yankes on November 19, 2016, 01:11:22 pm
Post by: clownagent on November 20, 2016, 05:22:32 pm
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?
Quote
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.
Post by: Yankes on November 20, 2016, 05:36:35 pm
I tried to use theI made bug in documentation, proper name is: "fuseType".
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?
Post by: clownagent on November 20, 2016, 05:59:59 pm
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?
Post by: Yankes on November 20, 2016, 06:12:06 pm
Thanks, it works. Great feature!"-1" is default behavior. "-2" is instant grenade.
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?
And in some future I will add option for grenades exploding in inventory.
Post by: Arthanor on November 20, 2016, 07:48:27 pm
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
Post by: Ethereal on November 21, 2016, 02:47:21 pm
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, указать эти значения для урона по местности?
Не могли бы пояснить, уважаемые профессионалы, каковы значения по умолчанию для урона по объектам местности, для всех типов урона? Я пытаюсь маневрировать параметром "damageAlter: - ToTile:", но не получается сбалансировать нормально, ибо не знаю исходных значений. Не могли бы вы в следующей версии, в Readme.txt, указать эти значения для урона по местности?
Post by: Yankes on November 22, 2016, 01:12:38 am
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.
Post by: RSSwizard on November 23, 2016, 10:37:47 pm
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)
Post by: Yankes on November 23, 2016, 10:43:14 pm
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.
Post by: Meridian on November 24, 2016, 11:00:12 pm
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
Post by: Yankes on November 24, 2016, 11:25:02 pm
Bugreport for OXCE 3.5: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.
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
Post by: Meridian on November 26, 2016, 11:44:01 am
Post by: Yankes on November 26, 2016, 02:02:59 pm
Is there an easy way to turn on the vanilla lighting?Right now not, but what is a problem?
Post by: Meridian on November 26, 2016, 02:18:41 pm
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.
Post by: Yankes on November 26, 2016, 03:03:43 pm
Simple answer is, I just don't like it at all and want vanilla back.Ok, I will add option for that.
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.
Post by: Meridian on November 26, 2016, 03:16:02 pm
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
Post by: Yankes on November 26, 2016, 03:25:50 pm
Post by: Solarius Scorch on November 26, 2016, 03:29:48 pm
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?
Post by: Meridian on November 26, 2016, 03:31:20 pm
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.
Post by: Solarius Scorch on November 26, 2016, 03:41:03 pm
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.
Post by: Dioxine on November 26, 2016, 03:54:58 pm
Post by: Meridian on November 26, 2016, 04:08:21 pm
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.
Post by: Dioxine on November 26, 2016, 04:18:21 pm
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.
Post by: Solarius Scorch on November 26, 2016, 04:43:54 pm
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.
Post by: Dioxine on November 26, 2016, 11:14:42 pm
Post by: Meridian on November 26, 2016, 11:22:47 pm
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.
Post by: Eddie on November 28, 2016, 02:53:09 am
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?
Post by: Yankes on November 28, 2016, 10:21:23 pm
Post by: BTAxis on November 28, 2016, 11:19:36 pm
Post by: Yankes on December 04, 2016, 05:57:49 pm
Thanks!Commit that fix bug with big unit animation: https://github.com/Yankes/OpenXcom/commit/64168e2befa7cf249cf9b549405ce5bef05d88f8
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
You can cherry-pick it or wait week or two for next version of OXCE
Post by: Meridian on December 06, 2016, 12:36:44 am
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.
Post by: Yankes on December 06, 2016, 02:02:03 am
Post by: Meridian on December 08, 2016, 11:44:59 am
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
Post by: ohartenstein23 on December 15, 2016, 07:13:17 pm
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.
Post by: Yankes on December 15, 2016, 08:02:22 pm
Post by: Meridian on December 15, 2016, 08:17:35 pm
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.
Post by: ohartenstein23 on December 15, 2016, 08:27:39 pm
Post by: Yankes on December 15, 2016, 11:42:17 pm
Post by: Yankes on December 16, 2016, 11:03:01 pm
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
Post by: ohartenstein23 on December 16, 2016, 11:20:23 pm
Post by: Yankes on December 16, 2016, 11:37:48 pm
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.
Post by: Meridian on December 17, 2016, 12:15:49 am
Post by: Yankes on December 17, 2016, 12:42:50 am
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".
Post by: TheSHEEEP on December 18, 2016, 01:55:12 pm
I copied the UFO files, but when I try to start, I get this in the log:
Quote
[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.
Post by: Yankes on December 18, 2016, 08:20:09 pm
Post by: TheSHEEEP on December 18, 2016, 11:54:50 pm
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.
Post by: Meridian on December 19, 2016, 12:06:40 am
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.
Post by: Yankes on December 19, 2016, 01:38:25 am
Well, it says: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?
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.
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).
Post by: TheSHEEEP on December 19, 2016, 10:59:13 am
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!
Post by: Ethereal on December 23, 2016, 10:11:47 pm
Убедительная просьба, указать опцию, или придумать способ отключения берсерка у пришельцев. Причём только берсерка. Поскольку пришельцы при берсерке всё равно атакуют ближайшую цель игрока и от обычных их действий, в этом случае, берсерк не отличается ничем. Опция паники в МК разрушителе, полностью и абсолютно бесполезна. Кроме того, сильно надоели взрывы берсеркующих внутри кораблей, которые лишают фрагов и ценных пленных.
Post by: Yankes on December 23, 2016, 11:00:34 pm
Post by: Ethereal on December 23, 2016, 11:22:42 pm
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:", могут получится интересные комбинации. Например Мутоны настолько свирепы, что никогда не паникуют, а только сходят с ума. И так далее.
Кстати, если развить мысль и к "noBerserk:" добавить "noPanic:" и "noMindControl:", могут получится интересные комбинации. Например Мутоны настолько свирепы, что никогда не паникуют, а только сходят с ума. И так далее.
Post by: SupSuper on December 24, 2016, 06:35:54 pm
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.
Post by: clownagent on December 30, 2016, 12:53:38 pm
Code: [Select]
personalLight: 15 #solder light radius.
but it had no effect. Does the "personalLight" intentionally works only for units controlled by the player?
Post by: Meridian on December 30, 2016, 05:46:59 pm
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.
Post by: Yankes on December 30, 2016, 09:05:20 pm
Hi Yankes,This is very similar to bug with stunning flying unit on edge of map, I will try fix it.
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.
Post by: Ethereal on January 02, 2017, 02:15:16 pm
Post by: Yankes on January 04, 2017, 02:11:50 am
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 )
Post by: Meridian on January 09, 2017, 06:53:54 pm
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?
Post by: Yankes on January 09, 2017, 09:20:45 pm
Code: [Select]
if (!modInfo.isMaster() && !modInfo.getMaster().empty() && modInfo.getMaster() != curMaster)
This `&&` are correct there? because you update `maxSize` when:Code: [Select]
modInfo.isMaster() || modInfo.getMaster().empty() || modInfo.getMaster() == curMaster
If mod is not master but still will bump up `maxSize`.
Post by: Meridian on January 09, 2017, 09:35:39 pm
There's one more check above, so together it is:
Code: [Select]
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.
Post by: Yankes on January 09, 2017, 10:06:38 pm
Post by: ohartenstein23 on January 10, 2017, 08:55:53 pm
Code: [Select]
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
Post by: Yankes on January 10, 2017, 10:07:31 pm
Post by: Solarius Scorch on January 14, 2017, 01:58:10 am
Post by: Yankes on January 14, 2017, 06:28:44 pm
Post by: Solarius Scorch on January 14, 2017, 07:08:59 pm
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:
Code: [Select]
- 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
Post by: Yankes on January 14, 2017, 07:45:28 pm
Code: [Select]
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" :)
Post by: Solarius Scorch on January 14, 2017, 08:29:30 pm
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
Post by: ohartenstein23 on January 16, 2017, 09:24:15 pm
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?
Post by: Yankes on January 17, 2017, 01:07:15 am
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
Post by: HelmetHair on January 20, 2017, 05:12:42 pm
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
Post by: Solarius Scorch on January 20, 2017, 05:28:31 pm
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.
Post by: HelmetHair on January 20, 2017, 08:22:50 pm
Post by: Yankes on January 20, 2017, 08:26:31 pm
Post by: HelmetHair on January 20, 2017, 09:16:24 pm
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?
Post by: Yankes on January 20, 2017, 11:42:50 pm
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 :)
Post by: Thirsk on January 24, 2017, 01:21:43 pm
Ps. I tried it with various nightlies and various versions of OXCE+ from Nov 16 till today but no combination seems to solve it :'(
Post by: Meridian on January 24, 2017, 01:43:58 pm
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
Post by: Thirsk on January 24, 2017, 03:24:28 pm
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.
Post by: Meridian on January 24, 2017, 03:35:47 pm
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).
Post by: Thirsk on January 24, 2017, 03:44:15 pm
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!
Post by: Thirsk on January 25, 2017, 12:58:56 pm
Post by: Yankes on January 25, 2017, 08:25:19 pm
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.
Post by: Thirsk on January 26, 2017, 03:11:08 am
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.
Post by: crutchmaster on January 26, 2017, 08:48:11 am
I dream about openxcom with JSON instead yml, ECMA bindings for most engine function and all not heavy/critical logic in scripts.
Post by: Yankes on January 26, 2017, 07:19:15 pm
What about external ECMA scripts support with duktape (https://duktape.org/), for example.If you propose this two years ago I could use it, right now I'm rolling my own script engine.
I dream about openxcom with JSON instead yml, ECMA bindings for most engine function and all not heavy/critical logic in scripts.
btw yaml is supporting JSON syntax.
Post by: crutchmaster on January 27, 2017, 06:36:38 am
btw yaml is supporting JSON syntax.Good!
Quote
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?
Post by: Meridian on January 27, 2017, 12:55:59 pm
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.
Post by: crutchmaster on January 27, 2017, 07:23:39 pm
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.
Quote
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
Post by: Yankes on January 27, 2017, 09:26:10 pm
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.
Post by: Yankes on January 28, 2017, 12:20:23 am
Post by: Solarius Scorch on January 28, 2017, 11:42:03 am
Post by: Yankes on January 28, 2017, 11:50:04 am
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
Post by: Solarius Scorch on January 28, 2017, 04:59:28 pm
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?
Post by: Yankes on January 28, 2017, 05:29:16 pm
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.
Post by: ohartenstein23 on January 28, 2017, 05:48:37 pm
Post by: Yankes on January 28, 2017, 05:50:48 pm
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.
Post by: Yankes on January 29, 2017, 04:00:32 pm
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.
Post by: HelmetHair on January 29, 2017, 08:52:59 pm
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.
Post by: Yankes on January 29, 2017, 09:03:07 pm
Could you elaborate what config for lighting system means?On/off and some limits for performance.
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.
Post by: ohartenstein23 on January 30, 2017, 04:24:29 pm
Post by: Meridian on January 30, 2017, 07:52:13 pm
Why change the timer from 125 to 100 ms?
Feels quite weird now :/
Post by: Yankes on January 30, 2017, 08:04:59 pm
If it too much off putting then I could tweak it a bit to restore original behavior.
Post by: Meridian on January 30, 2017, 08:08:20 pm
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.
Post by: ohartenstein23 on January 31, 2017, 02:57:31 pm
Code: [Select]
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?
Post by: Yankes on January 31, 2017, 08:08:42 pm
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?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.Code: [Select]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?
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
Post by: ohartenstein23 on January 31, 2017, 09:51:10 pm
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.
Post by: Yankes on January 31, 2017, 11:25:41 pm
`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?
Post by: crutchmaster on February 02, 2017, 11:04:47 am
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.
Post by: ohartenstein23 on February 02, 2017, 04:19:48 pm
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.
Post by: Yankes on February 02, 2017, 07:17:04 pm
Sorry I haven't posted that error yet - I forgot about it. I'll post it later today.I plan add random in 3.7. For damage type I will add this is bugfix release in this week.
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.
For "pointer to armor" I have long term plans to add some thing like that.
Post by: ohartenstein23 on February 02, 2017, 07:21:44 pm
Post by: Meridian on February 03, 2017, 01:33:01 am
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.
Post by: Yankes on February 03, 2017, 08:24:40 pm
Bugreport:Good catch, I will fix it.
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.
Post by: ohartenstein23 on February 03, 2017, 09:00:08 pm
Post by: Yankes on February 04, 2017, 01:44:47 am
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
Post by: Yankes on February 04, 2017, 05:08:43 pm
Fix couple of bugs.
Add some missed scripts.
Add damage type param to unit damage script.
Post by: HelmetHair on February 05, 2017, 09:07:51 am
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 :)
Post by: Meridian on February 05, 2017, 11:00:25 am
You can define soldier types with higher minimum stats and bigger initial pay/salary.
Post by: Meridian on February 05, 2017, 12:21:04 pm
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.
Post by: Yankes on February 05, 2017, 01:42:42 pm
[ps]
bug fix: https://github.com/Yankes/OpenXcom/commit/b2125b7a00bbedb8ee4ec8ecd90b67999907a78a
[ps2]
new version is up
Post by: ohartenstein23 on February 07, 2017, 07:08:04 pm
Post by: Yankes on February 07, 2017, 08:11:20 pm
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.
Post by: HelmetHair on February 07, 2017, 10:42:53 pm
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?
Post by: Meridian on February 07, 2017, 10:54:06 pm
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.
Post by: HelmetHair on February 08, 2017, 06:54:46 am
It will be tomorrow.
Post by: Meridian on February 08, 2017, 12:17:42 pm
quick question: when is this code (in mapdata.cpp) used? and for what?
https://github.com/Yankes/OpenXcom/commit/fff64519ec2703df7995773816992d714157b6fa#diff-c89e1363278b09061cd6d81fca7e79eeR176
Post by: Yankes on February 08, 2017, 08:07:49 pm
Post by: Meridian on February 08, 2017, 08:10:41 pm
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?
Post by: Yankes on February 08, 2017, 09:20:15 pm
That's exactly why I asked :)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.
I was wondering if that "default:" branch is important or if it could return _block[2] as well?
Post by: Biggieboy on February 09, 2017, 12:40:31 am
How can i do this? Need building? Where is this option?
Post by: Meridian on February 09, 2017, 01:07:54 am
"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.
Post by: Biggieboy on February 09, 2017, 05:29:40 am
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!
Post by: Meridian on February 09, 2017, 10:54:20 am
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
Post by: Biggieboy on February 09, 2017, 08:36:56 pm
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?
Post by: Meridian on February 09, 2017, 08:38:58 pm
Somebody else please answer Biggieboy's question...
Post by: ohartenstein23 on February 09, 2017, 08:40:43 pm
Post by: Solarius Scorch on February 09, 2017, 08:41:23 pm
If the meaning is something else, then I give up too. :P
Post by: wolfreal on February 09, 2017, 09:04:06 pm
"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.
Post by: Biggieboy on February 09, 2017, 09:08:57 pm
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)"
Post by: Meridian on February 09, 2017, 09:14:48 pm
... because yes, it applies to everything.
Post by: Biggieboy on February 09, 2017, 09:17:46 pm
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.
Post by: wolfreal on February 09, 2017, 09:25:11 pm
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.
Post by: Biggieboy on February 09, 2017, 09:28:10 pm
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.
Post by: Solarius Scorch on February 09, 2017, 09:32:10 pm
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.
Post by: Meridian on February 09, 2017, 09:34:19 pm
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.
Post by: Biggieboy on February 09, 2017, 09:37:45 pm
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..
Post by: Meridian on February 09, 2017, 09:42:46 pm
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.
Post by: Biggieboy on February 09, 2017, 09:45:24 pm
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"
Post by: ohartenstein23 on February 10, 2017, 11:19:17 pm
Post by: Yankes on February 10, 2017, 11:36:56 pm
I will add in 3.7 weapon and shooter to damage script.
Post by: Solarius Scorch on February 12, 2017, 04:19:08 pm
Post by: Yankes on February 12, 2017, 04:28:22 pm
[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.
Post by: Juku121 on February 14, 2017, 07:49:39 pm
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.
Post by: Yankes on February 14, 2017, 08:22:35 pm
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
Post by: Juku121 on February 14, 2017, 08:48:55 pm
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.
Post by: Yankes on February 14, 2017, 10:43:34 pm
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".
Post by: Juku121 on February 15, 2017, 01:19:36 am
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.
Post by: Dioxine on February 15, 2017, 09:11:51 am
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).
Post by: Juku121 on February 15, 2017, 10:27:41 am
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’.
Post by: Meridian on February 15, 2017, 11:00:41 am
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.
Post by: Juku121 on February 15, 2017, 11:54:58 am
Sorry for needlessly wasting your time with an already resolved issue. I really do need to upgrade before asking for help again.
Post by: Dioxine on February 15, 2017, 08:10:54 pm
Post by: Yankes on February 15, 2017, 09:00:15 pm
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.
Post by: clownagent on February 16, 2017, 10:21:25 pm
Code: [Select]
fuseType: -2
isExplodingInHands: true
But the grenade does not explode in hand.
Is the "isExplodingInHands" tag only working for other fuseTypes?
Post by: Yankes on February 17, 2017, 12:37:41 am
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`).
Post by: clownagent on February 17, 2017, 09:24:58 pm
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.
Post by: Yankes on February 18, 2017, 12:17:54 am
If I understand correctly `isExplodingInHands: true` is doing currently nothing for `fuseType: -2`.Yes, its do nothing but this is consistent with behavior of this grenade on ground (`isExplodingInHands` == "inventory work same as ground").
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.
I think proper solution for this is add different fuse type that will explode on impact and at end of turn.
Post by: RSSwizard on February 23, 2017, 12:45:03 am
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)
Post by: Meridian on February 23, 2017, 01:13:01 am
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.
Post by: RSSwizard on February 23, 2017, 01:21:33 am
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.
Post by: robin on February 26, 2017, 11:17:33 pm
- 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?
Post by: Yankes on February 27, 2017, 01:03:47 am
Post by: RSSwizard on February 27, 2017, 05:56:18 am
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)
Code: [Select]
[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
Post by: Meridian on February 27, 2017, 11:20:14 am
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
Post by: RSSwizard on February 27, 2017, 08:49:34 pm
Quote
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?
Post by: Solarius Scorch on February 28, 2017, 08:20:37 pm
Code: [Select]
lighting:
enhanced: 7to 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?
Post by: Yankes on March 02, 2017, 11:17:29 pm
In order to use the enhanced lighting system, I had to adderror 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.Code: [Select]lighting:to the global variables.
enhanced: 7
However, the documentation suggests that 7 should be default. Instead, 2 is default.
Is it an error in the code, or the documentation?
All times I used override value for tests and I miss default case.
Post by: robin on March 04, 2017, 12:47:36 pm
Code: [Select]
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. :-[
Post by: Yankes on March 04, 2017, 01:36:40 pm
Post by: robin on March 04, 2017, 01:51:16 pm
Post by: Yankes on March 04, 2017, 05:57:08 pm
is it used just for spotting bases?Yest, both for aliens and xcom.
Post by: robin on March 05, 2017, 04:17:11 pm
Code: [Select]
craftWeapons:
- type: STR_DIMENSIONAL_SCAN
sprite: 110
weaponType: 1 # irrelevant for the crash
stats:
radarRange: 1304
sightRange: 1304I'm using OXCE+ 3.6The sprite is not the culprit (is is used successfully in another craft weapon).
Post by: Meridian on March 05, 2017, 06:24:53 pm
The following is making the game crash
The "launcher" attribute on craft weapons is mandatory.
Post by: robin on March 05, 2017, 09:34:59 pm
Post by: Yankes on March 07, 2017, 01:21:22 am
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
Post by: Solarius Scorch on March 07, 2017, 01:36:04 am
Were there any changes to the vanilla files that modders should be aware of?
Post by: Yankes on March 07, 2017, 07:09:21 pm
Post by: Meridian on March 08, 2017, 06:54:33 pm
(Doesn't crash in Release mode.)
Post by: Yankes on March 08, 2017, 09:32:51 pm
BattlescapeGenerator crashes before any mission, in visual studio in Debug mode, in 3.7.I will look at that.
(Doesn't crash in Release mode.)
Post by: Yankes on March 09, 2017, 07:33:03 pm
Post by: Meridian on March 09, 2017, 11:53:12 pm
This commit fix this bug: https://github.com/Yankes/OpenXcom/commit/f807f5213d4c5add50bea17025d9d0b7a61bc8df
Thx, that helped.
Not getting the crash anymore.
Post by: Yankes on March 10, 2017, 01:24:10 am
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 :> ).
Post by: sectopod on March 11, 2017, 02:05:59 am
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
Post by: Yankes on March 11, 2017, 11:32:12 am
Post by: Solarius Scorch on March 11, 2017, 02:09:55 pm
Post by: Meridian on March 11, 2017, 02:57:05 pm
I found a fix, but don't know if that's all or maybe something else could be missing...
Post by: Yankes on March 11, 2017, 04:53:04 pm
Post by: sectopod on March 12, 2017, 03:11:42 am
Yes, that was whole point of releasing it.
great! thank you!
Post by: RSSwizard on March 16, 2017, 02:27:03 pm
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.
Post by: HelmetHair on March 16, 2017, 02:30:51 pm
Post by: Meridian on March 16, 2017, 02:35:04 pm
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.
Post by: SIMON BAILIE on March 16, 2017, 04:52:52 pm
Post by: Meridian on March 16, 2017, 06:29:56 pm
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.
Post by: SIMON BAILIE on March 16, 2017, 07:29:37 pm
Post by: Solarius Scorch on March 16, 2017, 08:35:49 pm
Post by: Yankes on March 16, 2017, 11:27:59 pm
Can we expect (hope) two ammo weapons in the next version OXCE+?This is still in plans for next version.
Post by: ohartenstein23 on March 20, 2017, 04:47:36 pm
Post by: Solarius Scorch on March 20, 2017, 06:29:53 pm
Post by: Yankes on March 20, 2017, 07:21:04 pm
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.
Post by: ohartenstein23 on March 20, 2017, 07:36:22 pm
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.
Post by: Yankes on March 20, 2017, 07:57:35 pm
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.
Post by: RSSwizard on March 22, 2017, 02:09:34 am
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
Post by: Solarius Scorch on March 22, 2017, 08:33:55 am
Post by: RSSwizard on March 25, 2017, 07:58:51 pm
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.
Post by: ohartenstein23 on April 01, 2017, 06:49:45 pm
Post by: Meridian on April 02, 2017, 04:15:43 pm
can you please help with the following report: https://openxcom.org/forum/index.php/topic,5403.msg81586.html#msg81586
M.
Post by: Yankes on April 10, 2017, 08:20:45 pm
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.
Post by: Ethereal on April 20, 2017, 01:46:25 pm
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.
Post by: Meridian on April 20, 2017, 04:18:52 pm
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.
Post by: Yankes on April 20, 2017, 08:08:34 pm
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.if it would be per mission toggle and balanced by modder (put "hard" part in some other place) it could be useful.
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.
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.
Post by: Meridian on April 20, 2017, 09:33:39 pm
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.
Post by: Yankes on April 20, 2017, 11:10:35 pm
Post by: Ethereal on April 21, 2017, 05:49:18 am
Quote
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.
Quote
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.
Post by: Meridian on April 21, 2017, 10:04:02 am
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).
Post by: Ethereal on April 21, 2017, 02:22:48 pm
Quote
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.
Post by: Meridian on April 21, 2017, 02:46:44 pm
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).
Post by: Ethereal on April 21, 2017, 07:24:53 pm
Quote
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?
Post by: HelmetHair on May 04, 2017, 01:04:37 am
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.
Post by: Mr. Quiet on May 04, 2017, 08:09:08 am
This is exciting. I'm looking forward to seeing all theses features.DIdn't know all these things are possible in OXC. Hype!!
Post by: Meridian on May 05, 2017, 08:21:35 pm
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
Post by: Meridian on May 09, 2017, 12:28:17 pm
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.
Post by: Yankes on May 09, 2017, 08:29:58 pm
Post by: Yankes on May 10, 2017, 01:12:51 am
Simple fix is move code around to have:
Code: [Select]
_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).
Post by: Meridian on May 14, 2017, 07:10:48 pm
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...
Post by: Yankes on May 14, 2017, 09:09:48 pm
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?
Post by: Yankes on May 17, 2017, 01:56:22 am
"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?
Post by: BTAxis on May 17, 2017, 02:37:43 am
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.
Post by: Meridian on May 17, 2017, 03:13:23 pm
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? :)
Post by: Yankes on May 17, 2017, 07:59:54 pm
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.
Post by: FastForward on May 20, 2017, 09:35:02 pm
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:
Code: [Select]
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.
Post by: Meridian on May 21, 2017, 10:56:18 am
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.
Code: [Select]
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
Post by: Meridian on May 27, 2017, 06:49:42 pm
could you please look at this crash: https://openxcom.org/forum/index.php/topic,5047.msg83553.html#msg83553
Thx,
M.
Post by: Meridian on May 28, 2017, 01:38:57 pm
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
Code: [Select]
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.
Post by: Yankes on May 28, 2017, 06:16:04 pm
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.
Post by: Solarius Scorch on June 01, 2017, 07:47:42 pm
Post by: Yankes on June 01, 2017, 11:57:21 pm
Post by: Solarius Scorch on June 02, 2017, 12:39:36 am
Post by: Yankes on June 06, 2017, 12:55:33 am
With this some small changes like: change name of attack, auto shot of not auto shots, access attack action type in damage script.
Post by: Meridian on June 06, 2017, 08:02:43 pm
Post by: Yankes on June 06, 2017, 09:03:16 pm
Post by: Meridian on June 08, 2017, 12:38:31 pm
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?
Post by: Dioxine on June 08, 2017, 05:22:19 pm
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.
Post by: Yankes on June 08, 2017, 07:13:50 pm
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)There is probably small misunderstanding how it will work.
Secondary changes, very interesting.
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?
Post by: Meridian on June 08, 2017, 07:31:26 pm
this with light? yes.
No, the endless loop during alien turn: https://openxcom.org/forum/index.php/topic,2915.msg83582.html#msg83582
Post by: Yankes on June 08, 2017, 08:02:43 pm
Post by: Dioxine on June 09, 2017, 02:12:36 pm
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?
Post by: Yankes on June 10, 2017, 02:06:31 am
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.
Post by: Dioxine on June 10, 2017, 02:17:14 pm
Post by: Meridian on June 10, 2017, 05:16:18 pm
Tested on e4c8220, no mods.
Post by: Yankes on June 11, 2017, 02:21:29 am
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:
Code: [Select]
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.I will look on this too.
Tested on e4c8220, no mods.
Post by: Morrandir on June 12, 2017, 01:49:52 pm
Post by: Yankes on June 12, 2017, 08:08:07 pm
Post by: Yankes on June 13, 2017, 02:02:37 am
Post by: Ethereal on June 14, 2017, 09:21:19 am
As before, the aliens killed by mines are not recorded in the counter of the killed and do not give experience to the soldiers.
Post by: Yankes on June 15, 2017, 12:43:45 am
Post by: drages on June 25, 2017, 08:23:54 pm
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..
Post by: Meridian on June 25, 2017, 08:48:36 pm
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:
Code: [Select]
items:
- type: STR_GRENADE_LAUNCHER
arcingShot: true
Post by: drages on June 25, 2017, 08:59:24 pm
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.
Post by: Meridian on June 25, 2017, 09:14:14 pm
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
Code: [Select]
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.
Post by: drages on June 25, 2017, 09:21:47 pm
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..
Post by: Meridian on June 27, 2017, 01:31:19 pm
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
Post by: drages on June 27, 2017, 03:05:37 pm
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..
Post by: Meridian on June 27, 2017, 03:22:25 pm
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
Post by: ivandogovich on June 27, 2017, 03:45:44 pm
Post by: drages on June 27, 2017, 04:01:34 pm
@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.
Post by: Meridian on June 27, 2017, 06:51:52 pm
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.
Post by: Yankes on June 27, 2017, 07:40:02 pm
Post by: Meridian on June 27, 2017, 07:44:07 pm
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
Post by: Yankes on July 02, 2017, 06:19:57 pm
Post by: Meridian on July 03, 2017, 12:26:22 pm
Quote
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
Post by: Meridian on July 03, 2017, 04:26:09 pm
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.
Post by: Yankes on July 03, 2017, 07:08:54 pm
And one request:Consider it done
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.
Post by: Meridian on July 05, 2017, 04:25:47 pm
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.
Post by: Yankes on July 05, 2017, 07:26:12 pm
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.
Post by: Dioxine on July 06, 2017, 12:28:09 pm
Post by: Meridian on July 06, 2017, 01:04:45 pm
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?
Post by: Ethereal on July 06, 2017, 02:39:43 pm
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.
Post by: Solarius Scorch on July 06, 2017, 08:17:00 pm
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.
Post by: Meridian on July 06, 2017, 08:19:27 pm
It's a simple rule... you hit enemy => you get exp... simple to explain, simple to remember... simple is good, why make it complicated?
Post by: Solarius Scorch on July 06, 2017, 08:25:44 pm
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.
Post by: Meridian on July 06, 2017, 09:14:32 pm
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?).
Post by: Solarius Scorch on July 06, 2017, 09:39:56 pm
Post by: Meridian on July 07, 2017, 04:05:20 pm
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.
Post by: Yankes on July 07, 2017, 08:59:46 pm
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.
This is why I miss this bug last time I fix bugs in coping.
[ps]
When saving again layout its behave different.
Post by: Dioxine on July 08, 2017, 10:53:30 am
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.
Post by: Eddie on July 08, 2017, 01:22:25 pm
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.
Post by: BTAxis on July 08, 2017, 01:32:55 pm
Post by: Meridian on July 08, 2017, 03:25:37 pm
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.
Post by: Meridian on July 08, 2017, 03:32:52 pm
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.
Post by: Yankes on July 08, 2017, 04:09:50 pm
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.
Post by: karadoc on July 09, 2017, 04:05:23 am
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:
Code: [Select]
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
Post by: Yankes on July 09, 2017, 04:29:42 am
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.
Post by: karadoc on July 09, 2017, 06:15:35 am
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.
Post by: Meridian on July 09, 2017, 08:40:34 am
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.
Post by: Solarius Scorch on July 09, 2017, 10:44:21 am
Solarius (against recommendation) used 3.8 version in xcf and it's crashing a lot.
Er, no, I haven't. Some players upgraded, though.
Post by: Yankes on July 09, 2017, 01:02:03 pm
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.
Quote
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.
Quote
[edit]`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".
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.
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...And it is supported like other ones.
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 for new version, it will be released today or tomorrow, it will be with new goodies from master and fix for all reported bugs.
Post by: Yankes on July 11, 2017, 01:57:22 am
New functionality is script that can alter exp grain (as multiplier on top of Meridian system).
Post by: karadoc on July 11, 2017, 11:06:00 am
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
Code: [Select]
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.
Post by: Meridian on July 11, 2017, 12:13:31 pm
One more similar, but different bug that needs a fix: https://openxcom.org/forum/index.php/topic,5047.msg84804.html#msg84804QuoteA 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.
Post by: Yankes on July 11, 2017, 09:17:32 pm
Here's the relevant bit of codesh*** 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.Code: [Select]if (_visibleEnemies)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.
{
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;
}
Notice val: 12 (BA_LAUNCH), not 8 (BA_SNAPSHOT) as in the earlier bugFailed again :/ I focus too much on "NULL" bug :/
I will add that this bug was also not fixed yet... still crashes.
I will release today fixed version.
Post by: Yankes on July 11, 2017, 11:29:20 pm
Post by: karadoc on July 12, 2017, 01:51:01 am
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.
Post by: Meridian on July 13, 2017, 06:37:46 pm
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?
Post by: Yankes on July 13, 2017, 08:02:14 pm
[ps]
check if it fix your error: https://github.com/Yankes/OpenXcom/commit/3ce7a4cd72580743a579405f0164df9262e183ec
Post by: Meridian on July 14, 2017, 02:28:21 pm
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)
Post by: Yankes on July 14, 2017, 10:50:20 pm
Yes, it's fixed.Thanks for fixes
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)
Post by: kikimoristan on July 19, 2017, 03:48:56 pm
Post by: Ethereal on July 23, 2017, 04:14:29 pm
Post by: Yankes on July 23, 2017, 04:31:10 pm
Post by: Ethereal on July 23, 2017, 05:14:30 pm
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.
Quote
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.
Post by: Meridian on July 23, 2017, 08:16:34 pm
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...
Post by: clownagent on July 23, 2017, 09:29:59 pm
It happened there when the tile was hit by a flame arrow (PirateZ). One turn later when the fire spreads lighting is proper again.
Post by: Ethereal on July 23, 2017, 10:10:01 pm
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?
Post by: Meridian on July 23, 2017, 10:35:52 pm
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.
Post by: Yankes on July 24, 2017, 01:38:47 am
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
Post by: Meridian on July 25, 2017, 10:04:48 pm
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
Post by: SIMON BAILIE on July 27, 2017, 02:16:00 am
https://openxcom.org/forum/index.php/topic,5604.msg85815.html#msg85815
EDIT by Meridian: fixed link
Post by: Meridian on July 27, 2017, 11:11:35 am
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?
Post by: Yankes on July 28, 2017, 02:09:18 am
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)
Post by: Meridian on July 28, 2017, 05:47:50 pm
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.
Post by: Meridian on July 29, 2017, 11:33:40 am
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.
Post by: Meridian on July 31, 2017, 05:53:05 pm
Reported here: https://openxcom.org/forum/index.php/topic,5617.0.html
Post by: Solarius Scorch on July 31, 2017, 06:22:13 pm
Post by: Meridian on July 31, 2017, 06:35:58 pm
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+.
Post by: Yankes on July 31, 2017, 08:57:21 pm
Crash in AI code.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.
Reported here: https://openxcom.org/forum/index.php/topic,5617.0.html
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`.
Post by: ohartenstein23 on August 01, 2017, 01:21:39 am
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.
Post by: clownagent on August 01, 2017, 09:08:41 pm
Code: [Select]
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
Code: [Select]
- 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.
Post by: Nord on August 06, 2017, 05:03:02 am
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.So, what is an issue source? Alien without weapons? Or terror unit without "fixedweapon"? Or psionic alien?
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`.
What can i modify in savegame or ruleset to avoid this bug? (Just for now, because no fixes exist)
Post by: Yankes on August 06, 2017, 09:09:28 pm
Post by: mumble on August 08, 2017, 02:53:00 am
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.
Post by: ohartenstein23 on August 08, 2017, 03:03:32 pm
Post by: Meridian on August 09, 2017, 11:17:46 pm
... 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?
Post by: Yankes on August 10, 2017, 12:59:34 am
Post by: Meridian on August 10, 2017, 09:48:36 am
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
Quote
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
Post by: Meridian on August 13, 2017, 11:50:01 am
Post by: Dioxine on August 15, 2017, 06:45:09 pm
Code: [Select]
isExplodingInHands: flag is not working for BT: 5 items (proxies). Can this function be added (with explosion delay = 0 if no timer set)?
Post by: ohartenstein23 on August 15, 2017, 08:44:38 pm
Post by: Yankes on August 16, 2017, 09:13:08 pm
Fix for a very old merge issue: https://github.com/MeridianOXC/OpenXcom/commit/938c1e772eff2d35fe51da2881438ab79420566bThax, I will pull this.
I noticed a curious thing (intended? bug?): theI do not look to code but I suspect that proxies do not explode until someone step on them.Code: [Select]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.Know bug, I will release fix for it soon (today or tomorrow).
Post by: Meridian on August 20, 2017, 12:18:51 pm
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)
Post by: Yankes on August 20, 2017, 05:57:31 pm
An issue reported from XComFiles... I would describe more, but I'm not sure which part of this is wrong.Ok I will look on this, if I manage to fix it I will release it with other bug fix today.
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)
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):I could say that this is not bug, you are using custom deploy directly in new battle game not as part of ufo deploy.Code: [Select]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 codeCode: [Select]- 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.
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).
Post by: Yankes on August 20, 2017, 06:49:48 pm
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.
Post by: Meridian on August 20, 2017, 07:32:06 pm
Post by: Yankes on August 21, 2017, 03:23:16 am
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.
Post by: Meridian on August 22, 2017, 04:29:36 pm
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...
Post by: Yankes on August 22, 2017, 07:42:38 pm
Yeah, there is definitely something fishy there.as reference you could use my commit: https://github.com/Yankes/OpenXcom/commit/5e97b199367cedd063f2bef1f7c2010df6c8478f
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...
Probably this is one place where this could go wrong.
Post by: Meridian on August 22, 2017, 08:36:21 pm
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.
Post by: ohartenstein23 on August 31, 2017, 12:23:15 am
Post by: Yankes on September 01, 2017, 02:03:18 am
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.
Post by: Meridian on September 01, 2017, 12:06:18 pm
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.
Post by: Meridian on September 01, 2017, 12:09:58 pm
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:
Code: [Select]
items:
- type: STR_PSI_AMP
accuracyMultiplier:
flatHundred: 2
flatRate: true
psiAttackName: CUSTOM_PSI
damageType: 1
damageBonus:
flatHundred: 1
Post by: ohartenstein23 on September 01, 2017, 06:56:30 pm
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.
Post by: Yankes on September 02, 2017, 12:22:59 am
@Yankes:My bad, I mess one condition here is bug fix commit:
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:Code: [Select]items:
- type: STR_PSI_AMP
accuracyMultiplier:
flatHundred: 2
flatRate: true
psiAttackName: CUSTOM_PSI
damageType: 1
damageBonus:
flatHundred: 1
https://github.com/Yankes/OpenXcom/commit/2d6906a8659e23d3353ae796b754df099c1259c5
Post by: Ethereal on September 03, 2017, 08:02:24 am
Post by: Meridian on September 03, 2017, 08:24:56 am
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...
Post by: Ethereal on September 03, 2017, 11:19:13 am
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.
Post by: Meridian on September 03, 2017, 12:54:42 pm
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.
Post by: Yankes on September 03, 2017, 04:01:22 pm
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.
Post by: Meridian on September 03, 2017, 08:38:50 pm
Maybe you'll spot immediately, what could be causing it?
Post by: Yankes on September 05, 2017, 02:22:05 am
Post by: Ethereal on September 07, 2017, 07:21:28 pm
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.
Post by: Yankes on September 07, 2017, 07:50:24 pm
Post by: ohartenstein23 on September 09, 2017, 05:35:41 am
Post by: mumble on September 30, 2017, 10:13:55 pm
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?
Post by: Yankes on October 01, 2017, 01:56:53 pm
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.
Post by: Meridian on October 01, 2017, 02:09:31 pm
Post by: Nord on October 02, 2017, 06:54:48 am
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. :)
Post by: ohartenstein23 on October 05, 2017, 04:17:19 pm
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.
Post by: Yankes on October 05, 2017, 07:32:50 pm
Post by: mumble on October 08, 2017, 08:33:51 am
Post by: Ethereal on October 09, 2017, 12:37:22 pm
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.
Post by: ohartenstein23 on October 19, 2017, 03:15:31 pm
Post by: Yankes on October 20, 2017, 01:57:02 am
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.
Post by: Solarius Scorch on October 27, 2017, 07:06:28 pm
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! :)
Post by: Yankes on October 27, 2017, 08:37:24 pm
"can you please enable timers on flares"
isn't "fuse type" and "exploding in hand" do this trick? Or you want something else?
Post by: Solarius Scorch on October 27, 2017, 08:38:52 pm
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.
Post by: Yankes on October 27, 2017, 08:40:29 pm
Post by: tkzv on November 19, 2017, 05:29:46 pm
"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).
Post by: Yankes on November 19, 2017, 06:30:28 pm
Post by: tkzv on November 19, 2017, 07:56:21 pm
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.
Post by: Solarius Scorch on November 20, 2017, 09:15:14 pm
I do not get this error in the vanilla nightly.
Why not just fix the .rmp? It must be done anyway.
Post by: tkzv on November 20, 2017, 10:46:03 pm
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.
Post by: Solarius Scorch on November 20, 2017, 11:07:45 pm
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.
Post by: tkzv on November 21, 2017, 12:20:28 am
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.
Post by: Yankes on November 26, 2017, 04:47:31 pm
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?
Post by: Solarius Scorch on November 26, 2017, 09:07:13 pm
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.
Post by: Yankes on November 27, 2017, 01:22:06 am
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.
Post by: Solarius Scorch on November 27, 2017, 12:37:41 pm
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 :)
Post by: Yankes on November 27, 2017, 11:36:27 pm
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.)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 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 :)
This will be enough?
Post by: Solarius Scorch on November 28, 2017, 12:40:10 am
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.
Post by: BTAxis on November 29, 2017, 02:18:31 pm
Post by: Yankes on November 30, 2017, 01:33:07 am
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).
Post by: Solarius Scorch on November 30, 2017, 11:48:47 am
Any estimation on the next release date? I would like to adjust my timeframe with OXCE development cycle.
Post by: Yankes on December 01, 2017, 08:50:50 pm
4.0 with lot of big features still is without ETA.
Post by: Solarius Scorch on December 01, 2017, 09:57:05 pm
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!
Post by: Yankes on December 05, 2017, 03:12:47 am
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).
Post by: Yankes on December 11, 2017, 03:16:18 am
Bug fix.
Update nightly.
New grenade fuse config.
rule changes diff: https://github.com/Yankes/OpenXcom/commit/8f8ea26bee7377c566546465d21d1d11a3a536e9#diff-fe0874bb03e6a00382c8b351288b4249
Post by: Solarius Scorch on December 17, 2017, 07:05:03 pm
Like every single time, I have no idea how to use the new feature.
Quote
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?
Post by: Yankes on December 17, 2017, 09:12:17 pm
`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:
Quote
fuseType: -2now flare will start "counting" on throw, because `-2` mean unlimited time, it will stay that way infinity.
fuseTriggerEvents:
defaultBehavior: false
throwTrigger: true
Post by: Solarius Scorch on December 17, 2017, 09:50:09 pm
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.
Post by: Yankes on December 17, 2017, 10:04:05 pm
Post by: Solarius Scorch on December 17, 2017, 10:53:27 pm
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?
Post by: Yankes on December 18, 2017, 01:34:57 am
Code: [Select]
fuseTriggerEvents:
throwTrigger: true
fuseType: 5
I added new property and even split to multiple sub properties to have multiple possible combinations for flare & proxi & grenadebtw grenade can work as proxi now if you use
Code: [Select]
fuseTriggerEvents:
proximityExplode: true
Post by: Solarius Scorch on December 18, 2017, 10:49:50 am
Post by: Nord on December 18, 2017, 03:28:18 pm
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?
Post by: ohartenstein23 on December 18, 2017, 05:27:51 pm
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).
Post by: Nord on December 19, 2017, 03:37:55 am
One small question: is it possible to set blinking of shield on hit longer?
Post by: ohartenstein23 on December 19, 2017, 02:58:20 pm
Code: [Select]
unit.setTag Tag.UNIT_RECOLOR_FRAME_LENGTH 3;to have a number larger than 3.
Post by: Nord on December 20, 2017, 11:56:07 am
Post by: ohartenstein23 on December 20, 2017, 10:30:52 pm
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.
Post by: Yankes on December 21, 2017, 12:33:44 am
Post by: ohartenstein23 on December 23, 2017, 04:57:05 pm
Post by: Yankes on December 23, 2017, 06:18:08 pm
Post by: ohartenstein23 on December 23, 2017, 07:45:22 pm
Post by: Meridian on December 26, 2017, 03:32:02 pm
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."
Post by: ohartenstein23 on December 26, 2017, 04:41:39 pm
For background, we reported this problem here (https://openxcom.org/forum/index.php/topic,2915.msg87448.html#msg87448).
Post by: Yankes on December 26, 2017, 05:33:09 pm
@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
Post by: ohartenstein23 on December 26, 2017, 06:32:02 pm
Post by: Yankes on December 30, 2017, 06:13:41 pm
isRecoverable should be moved from Geoscape item to BattleScape item, because how now work in OXC.
--- posts merged ---
@Yankes:Found and fixed. One check use invalid iterator instead of pointer.
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.
Probably today or tomorrow I will release bugfix version.
Post by: Yankes on January 01, 2018, 08:13:55 pm
Post by: Meridian on January 02, 2018, 06:24:40 pm
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
Post by: Yankes on January 02, 2018, 11:09:40 pm
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 :>
Post by: Meridian on January 03, 2018, 09:33:31 pm
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 :)
Post by: Meridian on January 16, 2018, 04:09:22 pm
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?
Post by: Yankes on January 16, 2018, 08:37:09 pm
Post by: Meridian on January 18, 2018, 06:22:07 pm
1/ Use this mod:
Code: [Select]
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.
Post by: Meridian on January 22, 2018, 05:31:36 pm
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:
Code: [Select]
setValueMax(_currentArmor[side], - std::get<toArmor>(args.data), 0, _armor->getArmor(side));
it should be:
Code: [Select]
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
Post by: Meridian on January 22, 2018, 07:57:47 pm
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:
Code: [Select]
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
Post by: Yankes on January 22, 2018, 08:14:54 pm
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.
Post by: SIMON BAILIE on January 22, 2018, 09:54:51 pm
Post by: Meridian on January 22, 2018, 10:28:50 pm
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
Code: [Select]
if (unit->getOriginalFaction() == FACTION_HOSTILE && getTurn() < rule->getAIUseDelay(getMod()))
should be changed to thisCode: [Select]
if (unit->getFaction() == FACTION_HOSTILE && getTurn() < rule->getAIUseDelay(getMod()))
Fix: https://github.com/MeridianOXC/OpenXcom/commit/68ec0b2b45fd5aa275b3cab3332869901d984b49
Post by: SIMON BAILIE on January 24, 2018, 09:37:12 pm
Post by: Meridian on January 24, 2018, 10:08:55 pm
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.
Post by: ohartenstein23 on February 04, 2018, 05:08:52 pm
Edit: Meridian just wrote a commit to change this, if you'd like to use it (https://github.com/MeridianOXC/OpenXcom/commit/08384009518626a8c1ff1514bc02cf8e2e172044).
Post by: Yankes on February 04, 2018, 05:58:24 pm
I will include this in next version.
Post by: Ethereal on February 12, 2018, 11:03:39 pm
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?
Post by: Yankes on February 12, 2018, 11:23:02 pm
Post by: Ethereal on February 12, 2018, 11:45:07 pm
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"?
Post by: Meridian on February 13, 2018, 12:01:22 am
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...
Post by: ohartenstein23 on February 13, 2018, 11:20:44 pm
Post by: Yankes on February 16, 2018, 09:40:00 pm
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:
Code: [Select]
int overflowFuel = _fuel - _stats.fuelMax;
if (overflowFuel > 0 && !_rules->getRefuelItem().empty())
{
_base->getStorageItems()->addItem(_rules->getRefuelItem(), overflowFuel / _rules->getRefuelRate());
}
setFuel(_fuel);
Post by: Meridian on February 26, 2018, 04:02:37 pm
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.
Post by: Solarius Scorch on February 26, 2018, 05:16:45 pm
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.
Post by: Yankes on February 26, 2018, 09:49:20 pm
A small bug report... which is not even a bug... but a different side-effect than in vanilla.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.
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.
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.
Post by: Meridian on February 26, 2018, 09:58:43 pm
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 :)
Post by: kikimoristan on February 28, 2018, 04:21:54 pm
Post by: Meridian on March 01, 2018, 12:10:08 am
Is it intended or just forgotten?
Post by: Yankes on March 01, 2018, 07:59:04 pm
Post by: Meridian on March 01, 2018, 08:22:13 pm
`-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...
Post by: Yankes on March 01, 2018, 11:35:44 pm
But why is Aimed a parent of Auto and Snap?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.
Doesn't make any sense to me...
Post by: kikimoristan on March 01, 2018, 11:40:01 pm
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.
Post by: Yankes on March 02, 2018, 01:05:21 am
I have completed the Romanian translation for OpenXCom Extended.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.
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.
Post by: Meridian on March 02, 2018, 06:32:55 pm
When a weapon is defined like this:
Code: [Select]
- 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?
Post by: Yankes on March 02, 2018, 07:41:32 pm
Post by: Meridian on March 02, 2018, 09:54:21 pm
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
Post by: Yankes on March 02, 2018, 10:28:10 pm
Post by: Meridian on March 03, 2018, 12:36:59 pm
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?
Post by: Yankes on March 03, 2018, 01:05:59 pm
I see you did lot of check lately, what do you work on right now? This is some kind ruleset "dump"?
Post by: Meridian on March 04, 2018, 03:59:24 pm
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.
Post by: kikimoristan on March 12, 2018, 07:10:22 am
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 :)
Post by: ohartenstein23 on March 14, 2018, 04:26:12 am
Code: [Select]
items:
- type: STR_RIFLE
ammo:
0:
compatibleAmmo: [STR_RIFLE_CLIP]
1:
compatibleAmmo: [STR_RIFLE_CLIP]
confAimed:
ammoSlot: 1
Is there a way around this?
Post by: Yankes on March 14, 2018, 07:35:44 pm
Post by: Meridian on March 15, 2018, 11:02:04 am
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??
Post by: Yankes on March 15, 2018, 07:54:07 pm
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
Post by: Meridian on March 18, 2018, 07:25:45 pm
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
Post by: Yankes on March 19, 2018, 01:13:17 am
Hi again Yankes,https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/DogfightState.cpp#L960 (compare with master)
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
This was use place of this, probably after couple of refactoring I forget remove them.
Post by: Meridian on March 20, 2018, 12:54:12 pm
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.
Post by: Yankes on March 20, 2018, 08:10:15 pm
Post by: ohartenstein23 on March 29, 2018, 12:19:55 am
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?
Post by: Yankes on March 31, 2018, 11:54:57 am
Post by: Ethereal on April 08, 2018, 11:54:20 pm
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?
Post by: Meridian on April 09, 2018, 12:14:57 am
Code: [Select]
soldierDiaries: false
Btw. it's not about the size of the file, splitting it into multiple parts won't help.
Post by: Ethereal on April 09, 2018, 01:15:26 am
You can disable soldier diaries in options.cfg, just set:Code: [Select]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.
Post by: Meridian on April 09, 2018, 01:42:43 am
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.
Post by: Yankes on April 09, 2018, 01:48:26 am
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 :)yup, this more work for Warboy or SupSuper, otherwise OXCE/OXCE+ would need break compatibility with basic version.
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.
Post by: Ethereal on April 09, 2018, 01:40:49 pm
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.
Post by: Meridian on April 09, 2018, 02:14:12 pm
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
Post by: Ethereal on April 09, 2018, 04:01:51 pm
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.
Post by: Meridian on April 09, 2018, 05:40:52 pm
Post by: Ethereal on April 09, 2018, 05:55:11 pm
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
Post by: Meridian on April 10, 2018, 12:42:56 am
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...
Post by: Kammerer on April 10, 2018, 05:48:37 am
Post by: Ethereal on April 10, 2018, 07:25:59 am
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.
Post by: Solarius Scorch on April 10, 2018, 10:32:25 am
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 ;)
Post by: Meridian on May 03, 2018, 11:14:46 am
https://github.com/MeridianOXC/OpenXcom/commit/d3dcd52c430095ca9d6ce4488d6d936733243ced
https://github.com/MeridianOXC/OpenXcom/commit/c20fbbc170f0bc568bf4c6921edbc8b846bffbb6
Post by: Yankes on May 03, 2018, 03:02:11 pm
Post by: Meridian on May 10, 2018, 12:47:23 pm
PS: I didn't add weapon stats since OG doesn't have any, but feel free to add them if you want
Post by: Meridian on May 17, 2018, 11:33:19 pm
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
Post by: Yankes on May 18, 2018, 07:48:03 pm
For now commit for cherry-pick: https://github.com/Yankes/OpenXcom/commit/f0495bf10e03cf37096254dfacc01eae1a8eac63
Post by: Meridian on May 18, 2018, 07:52:48 pm
https://github.com/Yankes/OpenXcom/commit/f0495bf10e03cf37096254dfacc01eae1a8eac63#diff-a19679ce5a8ec8fcb81157507368cd4eR3962
Post by: Yankes on May 18, 2018, 07:56:57 pm
I that "maxStun = 0;" correct?Fast fix aren't fixes, yup I overwrite correct value by this, it should be in `else`.
https://github.com/Yankes/OpenXcom/commit/f0495bf10e03cf37096254dfacc01eae1a8eac63#diff-a19679ce5a8ec8fcb81157507368cd4eR3962
Post by: Meridian on May 26, 2018, 12:23:00 am
https://github.com/Yankes/OpenXcom/blob/stash/workInProgress/src/Mod/RuleItem.cpp#L444
Code: [Select]
if (node["skillApplied"].as<int>(false))
should beCode: [Select]
if (node["skillApplied"].as<bool>(false))
Post by: Yankes on May 26, 2018, 12:29:01 am
Post by: Mechasaurian on May 29, 2018, 05:27:05 pm
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?
Post by: Meridian on May 29, 2018, 05:48:43 pm
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.
Post by: Yankes on May 29, 2018, 09:55:13 pm
It means "some".yup,
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.
@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+
Post by: Meridian on May 31, 2018, 11:04:53 pm
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
Post by: Yankes on May 31, 2018, 11:46:25 pm
Post by: ohartenstein23 on June 08, 2018, 07:25:51 pm
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.
Post by: Yankes on June 09, 2018, 12:04:14 am
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`.
Post by: ohartenstein23 on June 09, 2018, 01:48:34 am
Do you want a commit for the melee attack fix?
Post by: Yankes on June 09, 2018, 01:10:04 pm
Post by: ohartenstein23 on June 09, 2018, 05:28:07 pm
Here's the fix for AI melee attacks at the end of a charge (https://github.com/ohartenstein23/OpenXcom/commit/e31f13d7f578afaa3f3369156a675c0b13ad9a0a).
Post by: robin on June 12, 2018, 10:50:11 pm
Code: [Select]
power: 0
meleeMultiplier:
healthCurrent: 1.0
orCode: [Select]
power: 0
damageBonus:
healthCurrent: 1.0
?
Post by: Meridian on June 12, 2018, 10:57:26 pm
(meleeMultiplier affects accuracy)
Post by: robin on June 12, 2018, 11:39:43 pm
Post by: robin on June 13, 2018, 09:55:07 pm
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:
Code: [Select]
power: 50
damageAlter:
ToHealth: 0.5
ToWound: 3.0so, 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?
Post by: Yankes on June 13, 2018, 10:08:41 pm
`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.
Post by: robin on June 13, 2018, 10:14:51 pm
`false` <- mean `round(damageThatPassArmor*ToWound)`so 10 damage with "ToWound: 3.0" would inflict 30 points of fatal wounds?
Post by: Yankes on June 14, 2018, 01:29:23 am
Post by: robin on June 14, 2018, 11:16:59 pm
Does that means the "power" is reduced by 10% each tile after "powerRangeThreshold" ?
Post by: ohartenstein23 on June 14, 2018, 11:34:54 pm
Post by: robin on June 14, 2018, 11:38:14 pm
Not by 10%, but by a flat 0.1, or 1 power every 10 tiles.thanks!
Post by: Ethereal on June 18, 2018, 07:09:30 am
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.
Post by: Yankes on June 18, 2018, 07:19:55 pm
Post by: Meridian on June 26, 2018, 02:27:54 pm
Post by: Yankes on June 26, 2018, 10:13:48 pm
Post by: Meridian on July 05, 2018, 03:09:41 pm
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
Post by: Meridian on July 13, 2018, 08:39:16 pm
Post by: Yankes on July 13, 2018, 10:43:45 pm
Post by: Meridian on July 20, 2018, 11:57:12 am
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.
Post by: Yankes on July 20, 2018, 02:28:22 pm
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
Post by: Meridian on August 06, 2018, 09:13:46 pm
_missionCustomDeploy is saved, but never loaded
Post by: Yankes on August 06, 2018, 11:12:14 pm
We load `missionSites` and `terrorSites`, one load and another not load this `missionCustomDeploy`. This is correct because one is for backward compatibility.
Post by: Solarius Scorch on August 17, 2018, 04:03:09 pm
We're really far from the vanilla now, which makes me kinda uncomfortable. ;)
Post by: Yankes on August 17, 2018, 07:28:06 pm
Are you getting progress with the next version, Yankes?Real men can live with uncomfortable things :D
We're really far from the vanilla now, which makes me kinda uncomfortable. ;)
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.
Post by: Solarius Scorch on August 18, 2018, 11:40:43 am
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.
Post by: The Reaver of Darkness on August 19, 2018, 09:06:05 pm
We're really far from the vanilla now, which makes me kinda uncomfortable. ;)Extended/Extended+ is the new vanilla.
Post by: Yankes on August 19, 2018, 10:20:21 pm
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+.
Post by: Yankes on August 24, 2018, 09:35:20 pm
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.
Post by: Moon_Dew on August 31, 2018, 08:41:30 am
Post by: Ethereal on August 31, 2018, 09:52:55 am
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.
Code: [Select]
sickBayAbsoluteBonus: 10.0
sickBayRelativeBonus: 10.0Or similar settings with this update will lose relevance?
Post by: Yankes on August 31, 2018, 06:04:53 pm
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.Biggest difference is that you can assign arbitrary value to healing time. If solder is robot, it will not need any time to heal.Code: [Select]sickBayAbsoluteBonus: 10.0
sickBayRelativeBonus: 10.0
Or similar settings with this update will lose relevance?
Post by: Ethereal on August 31, 2018, 06:47:37 pm
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.
Post by: ohartenstein23 on August 31, 2018, 07:15:29 pm
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:
Code: [Select]
armors:
- type: STR_ROBOT_ARMOR
instantWoundRecovery: true
However, the script will be useful for reducing wound time on units used as HP tanks.
Post by: Yankes on September 01, 2018, 12:39:52 am
This is already available in OXCE+ as a tag on armor to determine whether or not a unit takes any wound time:Exactly, scripts are for "custom" behaviors, like now wounds could count to recovery days or even heal up damage still counts.Code: [Select]armors:
- type: STR_ROBOT_ARMOR
instantWoundRecovery: true
However, the script will be useful for reducing wound time on units used as HP tanks.
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).
Post by: LouisdeFuines on September 01, 2018, 09:50:13 am
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?
Post by: The Reaver of Darkness on September 01, 2018, 12:24:14 pm
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.
Post by: Meridian on September 04, 2018, 12:39:33 pm
Please hotfix.
Post by: Yankes on September 04, 2018, 08:07:49 pm
Post by: Yankes on September 04, 2018, 11:13:20 pm
Post by: Meridian on September 04, 2018, 11:55:37 pm
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.
Post by: Meridian on September 05, 2018, 05:58:06 pm
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
Code: [Select]
newMission->start(newMission->getRules().getWave(0).spawnTimer); // fixed delay for first scout
OXCE hasCode: [Select]
newMission->start(mission->getRules().getWave(0).spawnTimer); // fixed delay for first scout
[/code]4/ DEBUG mode in Ufopedia doesn't show all articles anymore
Post by: Yankes on September 05, 2018, 08:30:23 pm
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 :)
Post by: Meridian on September 06, 2018, 06:36:21 pm
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
Post by: Yankes on September 06, 2018, 07:46:59 pm
Post by: Moon_Dew on September 07, 2018, 10:57:41 am
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?
Post by: Meridian on September 07, 2018, 11:45:59 am
...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
Post by: SupSuper on September 08, 2018, 03:10:39 am
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).
Post by: Yankes on September 08, 2018, 03:19:42 am
Post by: Meridian on September 08, 2018, 08:08:15 am
Post by: Yankes on September 08, 2018, 07:01:03 pm
Post by: Yankes on September 09, 2018, 04:34:31 pm
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.
Post by: Yankes on September 09, 2018, 05:37:26 pm
Post by: Meridian on September 17, 2018, 05:31:07 pm